From owner-ipsec@lists.tislabs.com Wed Mar 1 04:17:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA27613; Wed, 1 Mar 2000 04:17:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA01513 Wed, 1 Mar 2000 05:39:58 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D0529@baltimore.com> From: Chris Trobridge To: akrywani@newbridge.com, "'IPSEC Mailing List @ tis labs'" Subject: RE: Use of Encryption in Heartbeat Packets Date: Wed, 1 Mar 2000 10:45:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > No heartbeat protocol can realistically hope to protect > against an adversary > who can modify packets in transit. This is a reasonable > limitation, and if > you read the client puzzles document that was recently posted > to this list > (http://www.rsasecurity.com/rsalabs/staff/ajuels/papers/client > puzzles.pdf), > you will see that they make a similar assumption for their protocol. > > Remember that such an adversary (presumably an intermediate router) can > easily convince you that the peer has crashed simply by refusing to forward > any packets on the link (unless you are using ToS = high reliability, but > that's besides the point). > > If the packet is modified in transit, it will still be rejected, just not in > a fully DoS-resistant fashion. > > Andrew I'm not at all convinced about the usefulness of assumptions made in the puzzle paper. He also goes on to say that the DOS problem could be solved by a PKI... What I think is that the heartbeat protocol isn't a particularly valuable target and should be afforded the protection of an existing IPSEC/ISAKMP SA (definition). From a complexity point of view, it's best if it can be fitted in without having to modify or add to the existing crypto architecture. The problems with the encryption test for integrity are that you need to know what the plaintext should be, and that it adds to the cost of processing a correct datagram. If the code for processing the datagram is generic then it won't be aware of what would be correct plaintext (it probably won't be a single value), and a lot of solutions can probably keep up with checking authentication of long datagrams anyway (it's actually short datagrams that cause more work/byte!). Chris From owner-ipsec@lists.tislabs.com Wed Mar 1 07:41:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03757; Wed, 1 Mar 2000 07:41:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02195 Wed, 1 Mar 2000 09:18:56 -0500 (EST) Date: Tue, 29 Feb 2000 09:41:20 +0300 From: Stanislav Grudnitsky X-Mailer: The Bat! (v1.35) UNREG / CD5BF9353B3B7091 Reply-To: Stanislav Grudnitsky X-Priority: 3 (Normal) Message-ID: <12403.000229@mail.com> To: ipsec@lists.tislabs.com Subject: IKE Algorithms Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Recipient: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I try to find out, is any new IKE algorithms existed. I have only well known SKEME and Oakley. May be anybody knows more? If it's so, please let me know the webpages or ftp site to acquaint with. From owner-ipsec@lists.tislabs.com Wed Mar 1 12:18:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08036; Wed, 1 Mar 2000 12:18:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03461 Wed, 1 Mar 2000 13:27:04 -0500 (EST) From: "Jeff Kleiman" To: Subject: RE: Win2K? Date: Wed, 1 Mar 2000 13:33:05 -0500 Message-ID: <021c01bf83ac$954fed00$f9fea8c0@balrog.tril-inc.com> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <20000223112806.D27253@ffwd.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We have not found any exposed APIs that allow control over Windows 2000 IPSec policies. It was largely because we did not find any programmatic interfaces allowing control over SPD policies and SAs that we went ahead and developed our own Windows 2000 IPSec client. Jeff Kleiman -- Trilogy, Inc. [http://www.tril-inc.com] Provider of core IPSec technology and consulting services -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Skye Poier Sent: Wednesday, February 23, 2000 2:28 PM To: ipsec@lists.tislabs.com Subject: Win2K? Can anyone direct me to the Windows 2000 IPSec snap-in API? I'm assuming here, which may be a stretch, that an API actually exists to configure Win2K IPSec SA's policies etc. Thanks Skye -- Clarity of thought should be accompanied by clarity of technique - Mondriaan Powered by ffwd internet division [ http://www.ffwd.com/ ] From owner-ipsec@lists.tislabs.com Wed Mar 1 14:59:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10453; Wed, 1 Mar 2000 14:59:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04269 Wed, 1 Mar 2000 16:38:36 -0500 (EST) Message-ID: <4270986D781ED211AC4D00A02461F04803D34F34@USPLM208> From: "Franz, Joseph" To: "'ipsec@lists.tislabs.com'" Subject: IPSEC Security Concerns Date: Wed, 1 Mar 2000 15:11:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.32) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk More questions: For IPSEC 'Tunnels', how do devices agree on transmitting packets? Are there any security concerns here? Please let me know what you think. Thanks, Joseph Franz | EDS | Wholesale ASP Services 10975 Benson Drive, Suite 400 | Overland Park, Kansas 66210 Tel: (913) 663.6755 | PCS: (913) 269.8870 e-mail: joseph.franz@eds.com From owner-ipsec@lists.tislabs.com Wed Mar 1 14:59:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10461; Wed, 1 Mar 2000 14:59:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04261 Wed, 1 Mar 2000 16:37:36 -0500 (EST) Message-ID: <4270986D781ED211AC4D00A02461F04803D34F33@USPLM208> From: "Franz, Joseph" To: "'ipsec@lists.tislabs.com'" Subject: What Ports Does IPSEC Use? Date: Wed, 1 Mar 2000 15:10:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.32) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just a quick question for the group: What port(s) does IPSEC use? I've learned that VPN-like services use UDP, but is there a particular port that IPSEC uses; any recommendations on which port(s) to use? Joseph Franz | EDS | Wholesale ASP Services 10975 Benson Drive, Suite 400 | Overland Park, Kansas 66210 Tel: (913) 663.6755 | PCS: (913) 269.8870 e-mail: joseph.franz@eds.com From owner-ipsec@lists.tislabs.com Wed Mar 1 15:46:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11264; Wed, 1 Mar 2000 15:46:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04440 Wed, 1 Mar 2000 17:25:01 -0500 (EST) Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB20344B5DA@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'Franz, Joseph'" , "'ipsec@lists.tislabs.com'" Subject: RE: What Ports Does IPSEC Use? Date: Wed, 1 Mar 2000 14:30:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not sure what you mean. As a layer three protocol, IPSEC itself has no knowledge of ports at all (they are a layer 4 concept) Infact ESP will encrypt the port information if it is a TCP/UDP packet. If you are asking what ports various protocols within IPSEC use I believe that IKE uses port 500 to handle IKE negotiations. Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: Franz, Joseph [mailto:joseph.franz@eds.com] > Sent: Wednesday, March 01, 2000 1:11 PM > To: 'ipsec@lists.tislabs.com' > Subject: What Ports Does IPSEC Use? > > > Just a quick question for the group: > > What port(s) does IPSEC use? I've learned that VPN-like > services use UDP, > but is there a particular port that IPSEC uses; any > recommendations on which > port(s) to use? > > Joseph Franz | EDS | Wholesale ASP Services > 10975 Benson Drive, Suite 400 | Overland Park, Kansas 66210 > Tel: (913) 663.6755 | PCS: (913) 269.8870 > e-mail: joseph.franz@eds.com > > > From owner-ipsec@lists.tislabs.com Wed Mar 1 18:09:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14639; Wed, 1 Mar 2000 18:09:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04715 Wed, 1 Mar 2000 19:23:38 -0500 (EST) Message-ID: <38BDB5BB.3A889116@cisco.com> Date: Wed, 01 Mar 2000 16:28:43 -0800 From: Scott Fanning X-Mailer: Mozilla 4.7C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IETF IPSec WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have looked at the IETF agenda, and was wondering if the IPSec WG is getting together? Scott -- Scott T. Fanning Software Engineer E-mail: sfanning@cisco.com Cisco Systems Inc. From owner-ipsec@lists.tislabs.com Thu Mar 2 09:17:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27211; Thu, 2 Mar 2000 09:17:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07169 Thu, 2 Mar 2000 10:09:24 -0500 (EST) Date: Thu, 2 Mar 2000 10:13:47 -0500 (EST) From: Henry Spencer To: "Franz, Joseph" cc: "'ipsec@lists.tislabs.com'" Subject: Re: What Ports Does IPSEC Use? In-Reply-To: <4270986D781ED211AC4D00A02461F04803D34F33@USPLM208> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 1 Mar 2000, Franz, Joseph wrote: > What port(s) does IPSEC use? I've learned that VPN-like services use UDP, > but is there a particular port that IPSEC uses; any recommendations on which > port(s) to use? The IPSEC services themselves, AH and ESP, are transport protocols, with no concept of ports. (They are peers of TCP or UDP, not clients of them.) The IKE key-negotiation protocol uses UDP port 500. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 2 09:41:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27571; Thu, 2 Mar 2000 09:41:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00325 Thu, 2 Mar 2000 11:24:12 -0500 (EST) Date: Thu, 2 Mar 2000 11:29:36 -0500 Message-Id: <200003021629.LAA14764@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: Scott Fanning CC: ipsec@lists.tislabs.com In-reply-to: Scott Fanning's message of Wed, 01 Mar 2000 16:28:43 -0800, <38BDB5BB.3A889116@cisco.com> Subject: Re: IETF IPSec WG Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Date: Wed, 01 Mar 2000 16:28:43 -0800 From: Scott Fanning I have looked at the IETF agenda, and was wondering if the IPSec WG is getting together? Yes, I have requested one slot, but the secretariat hasn't yet updated the IETF agenda. Speaking of agendas, please send me proposed agenda items for the working group meeting with an estimate of how long you think that item will take. Also, please note that the Internet-Draft submission cutoff date is March 10, a week from now. So if you are working on a draft, please get it done and submitted soon! - Ted From owner-ipsec@lists.tislabs.com Thu Mar 2 15:11:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02711; Thu, 2 Mar 2000 15:11:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01528 Thu, 2 Mar 2000 16:32:26 -0500 (EST) Date: Thu, 2 Mar 2000 16:38:08 -0500 Message-Id: <200003022138.QAA14837@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@lists.tislabs.com Subject: WG Last call: draft-ietf-ipsec-ecn-02.txt Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk While getting ready for the Adelaide IETF meeting, it's been called to my attention that the Ipsec Interactiosn with ECN document, draft-ietf-ipsec-ecn-02.txt has been ready for advance for a few weeks now. Thanks to the authors for submitting this document, and my apologies for not getting this WG last call out sooner. Given that the secretariat won't be in a position to start the IETF-wide last call until after the Adelaide IETF meeting, the WG last call will be a bit longer than normal --- it will end on April 3, 2000. I don't anticipate there to be any serious issues with this document, but if there is, please raise them at this time. Thanks!! - Ted From owner-ipsec@lists.tislabs.com Thu Mar 2 15:11:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02724; Thu, 2 Mar 2000 15:11:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01579 Thu, 2 Mar 2000 16:46:23 -0500 (EST) Date: Thu, 2 Mar 2000 16:52:13 -0500 Message-Id: <200003022152.QAA14854@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: "Theodore Y. Ts'o" CC: ipsec@lists.tislabs.com In-reply-to: Theodore Y. Ts'o's message of Thu, 2 Mar 2000 16:39:12 -0500, <200003022139.QAA14841@tsx-prime.MIT.EDU> Subject: Re: WG Last call: draft-ietf-ipsec-isakmp-gss-auth-05.txt Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Date: Thu, 2 Mar 2000 16:39:12 -0500 From: "Theodore Y. Ts'o" While getting ready for the Adelaide IETF meeting, it's been called to my attention that the Ipsec Interactiosn with ECN document, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Oops, sorry let me resend this... While getting ready for the Adelaide IETF meeting, it's been called to my attention that the A GSS-API Authentication Method for IKE, draft-ietf-ipsec-isakmp-gss-auth-05.txt has been ready for advance for a while now. Thanks to the authors for submitting this document, and my apologies for not getting this WG last call out sooner. Given that the secretariat won't be in a position to start the IETF-wide last call until after the Adelaide IETF meeting, the WG last call will be a bit longer than normal --- it will end on April 3, 2000. I don't anticipate there to be any serious issues with this document, but if there is, please raise them at this time. Thanks!! - Ted From owner-ipsec@lists.tislabs.com Thu Mar 2 15:14:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02770; Thu, 2 Mar 2000 15:14:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01535 Thu, 2 Mar 2000 16:33:22 -0500 (EST) Date: Thu, 2 Mar 2000 16:39:12 -0500 Message-Id: <200003022139.QAA14841@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@lists.tislabs.com Subject: WG Last call: draft-ietf-ipsec-isakmp-gss-auth-05.txt Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk While getting ready for the Adelaide IETF meeting, it's been called to my attention that the Ipsec Interactiosn with ECN document, draft-ietf-ipsec-isakmp-gss-auth-05.txt has been ready for advance for a while now. Thanks to the authors for submitting this document, and my apologies for not getting this WG last call out sooner. Given that the secretariat won't be in a position to start the IETF-wide last call until after the Adelaide IETF meeting, the WG last call will be a bit longer than normal --- it will end on April 3, 2000. I don't anticipate there to be any serious issues with this document, but if there is, please raise them at this time. Thanks!! - Ted From owner-ipsec@lists.tislabs.com Thu Mar 2 16:07:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03530; Thu, 2 Mar 2000 16:07:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01776 Thu, 2 Mar 2000 17:47:21 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: "Theodore Y. Ts'o" cc: ipsec@lists.tislabs.com, "Paul Fahn" Message-ID: <85256896.007D46A8.00@smtpmail.certicom.com> Date: Thu, 2 Mar 2000 14:51:03 -0800 Subject: Re: IETF IPSec WG Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How does one actually issue a draft associated with the working group? Thanks - John "Theodore Y. Ts'o" on 02.03.2000 08:29:36 To: Scott Fanning cc: ipsec@lists.tislabs.com (bcc: John Harleman/Certicom) Subject: Re: IETF IPSec WG Date: Wed, 01 Mar 2000 16:28:43 -0800 From: Scott Fanning I have looked at the IETF agenda, and was wondering if the IPSec WG is getting together? Yes, I have requested one slot, but the secretariat hasn't yet updated the IETF agenda. Speaking of agendas, please send me proposed agenda items for the working group meeting with an estimate of how long you think that item will take. Also, please note that the Internet-Draft submission cutoff date is March 10, a week from now. So if you are working on a draft, please get it done and submitted soon! - Ted From owner-ipsec@lists.tislabs.com Thu Mar 2 16:27:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03752; Thu, 2 Mar 2000 16:27:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01897 Thu, 2 Mar 2000 18:00:12 -0500 (EST) Date: Thu, 2 Mar 2000 18:05:51 -0500 Message-Id: <200003022305.SAA07366@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kanta@hideki.iis.u-tokyo.ac.jp Cc: neo@silkroad.com, ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <200002291551.KAA17349@tonga.xedia.com> <10003010237.AA03121@Ichiko.imailab.iis.u-tokyo.ac.jp> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Kanta" == Kanta Matsuura writes: Kanta> Paul, Since I also think CPU protection is important, Kanta> ... My opinion is that CPU is Kanta> more important in a sense that memory exhaustion can be Kanta> numerically evaluated... Do you have any other reasons (why the Kanta> most significant resource is CPU power rather than state Kanta> memory) ? Several reasons. Adding memory is generally far easier than adding CPU power. Available memory sizes are very large and growing very quickly. CPU power doesn't grow nearly as quickly. That is particularly true when you look at packet processing. In that case, the limits often involve the speed of your I/O bus, which tends to be slow and evolving very slowly indeed. Any protective or recovery action consumes CPU cycles. If you're low on CPU cycles, that's a problem. So if the problem is memory shortage, you probably still have CPU capacity left to resolve it. In general, routers or devices like that have little if any problem in managing memory shortages. CPU shortages are another matter. Many system designs suffer from malfunction under overload, so that some things that have to get done do not get done because the CPU is too busy doing other things that have been given higher priority. It's possible to do system design that avoids these issues, and it is wise to do so, but that also depends on having the right hardware structures. (And the right software religion...) paul Kanta> Paul Koning wrote: Anderson> (2) Risk is reduced by minimizing set-up time and Anderson> maximizing non-setup processing (time). >>> No. Time is not of the essence. The essential issue is the >>> resources consumed before good requests can be distinguished from >>> bad ones. The most significant resource is CPU power; the >>> secondary one is state memory. From owner-ipsec@lists.tislabs.com Thu Mar 2 19:20:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12585; Thu, 2 Mar 2000 19:20:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02692 Thu, 2 Mar 2000 20:41:09 -0500 (EST) Date: Thu, 2 Mar 2000 20:46:50 -0500 Message-Id: <200003030146.UAA17651@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: "John Harleman" CC: "Theodore Y. Ts'o" , ipsec@lists.tislabs.com, "Paul Fahn" In-reply-to: John Harleman's message of Thu, 2 Mar 2000 14:51:03 -0800, <85256896.007D46A8.00@smtpmail.certicom.com> Subject: Re: IETF IPSec WG Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: "John Harleman" Date: Thu, 2 Mar 2000 14:51:03 -0800 How does one actually issue a draft associated with the working group? Thanks - The first time you issue a draft associated with the working group, it requires the concurrance of the working group chair that this is an appropriate work item for the working group. If you want to do this, you should send me e-mail ASAP, since I have to arrange the clearance with the secretariat before you send the I-D to the secretariat. - Ted From owner-ipsec@lists.tislabs.com Thu Mar 2 20:47:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA18636; Thu, 2 Mar 2000 20:47:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA03079 Thu, 2 Mar 2000 22:18:39 -0500 (EST) From: "Mr. Anderson" Message-Id: <200003030323.WAA03578@linux.silkroad.com> Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing To: ipsec@lists.tislabs.com Date: Thu, 2 Mar 100 22:23:15 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From an engineering perspective, time is the core design principle for CPU cycles and RAM; plus timing states and other related time/resource issues. Time is the ultimate resource..... Hence, Time is of the essence and we are all in agreement. To say CPU or RAM is key is to agree, very obviously, that time is underlying critical element, the Zen of network and computer systems. It is still not clear what is the way ahead, to insure that when IPSEC VPNs are in place, that folks of malicious intent will not have a easy target to effect ISAKMP UPD 500 (using whatever) to decrease the reliability, risk and robustness of IPSEC ISAKMP. Anyone clearly know the way ahead? Finest Regards, Neo Previous>> No. Time is not of the essence. The essential issue is the Previous>> resources consumed before good requests can be distinguished from Previous>> bad ones. The most significant resource is CPU power; the Previous>> secondary one is state memory. -- --------------------------- The Y2K Feature: A way of remaining in the 20th century for a little longer ..... 19 - 100 ... a feature, not a bug :) From owner-ipsec@lists.tislabs.com Fri Mar 3 07:08:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20789; Fri, 3 Mar 2000 07:08:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05033 Fri, 3 Mar 2000 08:35:03 -0500 (EST) Message-ID: <000d01bf84df$1cf5afa0$2dcd09c0@nig95> From: "rupesh" To: Subject: Q:Regarding AH & ESP Date: Fri, 3 Mar 2000 12:37:17 +0530 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 5.00.0518.4 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ESP provides both authentication & confidentiality.AH provides authentication only but it provides authentication to IP header also which ESP does't provide. My question is designer's of Ipsec could have implemented this functionality within ESP as well & then there will not be any need for AH. Why they have not done that way & incorporated AH ?. Thanks Rupesh From owner-ipsec@lists.tislabs.com Fri Mar 3 07:58:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26213; Fri, 3 Mar 2000 07:58:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05303 Fri, 3 Mar 2000 09:40:04 -0500 (EST) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Fri, 3 Mar 2000 16:45:58 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: ipsec@lists.tislabs.com Subject: Re: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? In-Reply-To: <000b01bf7f84$6873e6a0$2dcd09c0@nig95> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 25 Feb 2000, rupesh wrote: > I had read nearly all RFC'c of Ipsec , everywhere it talks about CBC > mode implementation only. why Ipsec should not be used in other modes > like CFB or OFB ? Please anyone can give me answer to above question > or forward me a link..... CBC is most probably used since it is 'an old and proven standard'. However there is a number of reasons why one would prefer to use something else: 1. CBC is a serial mode (in encryption). However, in many hardware and software solutions would would prefer to use a parallel mode instead. (pipelined hardware chips, MMX/AltiVec-based implementations, ...) Thus CBC mode is unpleasant from an implementer point of view. See, e.g. http://home.cyber.ee/helger/fastidea/ if you do not believe in parallel software implementations :-) 2. CBC can be attacked by birthday paradox and therefore efficiently reduces the lifetime of a cipher (think about that: in linear cryptanalysis you'll need 2^43 plaintext blocks to break DES itself, but actually you only need 2^32 plaintext blocks to break DES in CBC mode). - that kind of birthday attacks are unavoidable if the cipher is invertible. Thus, CBC mode is unsecure. See recent publications by Mihir Bellare, Phil Rogaway etc. 3. CBC requires the cipher to be invertible but invertibility makes ciphers much slower at the same level of security (compare invertible block ciphers - DES, IDEA, Rijndael - with non-invertible MACs - UMAC). It seems that an additional effort is required from designers to make the cipher invertible and still secure. Combined with 2, using a non-invertible cipher would be beneficial both from security and efficiency point of view and therefore CBC should be abandoned if possible. Now, would it be possible? It would: use the counter mode. It is parallel, does not require a cipher to be invertible, it allows precomputation etc. Moreover, it can be used in combination with DES and other invertible ciphers such that birthday attacks will not apply. It is proven to be very secure in the case of strong underlying cipher. Due to all of this, many cryptographers think that counter mode should replace CBC mode as a standard. I am myself a very strong supporter of this, too. I am currently writing a draft of an internet draft on counter mode that will be finished in a week or two. (If anyone would get a preview of that, please directly contact me.) I hope it could then be considered as a (recommended but not required) part of IPSEC. Helger Lipmaa http://home.cyber.ee/helger From owner-ipsec@lists.tislabs.com Fri Mar 3 08:33:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29443; Fri, 3 Mar 2000 08:33:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05325 Fri, 3 Mar 2000 09:52:09 -0500 (EST) Message-ID: <38BFD0AC.83DA9B33@F-Secure.com> Date: Fri, 03 Mar 2000 16:48:12 +0200 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Mr. Anderson" CC: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <200003030323.WAA03578@linux.silkroad.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Mr. Anderson" wrote: > > >From an engineering perspective, time is the core design > principle for CPU cycles and RAM; plus timing states and > other related time/resource issues. Time is the ultimate > resource..... > > Hence, Time is of the essence and we are all in agreement. > > To say CPU or RAM is key is to agree, very obviously, > that time is underlying critical element, the Zen > of network and computer systems. > > It is still not clear what is the way ahead, to insure > that when IPSEC VPNs are in place, that folks of malicious > intent will not have a easy target to effect ISAKMP > UPD 500 (using whatever) to decrease the reliability, > risk and robustness of IPSEC ISAKMP. > > Anyone clearly know the way ahead? Yes. The way ahead is to consider the capabilities of the adversary, and to define the requirements as to how good protection we wish to obtain against an adversary with the particular capabilities. Some of the key capabilities the adversary may have are a) ability to send forged packets, b) ability to receive responses to former forged packets, c) ability to modify all packets between Alice and Bob, d) how much of traffic the adversary can generate and of what type, e) ditributed attack or not, f) ability to plant a bomb underneath the SGW and to blow it sky-high. One of the key requirements is: if the DoS attack has lowered system capability, what service may fail first? New connections? Existing connections? Connections from peers that succeeded in authenticating in the near past? There's no way to proceed without a requirements specification! Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Fri Mar 3 11:41:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06590; Fri, 3 Mar 2000 11:41:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05928 Fri, 3 Mar 2000 13:04:57 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D056A@baltimore.com> From: Chris Trobridge To: Helger Lipmaa , ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Date: Fri, 3 Mar 2000 18:10:09 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The main issue with counter mode is the requirement to avoid using the same values twice. This might not sound like much but it's the sort of thing that gives evaluators nightmares. That aside, I agree: it is faster than CBC and easier to synchronise than OFB and most easily implemented in parallel. I can't claim to be a crypto-scholar, but looking over the publication you reference (A Concrete Security Treatment Of Symmetric Encryption: Analysis Of DES modes Of Operation), I'm not convinced that the attacks they mention are particularly viable, at least not in IPSEC case. The attack analysed is chosen plaintext which wouldn't generally be possible. Chris > CBC is most probably used since it is 'an old and proven > standard'. However there is a number of reasons why one would > prefer to > use something else: > > 1. CBC is a serial mode (in encryption). However, in many hardware and > software solutions would would prefer to use a parallel > mode instead. > (pipelined hardware chips, MMX/AltiVec-based implementations, ...) > > Thus CBC mode is unpleasant from an implementer point of view. See, > e.g. http://home.cyber.ee/helger/fastidea/ if you do not believe in > parallel software implementations :-) > > 2. CBC can be attacked by birthday paradox and therefore efficiently > reduces the lifetime of a cipher (think about that: in linear > cryptanalysis you'll need 2^43 plaintext blocks to break > DES itself, > but actually you only need 2^32 plaintext blocks to break > DES in CBC > mode). - that kind of birthday attacks are unavoidable if the > cipher is invertible. > > Thus, CBC mode is unsecure. See recent publications by > Mihir Bellare, > Phil Rogaway etc. > > 3. CBC requires the cipher to be invertible but invertibility makes > ciphers much slower at the same level of security (compare > invertible > block ciphers - DES, IDEA, Rijndael - with non-invertible > MACs - UMAC). > It seems that an additional effort is required from > designers to make > the cipher invertible and still secure. > > Combined with 2, using a non-invertible cipher would be > beneficial both > from security and efficiency point of view and therefore > CBC should be > abandoned if possible. > > Now, would it be possible? It would: use the counter mode. It > is parallel, > does not require a cipher to be invertible, it allows > precomputation etc. > Moreover, it can be used in combination with DES and other invertible > ciphers such that birthday attacks will not apply. It is proven to be > very secure in the case of strong underlying cipher. > > Due to all of this, many cryptographers think that counter mode should > replace CBC mode as a standard. I am myself a very strong supporter > of this, too. > > I am currently writing a draft of an internet draft on > counter mode that > will be finished in a week or two. (If anyone would get a > preview of that, > please directly contact me.) I hope it could then be considered as a > (recommended but not required) part of IPSEC. > > Helger Lipmaa > http://home.cyber.ee/helger > > From owner-ipsec@lists.tislabs.com Fri Mar 3 12:16:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07009; Fri, 3 Mar 2000 12:16:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06211 Fri, 3 Mar 2000 14:02:56 -0500 (EST) Date: Fri, 3 Mar 2000 14:08:34 -0500 Message-Id: <200003031908.OAA09383@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: CTrobridge@baltimore.com Cc: helger@cyber.ee, ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? References: <1FD60AE4DB6CD2118C420008C74C27B81D056A@baltimore.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chris" == Chris Trobridge writes: Chris> The main issue with counter mode is the requirement to avoid Chris> using the same values twice. This might not sound like much Chris> but it's the sort of thing that gives evaluators nightmares. That's a fair issue, but I can't see it being a fatal problem. The same requirement already exists for sequence numbers. As has been mentioned already (a few weeks ago, I think, perhaps in a different venue) you could concatenate the ESP sequence number with the block in packet number to make the counter number. Chris> I can't claim to be a crypto-scholar, but looking over the Chris> publication you reference (A Concrete Security Treatment Of Chris> Symmetric Encryption: Analysis Of DES modes Of Operation), I'm Chris> not convinced that the attacks they mention are particularly Chris> viable, at least not in IPSEC case. The attack analysed is Chris> chosen plaintext which wouldn't generally be possible. I'd be hesitant to assume that chosen plaintext is that hard; in any event, it is one of the current standard tests for the security of a cipher. (If a cipher is secure against known plaintext but not against chosen text attack, that is no longer considered acceptable.) paul From owner-ipsec@lists.tislabs.com Fri Mar 3 12:59:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07541; Fri, 3 Mar 2000 12:59:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06410 Fri, 3 Mar 2000 14:42:04 -0500 (EST) Date: Fri, 3 Mar 2000 14:47:52 -0500 Message-Id: <200003031947.OAA09553@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? References: <1FD60AE4DB6CD2118C420008C74C27B81D056A@baltimore.com> <200003031908.OAA09383@tonga.xedia.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Chris> The main issue with counter mode is the requirement to avoid Chris> using the same values twice. This might not sound like much Chris> but it's the sort of thing that gives evaluators nightmares. >> That's a fair issue, but I can't see it being a fatal problem. >> The same requirement already exists for sequence numbers. As has >> been mentioned already (a few weeks ago, I think, perhaps in a >> different venue) you could concatenate the ESP sequence number >> with the block in packet number to make the counter number. Stephen> It's dangerous for a crypto system to accept a value from Stephen> "outside" as a basis for generating key stream, especially Stephen> for a mode such as this. So, if software in my IPSec system Stephen> maintained the ESP sequence number and handed the formatted Stephen> packet into the crypto, which the made use of that Stephen> externally provided value for counter mode control, I'd Stephen> question the assurance of the resulting encryption system. Stephen> That's one of the reasons why we have discouraged implicit Stephen> IVs for CBC modes. I view the sequence number stuff as part of the crypto system, but I suppose opinions might differ on that. In that case, how about adopting the explicit "IV" approach here as well (where "IV" is actually the high N bits of the counter)? That way the same block that you currently trust to do IVs properly can pass the initial counter value for the block properly. For a lot of implementations that field would then merely be a copy of the sequence number, but you'd be able to source it independently. Then again, if the rule is that it contains a copy of the sequence number, the crypto module can simply check that property rather than taking it on faith. After all, it will be running the header, including that sequence number, through the authentication hash. paul From owner-ipsec@lists.tislabs.com Fri Mar 3 13:03:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07607; Fri, 3 Mar 2000 13:03:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06377 Fri, 3 Mar 2000 14:37:27 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200003031908.OAA09383@tonga.xedia.com> References: <1FD60AE4DB6CD2118C420008C74C27B81D056A@baltimore.com> <200003031908.OAA09383@tonga.xedia.com> Date: Fri, 3 Mar 2000 14:36:42 -0500 To: Paul Koning From: Stephen Kent Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Chris> The main issue with counter mode is the requirement to avoid > Chris> using the same values twice. This might not sound like much > Chris> but it's the sort of thing that gives evaluators nightmares. > >That's a fair issue, but I can't see it being a fatal problem. The >same requirement already exists for sequence numbers. As has been >mentioned already (a few weeks ago, I think, perhaps in a different >venue) you could concatenate the ESP sequence number with the block in >packet number to make the counter number. It's dangerous for a crypto system to accept a value from "outside" as a basis for generating key stream, especially for a mode such as this. So, if software in my IPSec system maintained the ESP sequence number and handed the formatted packet into the crypto, which the made use of that externally provided value for counter mode control, I'd question the assurance of the resulting encryption system. That's one of the reasons why we have discouraged implicit IVs for CBC modes. Steve From owner-ipsec@lists.tislabs.com Fri Mar 3 13:39:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08388; Fri, 3 Mar 2000 13:39:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06525 Fri, 3 Mar 2000 15:27:15 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200003031947.OAA09553@tonga.xedia.com> References: <1FD60AE4DB6CD2118C420008C74C27B81D056A@baltimore.com> <200003031908.OAA09383@tonga.xedia.com> <200003031947.OAA09553@tonga.xedia.com> Date: Fri, 3 Mar 2000 15:33:38 -0500 To: Paul Koning From: Stephen Kent Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, Most crypto modules today do not include this aspect of IPsec, although newer crypto chips that are IPsec specific may do so. Yes, an explicit IV approach for counter mode, where the crypto module is responsible for the IV, is fine. Steve From owner-ipsec@lists.tislabs.com Fri Mar 3 15:10:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09423; Fri, 3 Mar 2000 15:10:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06796 Fri, 3 Mar 2000 17:06:58 -0500 (EST) Date: Fri, 3 Mar 2000 17:12:46 -0500 Message-Id: <200003032212.RAA10480@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: helger@cyber.ee Cc: kent@bbn.com, ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? References: <200003031947.OAA09553@tonga.xedia.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Helger" == Helger Lipmaa writes: Helger> The problem with sequence number concatenated with packet Helger> number used as counters is that some counter space would be Helger> lost: e.g. if sequence numbers are 32-bit numbers and packets Helger> are not longer than 2^16 blocks (where a block could be 8, 16 Helger> or 32 bytes) in length, there would be no more than 2^48 Helger> different counters. Of course, that is still better than the Helger> security of 2^32 offered by the CBC mode. And in this case Helger> more than 2^48 encrypted blocks should not be sent anyways Helger> (otherwise ESP counter would zero again). Any deterministic way of maintaining the counter would have that property for any SA with replay protection, since you're not allowed to send more than 2^32 packets before rekeying and no IP packet is more than 2^16 bytes long. But while that's a *property* of the system, it doesn't strike me as a *problem*. If you had a counter construction rule that limited you to fewer distinct counter values than you might want to use naturally, that would be different -- but that isn't the case here. paul From owner-ipsec@lists.tislabs.com Fri Mar 3 15:13:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09457; Fri, 3 Mar 2000 15:13:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06749 Fri, 3 Mar 2000 17:00:32 -0500 (EST) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Sat, 4 Mar 2000 00:06:20 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: Paul Koning cc: kent@bbn.com, ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? In-Reply-To: <200003031947.OAA09553@tonga.xedia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by lists.tislabs.com id RAA06746 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 3 Mar 2000, Paul Koning wrote: > I view the sequence number stuff as part of the crypto system, but I > suppose opinions might differ on that. In that case, how about > adopting the explicit "IV" approach here as well (where "IV" is > actually the high N bits of the counter)? That way the same block > that you currently trust to do IVs properly can pass the initial > counter value for the block properly. For a lot of implementations > that field would then merely be a copy of the sequence number, but > you'd be able to source it independently. Some remarks. Counter mode is the strongest if you use _every_ counter only once, and if you use (say) keyed hash function (or a designated construction) instead of a block cipher. If you use the counter only once, it does not matter what is the specific order. Chosen IV attacks can break the mode, but that is also the case forthe CBC mode (in the counter mode the result is more devastating however: XOR of every two ciphertext block reveals the XOR of corresponding plaintext blocks. Note that in the case of CBC mode only XOR or the first two ciphertext blocks would reveal the XOR of corresponding plaintext blocks. (so quantitatively, chosen IV attacks are more dangerous against the counter mode than against the CBC mode. however, since also some information would leak out from the CBC mode, using the same IV/counter should be prohibited in both modes). The problem with sequence number concatenated with packet number used as counters is that some counter space would be lost: e.g. if sequence numbers are 32-bit numbers and packets are not longer than 2^16 blocks (where a block could be 8, 16 or 32 bytes) in length, there would be no more than 2^48 different counters. Of course, that is still better than the security of 2^32 offered by the CBC mode. And in this case more than 2^48 encrypted blocks should not be sent anyways (otherwise ESP counter would zero again). Of course, bd paradox can be avoided only if the cipher is non-invertible. Fortunately, a lot of good constructions are known for that. UMAC by Halevi etc could be used for that. Or keyed SHA-1. Or Bellare-Impagliazzo construction based on block ciphers. More in the draft... (which is also going to be submitted as a public comment for the NIST to consider at the AES process). Helger Lipmaa Küberneetika AS http://home.cyber.ee/helger From owner-ipsec@lists.tislabs.com Mon Mar 6 01:21:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA22514; Mon, 6 Mar 2000 01:21:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA13370 Mon, 6 Mar 2000 02:20:08 -0500 (EST) Message-Id: <200003060726.XAA16560@fionn.es.net> To: ipsec@lists.tislabs.com Reply-to: helm@fionn.es.net Subject: ipsec NICs? Date: Sun, 05 Mar 2000 23:26:02 -0800 From: Michael Helm Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is there anyone keeping track of vendors' ipsec-friendly NICs & other networking cards? (not the chrysalis/ncipher type of thing) I heard parts of a few talks about this general area at RSA, and one excellent discussion at the Microsoft W2K launch, & think it's necessary to put at least some crypto support for this set of standards on the hardware in order for it to be practical on a wide scale. But who's supporting it & how? From owner-ipsec@lists.tislabs.com Mon Mar 6 01:34:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA22687; Mon, 6 Mar 2000 01:34:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA13684 Mon, 6 Mar 2000 03:26:31 -0500 (EST) Message-ID: From: Ivars Suba To: "'Helger Lipmaa'" Cc: ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Date: Mon, 6 Mar 2000 10:31:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA13680 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk < -----Original Message----- < From: Helger Lipmaa [mailto:helger@cyber.ee] < Sent: Saturday, March 04, 2000 12:06 AM < To: Paul Koning < Cc: kent@bbn.com; ipsec@lists.tislabs.com < Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like < CFB or OFB ? < < Note that < in the case < of CBC mode only XOR or the first two ciphertext blocks would < reveal the < XOR of corresponding plaintext blocks. < < Helger Lipmaa < Küberneetika AS < http://home.cyber.ee/helger < I think it pertain to CFB mode, not to CBC. I am correct? Ivars Suba From owner-ipsec@lists.tislabs.com Mon Mar 6 05:18:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA28302; Mon, 6 Mar 2000 05:18:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA14382 Mon, 6 Mar 2000 06:59:30 -0500 (EST) Message-Id: <200003061204.VAA02636@orange.ap.paso.fujitsu.co.jp> Date: Mon, 06 Mar 2000 21:05:07 +0900 From: Ichiro MIYAJIMA Subject: Q: SPD & IKE phase2 IDs To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: tsworks E-Mail Ver3.09 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Q: SPD & IKE phase2 IDs I have some questions about SPD & IKE phase2 IDs. Which implementation is better No.1 or No.2 in the example below? In other words, which is 'MUST'? ------------------------------ Example (1)Policy (established by system administrator) IPSEC tunnel ESP(DES,SHA-1)(all traffic) Network1-------VPNGW1============VPNGW2---------Network2 192.168.20.0/24 192.168.21.0/24 | V (2)Security Policy Database (SPD) in VPN GW1 src addr = 192.168.20.0/24 dst addr = 192.168.21.0/24 action = IPSEC ESP(DES,SHA-1) in tunnel mode | V (3)IKE Phase 2(Quick Mode) ID payload generated by VPN GW1(initiator) Network1-------VPNGW1============VPNGW2---------Network2 PC1(192.168.20.5)---> PC2(192.168.21.8) [No.1] : Phase 2(Quick Mode) ID payload IDci = 192.168.20.5 IDcr = 192.168.21.8 ID Type = ID_IPV4_ADDR or [No.2] : Phase 2(Quick Mode) ID payload IDci = 192.168.20.0/24 IDcr = 192.168.21.0/24 ID Type = ID_IPV4_ADDR_SUBNET ------------------------------ I appreciate your help. Regards, Ichiro MIYAJIMA From owner-ipsec@lists.tislabs.com Mon Mar 6 05:56:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA28806; Mon, 6 Mar 2000 05:56:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA14522 Mon, 6 Mar 2000 07:41:59 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D0573@baltimore.com> From: Chris Trobridge To: Paul Koning Cc: ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Date: Mon, 6 Mar 2000 12:47:48 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: 03 March 2000 19:09 > >>>>> "Chris" == Chris Trobridge writes: > > Chris> The main issue with counter mode is the requirement to avoid > Chris> using the same values twice. This might not sound like much > Chris> but it's the sort of thing that gives evaluators nightmares. > > That's a fair issue, but I can't see it being a fatal problem. The > same requirement already exists for sequence numbers. As has been > mentioned already (a few weeks ago, I think, perhaps in a different > venue) you could concatenate the ESP sequence number with the > block in packet number to make the counter number. Re-use of IVs/counters is generally more serious with counter (or OFB) mode than CBC mode. I remember MS recently had a flaw in one of its protocols that enabled the encryption to be broken relatively easily. I'm not aware of the same sort of issues having occurred with CBC. > Chris> I can't claim to be a crypto-scholar, but looking over the > Chris> publication you reference (A Concrete Security Treatment Of > Chris> Symmetric Encryption: Analysis Of DES modes Of Operation), I'm > Chris> not convinced that the attacks they mention are particularly > Chris> viable, at least not in IPSEC case. The attack analysed is > Chris> chosen plaintext which wouldn't generally be possible. > > I'd be hesitant to assume that chosen plaintext is that hard; in any > event, it is one of the current standard tests for the security of a > cipher. (If a cipher is secure against known plaintext but not > against chosen text attack, that is no longer considered acceptable.) > > paul For a plaintext attack, the adversary has to be able to ask you encrypt arbitrary plaintext and return him the corresponding cipher text. In the CBC case he also needs to be able to specify or predict the IV. The text suggests that encrypting the IV would protect against plaintext attack. In any case in an IPSEC system the adversary wouldn't normally have access to both plaintext and ciphertext let alone be able to specify plaintext - the initial portion of plaintext is a header and the IV and payload are protected by a MAC. That said, it's better to have an algorithm that is generally strong rather than just in the assumed operating conditions. Encrypting the (transmitted) IV before use would solve this. Chris From owner-ipsec@lists.tislabs.com Mon Mar 6 06:00:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28859; Mon, 6 Mar 2000 06:00:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA14545 Mon, 6 Mar 2000 07:45:58 -0500 (EST) Message-ID: <38C3A9C3.4B49C72B@indusriver.com> Date: Mon, 06 Mar 2000 07:51:16 -0500 From: Ben McCann MIME-Version: 1.0 To: Ichiro MIYAJIMA CC: ipsec@lists.tislabs.com Subject: Re: Q: SPD & IKE phase2 IDs References: <200003061204.VAA02636@orange.ap.paso.fujitsu.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I interpret RFC2401 to require support for both cases: > [No.1] : > Phase 2(Quick Mode) ID payload > IDci = 192.168.20.5 > IDcr = 192.168.21.8 > ID Type = ID_IPV4_ADDR > > or > > [No.2] : > Phase 2(Quick Mode) ID payload > IDci = 192.168.20.0/24 > IDcr = 192.168.21.0/24 > ID Type = ID_IPV4_ADDR_SUBNET > This is a policy decision made by the administrator that is stored in the policy bound to the SPD rule. A rule can generate new SAD entries that are initialized from the packet (i.e. your case 1) or they can generate an SAD entry that duplicates the filter defined in the SPD (i.e. your case 2). -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Mon Mar 6 06:09:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28946; Mon, 6 Mar 2000 06:09:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA14580 Mon, 6 Mar 2000 07:52:26 -0500 (EST) X-Lotus-FromDomain: COMPUTERM From: "Divya Annamraju" To: helm@fionn.es.net cc: ipsec@lists.tislabs.com Message-ID: <8525689A.004745DD.00@domino_01> Date: Mon, 6 Mar 2000 07:58:28 -0500 Subject: Re: ipsec NICs? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have seen 2 vendors claim they have IPSec NICs - Intel (new generation Pro/100+) and 3Com (3CR990 series). From owner-ipsec@lists.tislabs.com Mon Mar 6 06:40:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29678; Mon, 6 Mar 2000 06:40:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14669 Mon, 6 Mar 2000 08:24:58 -0500 (EST) Message-ID: <71984F8FB76AD211AC3E00A0C9C578C70206F2C5@hasmsx32.iil.intel.com> From: "Elzur, Uri" To: helm@fionn.es.net, ipsec@lists.tislabs.com Subject: RE: ipsec NICs? Date: Mon, 6 Mar 2000 02:53:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi please look at the following URLs http://www.intel.com/network/products/desktop_adapters.htm?iid=netsite+home& http://www.intel.com/network/products/security.htm http://www.intel.com/network/products/pro100smgmt.htm thx Uri Elzur uri.elzur@intel.com -----Original Message----- From: Michael Helm [mailto:helm@fionn.es.net] Sent: Monday, March 06, 2000 9:26 AM To: ipsec@lists.tislabs.com Subject: ipsec NICs? Is there anyone keeping track of vendors' ipsec-friendly NICs & other networking cards? (not the chrysalis/ncipher type of thing) I heard parts of a few talks about this general area at RSA, and one excellent discussion at the Microsoft W2K launch, & think it's necessary to put at least some crypto support for this set of standards on the hardware in order for it to be practical on a wide scale. But who's supporting it & how? From owner-ipsec@lists.tislabs.com Mon Mar 6 06:46:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29768; Mon, 6 Mar 2000 06:46:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14668 Mon, 6 Mar 2000 08:24:52 -0500 (EST) Message-Id: <3.0.5.32.20000306135801.031ff7e0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 06 Mar 2000 13:58:01 +0100 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Q: SPD & IKE phase2 IDs In-Reply-To: <200003061204.VAA02636@orange.ap.paso.fujitsu.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id HAA14559 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 21:05 6.3.2000 +0900, you wrote: >Q: SPD & IKE phase2 IDs > >I have some questions about SPD & IKE phase2 IDs. > >Which implementation is better No.1 or No.2 in the example below? >In other words, which is 'MUST'? > > There is no MUST here. The policy on GW1 might say "Do QM with the nets" or "Do QM only with host pairs". Or the GW1 does not have a policy setting at all, so it does it always in one way or the other. There no "better" here, either. QM with host pair will give an attacker headaches because there's a lot keys to crack and less traffic per SA. On the other hand, You might get _a_lot_ of QMs, and memory consumption goes up. We have a setting for this, it even goes down to protocols and ports, so if send a ping, the GW1 will only make a QM for ICMP. Only useful for stress tests, really. The same problem appears on the responder side, it is a common implementation (at the interops, anyway) to allow QM to a subnet of the configured net. So even if GW2 would do QM with 192.168.20.0/28 to 192.168.21.1-192.168.21.5, GW1 would accept that. Jörn From owner-ipsec@lists.tislabs.com Mon Mar 6 08:28:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01960; Mon, 6 Mar 2000 08:28:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15198 Mon, 6 Mar 2000 10:08:14 -0500 (EST) Date: Mon, 6 Mar 2000 10:14:06 -0500 Message-Id: <200003061514.KAA26292@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: helm@fionn.es.net Cc: ipsec@lists.tislabs.com Subject: Re: ipsec NICs? References: <200003060726.XAA16560@fionn.es.net> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Helm writes: Michael> Is there anyone keeping track of vendors' ipsec-friendly Michael> NICs & other networking cards? (not the chrysalis/ncipher Michael> type of thing) I heard parts of a few talks about this Michael> general area at RSA, and one excellent discussion at the Michael> Microsoft W2K launch, & think it's necessary to put at least Michael> some crypto support for this set of standards on the Michael> hardware in order for it to be practical on a wide scale. I don't think so. Given that you're not talking about crypto hardware engines but just about plain NICs (with the crypto done elsewhere) there are *no* special requirements imposed on the NICs that I can see. Certainly I have seen no reason to add any in the IPSec projects I have worked on. Or are you saying that IPSec isn't practical without crypto hardware assist? If so, I would agree at the high end (DS3 rates and above) but not at more modest data rates. Could you elaborate on what you heard that led you to this conclusion? paul From owner-ipsec@lists.tislabs.com Mon Mar 6 09:16:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02847; Mon, 6 Mar 2000 09:16:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15427 Mon, 6 Mar 2000 11:01:09 -0500 (EST) Message-ID: <95A2AF8E4643D211941A00805FE6BE4802865986@exchny18.sbi.com> From: "Mintz, Erik" To: "'ipsec@lists.tislabs.com'" Subject: Virtual adapters Date: Mon, 6 Mar 2000 11:05:04 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello All, I have a question regarding the use of virtual adapters, or 'shims' in ipsec VPN implementations. I have heard comments against the use of a virtual adapter. My requirement is for corporate remote access. I was hoping I could get some opinions here, or perhaps someone could point me to a more appropriate resource? Thanks, Erik Mintz Mobile computing group Technology architecture and engineering Salomon Smith Barney 212-816-3138, 816-0489 pager, www.mobilecomm.com pin# 96027 From owner-ipsec@lists.tislabs.com Mon Mar 6 09:16:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02859; Mon, 6 Mar 2000 09:16:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15359 Mon, 6 Mar 2000 10:47:17 -0500 (EST) From: "Josef Pojsl" Date: Mon, 6 Mar 2000 16:53:11 +0100 To: Michael Helm Cc: ipsec@lists.tislabs.com Subject: Re: ipsec NICs? Message-ID: <20000306165311.E6735@regent.in.skynet.cz> References: <200003060726.XAA16560@fionn.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.1i In-Reply-To: <200003060726.XAA16560@fionn.es.net>; from helm@fionn.es.net on Sun, Mar 05, 2000 at 11:26:02PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RedCreek has an IPSec card called Ravlin, see http://www.redcreek.com/products/ipsec.html They claim to support Linux too. Regards, Josef On Sun, Mar 05, 2000 at 11:26:02PM -0800, Michael Helm wrote: > > Is there anyone keeping track of vendors' ipsec-friendly > NICs & other networking cards? (not the chrysalis/ncipher > type of thing) I heard parts of a few talks about this > general area at RSA, and one excellent discussion at > the Microsoft W2K launch, & think it's necessary to put > at least some crypto support for this set of standards > on the hardware in order for it to be practical on a wide > scale. But who's supporting it & how? From owner-ipsec@lists.tislabs.com Mon Mar 6 10:31:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04200; Mon, 6 Mar 2000 10:31:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15611 Mon, 6 Mar 2000 11:44:17 -0500 (EST) Date: Mon, 6 Mar 2000 08:05:16 -0500 (EST) From: Henry Spencer To: Michael Helm cc: ipsec@lists.tislabs.com Subject: Re: ipsec NICs? In-Reply-To: <200003060726.XAA16560@fionn.es.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 5 Mar 2000, Michael Helm wrote: > Is there anyone keeping track of vendors' ipsec-friendly > NICs & other networking cards? ... think it's necessary to put > at least some crypto support for this set of standards > on the hardware in order for it to be practical on a wide > scale. Why? The commodity processors (200MHz Pentiums and the like) currently being *thrown out* in favor of newer ones will do IPSEC using 3DES -- a software-unfriendly algorithm if there ever was one -- and MD5 at several megabits per second. (I'm talking about measured end-to-end data rates with real protocols, mind you, not theoretical calculations.) High-end consumer-market processors with software-optimized algorithms should take this up into the T3 range. These standards are practical on cheap, commodity computers right now. Only people with very fat pipes have a real need for crypto hardware. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 6 11:10:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05078; Mon, 6 Mar 2000 11:10:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15870 Mon, 6 Mar 2000 12:45:02 -0500 (EST) Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB20344B5F6@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'Henry Spencer'" , Michael Helm Cc: ipsec@lists.tislabs.com Subject: RE: ipsec NICs? Date: Mon, 6 Mar 2000 09:49:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The problem is that a few Mbits/sec are not fast enough for intranet cases. While crypto acceleration isn't really necessary for WAN cases where people are connecting through modems, DSL, T1 speeds, within intranets people are wanting to talk at 100Mbit/Sec, soon to be 1Gbit/Sec for servers. In these cases it makes a LOT of sense to throw a cheap crypto accelerator at the problem rather than multiple General Purpose CPUs Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Monday, March 06, 2000 5:05 AM > To: Michael Helm > Cc: ipsec@lists.tislabs.com > Subject: Re: ipsec NICs? > > > On Sun, 5 Mar 2000, Michael Helm wrote: > > Is there anyone keeping track of vendors' ipsec-friendly > > NICs & other networking cards? ... think it's necessary to put > > at least some crypto support for this set of standards > > on the hardware in order for it to be practical on a wide > > scale. > > Why? The commodity processors (200MHz Pentiums and the like) > currently > being *thrown out* in favor of newer ones will do IPSEC using > 3DES -- a > software-unfriendly algorithm if there ever was one -- and > MD5 at several > megabits per second. (I'm talking about measured end-to-end > data rates > with real protocols, mind you, not theoretical calculations.) > High-end > consumer-market processors with software-optimized algorithms > should take > this up into the T3 range. > > These standards are practical on cheap, commodity computers right now. > Only people with very fat pipes have a real need for crypto hardware. > > > Henry Spencer > > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Mon Mar 6 15:03:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08958; Mon, 6 Mar 2000 15:03:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16706 Mon, 6 Mar 2000 16:35:11 -0500 (EST) Date: Mon, 6 Mar 2000 16:40:31 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: ipsec NICs? In-Reply-To: <7DAA70BEB463D211AC3E00A0C96B7AB20344B5F6@orsmsx41.jf.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 6 Mar 2000, Strahm, Bill wrote: > While crypto acceleration isn't really necessary for WAN cases where people > are connecting through modems, DSL, T1 speeds, within intranets people are > wanting to talk at 100Mbit/Sec, soon to be 1Gbit/Sec for servers. Good point. While I have my doubts about the necessity of that, that's another battle, and there's no question that people *want* to talk at those speeds. Filling those pipes is quite a challenge by itself, though. > In these cases it makes a LOT of sense to throw a cheap crypto accelerator > at the problem rather than multiple General Purpose CPUs I guess my general point is, one should remember that fast general-purpose CPUs are *no longer expensive*. It is quite reasonable to throw CPUs at problems which would have called for hardware solutions only a few years ago. A crypto accelerator has to be very fast or very cheap, preferably both, to be worth the trouble. If it runs at a few tens of megabits and costs a thousand dollars, you're probably better off with CPUs. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 6 15:57:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09792; Mon, 6 Mar 2000 15:57:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16934 Mon, 6 Mar 2000 17:48:55 -0500 (EST) Message-ID: <38C437F4.3C7A71EF@cisco.com> Date: Mon, 06 Mar 2000 14:57:56 -0800 From: "David A. McGrew" X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Helger Lipmaa CC: ipsec@lists.tislabs.com Subject: Re: Q: Why IPSEC to be used only in CBC mode & not other like CFBor OFB ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Rupesh, Helger, Helger Lipmaa wrote: > > On Fri, 25 Feb 2000, rupesh wrote: > > > I had read nearly all RFC'c of Ipsec , everywhere it talks about CBC > > mode implementation only. why Ipsec should not be used in other modes > > like CFB or OFB ? Please anyone can give me answer to above question > > or forward me a link..... > there are some attacks to which stream ciphers, and ECB, OFB, and counter modes are more vulnerable than CBC mode. Biham's key collision attack and Hellman's time-memory tradeoff attack are both described as attacks on ECB mode block ciphers, though they can be applied to all of the ciphers/modes mentioned above. Hellman's attack uses precomputation to amortize the computational cost of finding a secret key over multiple attacks, significantly lowering the average cost of an attack. Biham's attack works when the same plaintext is encrypted under many distinct keys, and can find a secret key with significant advantage over exhaustive search when many ciphertexts are available. Biham described his attack in a paper called "How to forge DES encrypted messages with O(2^28) work". This paper is available on his website at http://www.cs.technion.ac.il/~biham/. Hellman's attack originally appeared in his paper in IEEE Transactions on Information Theory circa 1979, and it is not available online. Stinson's book "Cryptography: Theory and Practice" describes how that attack works. I am currently working on an analysis of these attacks for IPSEC, in support of an upcoming stream cipher encryption draft for IPSEC. > CBC is most probably used since it is 'an old and proven > standard'. However there is a number of reasons why one would prefer to > use something else: > > 1. CBC is a serial mode (in encryption). However, in many hardware and > software solutions would would prefer to use a parallel mode instead. > (pipelined hardware chips, MMX/AltiVec-based implementations, ...) > > Thus CBC mode is unpleasant from an implementer point of view. See, > e.g. http://home.cyber.ee/helger/fastidea/ if you do not believe in > parallel software implementations :-) > > 2. CBC can be attacked by birthday paradox and therefore efficiently > reduces the lifetime of a cipher (think about that: in linear > cryptanalysis you'll need 2^43 plaintext blocks to break DES itself, > but actually you only need 2^32 plaintext blocks to break DES in CBC > mode). - that kind of birthday attacks are unavoidable if the > cipher is invertible. > > Thus, CBC mode is unsecure. See recent publications by Mihir Bellare, > Phil Rogaway etc. As has already been pointed out, the O(2^32) attack against CBC is a chosen plaintext attack, and it only recovers a small number of unknown plaintext blocks. It is a potential threat, though a minor one that is easily defended against by limiting the number of blocks encrypted under a single key. > > 3. CBC requires the cipher to be invertible but invertibility makes > ciphers much slower at the same level of security (compare invertible > block ciphers - DES, IDEA, Rijndael - with non-invertible MACs - UMAC). > It seems that an additional effort is required from designers to make > the cipher invertible and still secure. > Agreed. Secure stream ciphers appear to be faster than secure block ciphers. > Combined with 2, using a non-invertible cipher would be beneficial both > from security and efficiency point of view and therefore CBC should be > abandoned if possible. > > Now, would it be possible? It would: use the counter mode. It is parallel, > does not require a cipher to be invertible, it allows precomputation etc. > Moreover, it can be used in combination with DES and other invertible > ciphers such that birthday attacks will not apply. It is proven to be > very secure in the case of strong underlying cipher. > > Due to all of this, many cryptographers think that counter mode should > replace CBC mode as a standard. I am myself a very strong supporter > of this, too. > > I am currently writing a draft of an internet draft on counter mode that > will be finished in a week or two. (If anyone would get a preview of that, > please directly contact me.) I hope it could then be considered as a > (recommended but not required) part of IPSEC. > > Helger Lipmaa > http://home.cyber.ee/helger I would like to read your draft. Could you please forward me a copy? thanks, David mcgrew@cisco.com From owner-ipsec@lists.tislabs.com Mon Mar 6 19:32:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA20183; Mon, 6 Mar 2000 19:32:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17756 Mon, 6 Mar 2000 21:12:57 -0500 (EST) From: Black_David@emc.com Message-ID: <0F31E5C394DAD311B60C00E029101A070710F1@mxclsk.isus.emc.com> To: ipsec@lists.tislabs.com Subject: RE: ipsec NICs? Date: Mon, 6 Mar 2000 21:18:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > While crypto acceleration isn't really necessary for WAN cases where people > > are connecting through modems, DSL, T1 speeds, within intranets people are > > wanting to talk at 100Mbit/Sec, soon to be 1Gbit/Sec for servers. > > Good point. While I have my doubts about the necessity of that, that's > another battle, and there's no question that people *want* to talk at > those speeds. Filling those pipes is quite a challenge by itself, though. That depends on what one has for hardware, and how many of them. We have customers running at "those speeds" (n x 100 Mbit/sec) over MAN and WAN distances today for remote storage mirroring. Needless to say, the "last mile" is not modem, DSL or T1 ;-). Much of that traffic is not currently running on IP, but the technology exists to change that. IPsec is clearly of interest for this sort of content at "those speeds". --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com Cellular: +1 (978) 394-7754 --------------------------------------------------- From owner-ipsec@lists.tislabs.com Tue Mar 7 02:23:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA07692; Tue, 7 Mar 2000 02:23:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA20221 Tue, 7 Mar 2000 03:58:24 -0500 (EST) X-Lotus-FromDomain: 3COM From: "Philippe Piemont" To: helm@fionn.es.net cc: ipsec@lists.tislabs.com Message-ID: <8025689B.00333A00.00@notesmta.eur.3com.com> Date: Tue, 7 Mar 2000 10:04:23 +0100 Subject: Re: ipsec NICs? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Michael 3Com has 2 IPSec NIC cards working as normal NIC cards exept when the IPSec client asks to encrypt a conversation: the family name is 3CR990 one is dedicated for the servers with all the advanced server functionnalities. one for the desktops Regards Philippe ---------------------- Forwarded by Philippe Piemont/FR/3Com on 07/03/2000 09:58 --------------------------- "Josef Pojsl" on 06/03/2000 15:53:11 Sent by: "Josef Pojsl" To: Michael Helm cc: ipsec@lists.tislabs.com (Philippe Piemont/FR/3Com) Subject: Re: ipsec NICs? RedCreek has an IPSec card called Ravlin, see http://www.redcreek.com/products/ipsec.html They claim to support Linux too. Regards, Josef On Sun, Mar 05, 2000 at 11:26:02PM -0800, Michael Helm wrote: > > Is there anyone keeping track of vendors' ipsec-friendly > NICs & other networking cards? (not the chrysalis/ncipher > type of thing) I heard parts of a few talks about this > general area at RSA, and one excellent discussion at > the Microsoft W2K launch, & think it's necessary to put > at least some crypto support for this set of standards > on the hardware in order for it to be practical on a wide > scale. But who's supporting it & how? From owner-ipsec@lists.tislabs.com Tue Mar 7 03:27:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA11694; Tue, 7 Mar 2000 03:27:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA20571 Tue, 7 Mar 2000 05:07:37 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D0580@baltimore.com> From: Chris Trobridge To: Helger Lipmaa Cc: ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Date: Tue, 7 Mar 2000 10:13:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Helger Lipmaa [mailto:helger@cyber.ee] > Sent: 03 March 2000 22:06 > To: Paul Koning > Cc: kent@bbn.com; ipsec@lists.tislabs.com > Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like > CFB or OFB ? > > The problem with sequence number concatenated with packet number used as > counters is that some counter space would be lost: e.g. if sequence > numbers are 32-bit numbers and packets are not longer than 2^16 blocks > (where a block could be 8, 16 or 32 bytes) in length, there would be no > more than 2^48 different counters. Of course, that is still better than > the security of 2^32 offered by the CBC mode. And in this case more than > 2^48 encrypted blocks should not be sent anyways (otherwise ESP counter > would zero again). This isn't really a problem - sequence numbers are forbidden to repeat already, as they're used to defend aganist replay attacks. Due to the nature of IP (loss, duplication, re-ordering of datagrams) the receiver needs to be able to determine the IV independently of any other datagrams received. An explicit IV provides this, so does a suitable multiple of the sequence number. It does reinforce the advantages of authentication in ESP. I don't know if I've come to the point of assuming ESP authentication is pretty much essential through this group or though discussions with customers, but what do others think? Chris From owner-ipsec@lists.tislabs.com Tue Mar 7 06:41:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15412; Tue, 7 Mar 2000 06:41:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21528 Tue, 7 Mar 2000 08:24:15 -0500 (EST) Message-ID: <71984F8FB76AD211AC3E00A0C9C578C70206F4C4@hasmsx32.iil.intel.com> From: "Elzur, Uri" To: Henry Spencer , Michael Helm Cc: ipsec@lists.tislabs.com Subject: RE: ipsec NICs? Date: Mon, 6 Mar 2000 13:08:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Several examples might be Enterprise LAN with 100Mbs (and more in the future), Servers with 100/1G or backbone resident devices. Pls note that when a CPU is overloaded with Enc/Dec or Auth that overcome its power, it will not only neglect other application but might also bring the network connection to a grinding slow speeds. thx Uri Elzur uri.elzur@intel.com -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Monday, March 06, 2000 3:05 PM To: Michael Helm Cc: ipsec@lists.tislabs.com Subject: Re: ipsec NICs? On Sun, 5 Mar 2000, Michael Helm wrote: > Is there anyone keeping track of vendors' ipsec-friendly > NICs & other networking cards? ... think it's necessary to put > at least some crypto support for this set of standards > on the hardware in order for it to be practical on a wide > scale. Why? The commodity processors (200MHz Pentiums and the like) currently being *thrown out* in favor of newer ones will do IPSEC using 3DES -- a software-unfriendly algorithm if there ever was one -- and MD5 at several megabits per second. (I'm talking about measured end-to-end data rates with real protocols, mind you, not theoretical calculations.) High-end consumer-market processors with software-optimized algorithms should take this up into the T3 range. These standards are practical on cheap, commodity computers right now. Only people with very fat pipes have a real need for crypto hardware. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Mar 7 06:41:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA15411; Tue, 7 Mar 2000 06:41:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21529 Tue, 7 Mar 2000 08:24:15 -0500 (EST) Date: 6 Mar 2000 18:31:10 -0000 Message-ID: <20000306183110.11253.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipsec@lists.tislabs.com Subject: Re: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? References: <000b01bf7f84$6873e6a0$2dcd09c0@nig95> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Helger Lipmaa writes: > (compare invertible block ciphers - DES, IDEA, Rijndael - with > non-invertible MACs - UMAC). Apples and oranges. Data encryption needs a large amount of unpredictable output. MACs produce only a small amount of output. Note also that the UMAC advertisements are (1) at a trivially breakable security level and (2) for absurdly long packets. At a serious security level, for common packet sizes, UMAC simply uses HMAC-MD5. The MAC described in http://cr.yp.to/papers/hash127.ps is simpler and faster. Anyway, I agree that cipher invertibility is unnecessary for encryption, and is a distraction from the crucial property of unpredictability. ---Dan From owner-ipsec@lists.tislabs.com Tue Mar 7 07:57:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17158; Tue, 7 Mar 2000 07:57:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21923 Tue, 7 Mar 2000 09:33:38 -0500 (EST) From: "Fabio Zamparelli" To: "Philippe Piemont" Cc: Subject: R: ipsec NICs? 3com? Date: Tue, 7 Mar 2000 15:38:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <8025689B.00333A00.00@notesmta.eur.3com.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Messaggio originale----- > Da: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]Per conto di Philippe Piemont > Inviato: martedì 7 marzo 2000 10.04 > A: helm@fionn.es.net > Cc: ipsec@lists.tislabs.com > Oggetto: Re: ipsec NICs? > > > > > Hi Michael > > 3Com has 2 IPSec NIC cards working as normal NIC cards exept when > the IPSec > client asks to encrypt a conversation: the family name is 3CR990 > one is dedicated for the servers with all the advanced server > functionnalities. > one for the desktops > Regards > Philippe Very intersesting. I hope my university will buy at least two 'IPSec Nics' to do some testings ASAP. I think the test bed will be win2k to be able to test both host2host and tunneling configurations. Do you know if 3com's fastethernet products have win2k-IPSec compliant caracteristics similar to intel? How they fit with Microsoft tcp/ip(sec) stack? I try to find out something on 3com site but I think the docs to be not so updated. Any link to updated technical whitepapers? Thanks, Fabio Zed Zamparelli From owner-ipsec@lists.tislabs.com Tue Mar 7 08:56:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18155; Tue, 7 Mar 2000 08:56:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22285 Tue, 7 Mar 2000 10:44:27 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14533.9393.147854.568862@thomasm-u1.cisco.com> Date: Tue, 7 Mar 2000 07:48:01 -0800 (PST) To: "Elzur, Uri" Cc: Henry Spencer , Michael Helm , ipsec@lists.tislabs.com Subject: RE: ipsec NICs? In-Reply-To: <71984F8FB76AD211AC3E00A0C9C578C70206F4C4@hasmsx32.iil.intel.com> References: <71984F8FB76AD211AC3E00A0C9C578C70206F4C4@hasmsx32.iil.intel.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 Elzur, Uri writes: > Several examples might be Enterprise LAN with 100Mbs (and more in the > future), Servers with 100/1G or backbone resident devices. Pls note that > when a CPU is overloaded with Enc/Dec or Auth that overcome its power, it > will not only neglect other application but might also bring the network > connection to a grinding slow speeds. Then you wait for Moore's law to catch up? After years of watching the best intentioned accelerators being consumed by brute force and ignorance (eg faster main CPU's), I tend to agree with Henry's comment below -- though there's usually a window when such beasts are at least plausible. What I want to know is whether the current crop of accelerators can handle tens of thousands of simultaneous SA's, all with low but bursty output. I'm not sure where the accelerators keep the SA context, but if it's actually in the accelerator itself that's an awful lot of RAM. If it's on the bus, I'd be concerned about bus contention with the main CPU. BTW, this situation is common with high fan out client based systems which want to maintain medium term to indefinite SA's to a server -- like residential telephony. Since crypto is the exception instead of the norm on the net today, this may be the tip of the iceburg. Mike > > thx > > Uri Elzur > uri.elzur@intel.com > > > > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Monday, March 06, 2000 3:05 PM > To: Michael Helm > Cc: ipsec@lists.tislabs.com > Subject: Re: ipsec NICs? > > > On Sun, 5 Mar 2000, Michael Helm wrote: > > Is there anyone keeping track of vendors' ipsec-friendly > > NICs & other networking cards? ... think it's necessary to put > > at least some crypto support for this set of standards > > on the hardware in order for it to be practical on a wide > > scale. > > Why? The commodity processors (200MHz Pentiums and the like) currently > being *thrown out* in favor of newer ones will do IPSEC using 3DES -- a > software-unfriendly algorithm if there ever was one -- and MD5 at several > megabits per second. (I'm talking about measured end-to-end data rates > with real protocols, mind you, not theoretical calculations.) High-end > consumer-market processors with software-optimized algorithms should take > this up into the T3 range. > > These standards are practical on cheap, commodity computers right now. > Only people with very fat pipes have a real need for crypto hardware. > > Henry Spencer > henry@spsystems.net > > > > > > From owner-ipsec@lists.tislabs.com Tue Mar 7 08:56:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18167; Tue, 7 Mar 2000 08:56:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22279 Tue, 7 Mar 2000 10:43:24 -0500 (EST) Message-ID: <38C44A8D.83D9E912@ewd.3com.com> Date: Mon, 06 Mar 2000 16:17:17 -0800 From: Jeff Fowler X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henry Spencer CC: IP Security List Subject: Re: ipsec NICs? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 6 Mar 2000, Henry Spencer wrote: > I guess my general point is, one should remember that fast general-purpose > CPUs are *no longer expensive*. It is quite reasonable to throw CPUs at > problems which would have called for hardware solutions only a few years > ago. A crypto accelerator has to be very fast or very cheap, preferably > both, to be worth the trouble. If it runs at a few tens of megabits and > costs a thousand dollars, you're probably better off with CPUs. > The new 3Com 3CR9990 10/100 Ethernet NIC supports Windows 2000 IPSec offload at rates of up 90 megabits/sec when using ESP with 3DES+MD5 and it costs between $120-140. IPSec crypto offloading to a NIC also significantly improves the host system CPU utilization when doing 3DES. We have seen CPU utilization drop from over 80% to 20% when Windows 2000 ESP-3DES is offloaded to the 3CR9990 NIC. Jeff Fowler jeff_fowler@3com.com From owner-ipsec@lists.tislabs.com Tue Mar 7 08:56:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18189; Tue, 7 Mar 2000 08:56:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22280 Tue, 7 Mar 2000 10:43:25 -0500 (EST) Date: Mon, 6 Mar 2000 23:51:49 +0200 (EET) Message-Id: <200003062151.XAA13706@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: Mika Kojo To: Markku-Juhani Saarinen Cc: kivinen@ssh.fi, ipsec@lists.tislabs.com Subject: Re: Proposal for new DH Groups 6, 7, and 8 In-Reply-To: References: <200002061952.VAA22875@torni.ssh.fi> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security, Finland Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA16768 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear list, Markku-Juhani asked for ECPP primality proofs for the 2048, 3072 and 4096 bit primes. They can be found at http://people.ssh.fi/mkojo/ I apologize for the delay. Best regards, Mika Kojo SSH Communications Security Ltd. Markku-Juhani Saarinen writes: > On Sun, 6 Feb 2000, Tero Kivinen wrote: > > > I sent at least the 2048 bit prime to the list earlier, here is the > > values of the index t for those 2048, 3072 and 4096 bit primes: > > > > < n, t >: (n = number of bits in prime, t = offset from the pi) > > ---------------------------------------------------------------------- > > < 2048, 124476 > > > < 3072, 1690314 > > > < 4096, 240904 > > > ---------------------------------------------------------------------- > (..) > > Tero and others, > > I propose the following minimum exponent sizes to be used with the > bigger DH MODP groups: > > Prime Strength Exponent > --------- -------- -------- > 2048 bits 90 bits 180 bits > 3076 bits 112 bits 224 bits > 4096 bits 128 bits 256 bits > > I have independently verified that your (and Mika's) primes satisfy > all requirements given in RFCs 2412 and 2409. Perhaps it would > good also to publish the primality proofs (i.e. ECPP certificates). > > A brief discussion of minimum exponent sizes w.r.t. DH group strength > is included below. > > - mj > > Markku-Juhani O. Saarinen University of Jyväskylä, Finland > > > Rationale > --------- > > There are two distinct ways to attack Diffie-Hellman key agreement > in a prime field of order p, where p is a Sophie-Germain prime > (i.e. (p-1)/2 is also a prime) [1]: > > 1) Use Pollard's Lambda method to compute discrete logarithms. The > asymptotic complexity of this method is O(sqrt(e)), where e is > the exponent [2]. Hence the exponent size must be at least > twice the required security level. > > 2) Compute discrete logarithms in the prime field using the number > field sieve method (NFS). The conjectured complexity of this method > is: > > L_p[0.3333, 1.9223], > > where L_p is the commonly used notation [3]: > > L_p[a, b] = exp(b*(log(p))^a * (log(log(p)))^(1-a)) > > We can estimate the NFS constant factor using results presented > in [4], where a logarithm was computed in a 427-bit field in > roughly 2^46 steps. This constant factor also matches the strength > estimates given in RFC 2412 (sect 2.11.1). > > The following graph illustrates strength / modulus relationship: > > Strength > |'''''''''''''''''''''''''''''''''''''''''''''''''''''''''__xx"" > 160 | __xxx"" | > 152 | __xx"" | > 144 | _xx"" | > 136 | __xx"" | > 128 | _xx" | > 120 | __x"" | > 112 | _x" | > 104 | _x"" | > 96 | _x" | > 88 | _x" | > 80 | x" | > 72 | x" | > 64 | x" | > 56 | _" | > 48 | x | > 40 | x | > 32 |x | > 16 | | > 8 x | > 0 | | > ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, > 0 1024 2048 3072 4096 5120 6144 7168 8192 > Modulus size (bits) > > References > ---------- > > [1] P. C. van Oorschot and M. J. Wiener, "On Diffie-Hellman key agreement > with short exponents,", proceedings of EuroCrypt '96, > Springer 1996, pp. 332--343 > > [2] J. M. Pollard, "Monte Carlo methods for index computation (mod p)," > Math. Comp., vol. 32, no. 143 (July 1978), pp. 918--924 > > [3] D. Weber, "An Implementation of the General Number Field Sieve > to Compute Discrete Logarithms (mod p),", proceedings of EuroCrypt > '95, Springer 1995, pp. 95--105 > > [4] D. Weber and T. Denny, "The Solution of McCurley's Discrete Log > Challenge," proceedings of EuroCrypt '98, Springer 1998 > > From owner-ipsec@lists.tislabs.com Tue Mar 7 09:02:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18288; Tue, 7 Mar 2000 09:02:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22325 Tue, 7 Mar 2000 10:50:34 -0500 (EST) Date: Tue, 7 Mar 2000 10:56:17 -0500 Message-Id: <200003071556.KAA06133@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: CTrobridge@baltimore.com Cc: helger@cyber.ee, ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? References: <1FD60AE4DB6CD2118C420008C74C27B81D0580@baltimore.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chris" == Chris Trobridge writes: Chris> It does reinforce the advantages of authentication in ESP. I Chris> don't know if I've come to the point of assuming ESP Chris> authentication is pretty much essential through this group or Chris> though discussions with customers, but what do others think? I've been convinced by Steve Bellovin's papers that it is essential. Unfortunately, we're not currently allowed to reject ESP with null authenticaton. As far as I'm concerned, that's a bug, but unfortunately some feel differently. We're definitely telling people in documentation not to skip authentication. Both in software and hardware, there is no performance justification for omitting authentication. paul From owner-ipsec@lists.tislabs.com Tue Mar 7 09:34:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18907; Tue, 7 Mar 2000 09:34:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22623 Tue, 7 Mar 2000 11:24:14 -0500 (EST) From: "Bob Doud" To: "Paul Koning" , Cc: Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Date: Tue, 7 Mar 2000 11:31:27 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200003071556.KAA06133@tonga.xedia.com> X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Of course, one argument for ESP, Null Auth is when you are bundling it with AH. That way, you pick up the authentication of the outer IP header, without duplicating the ICV's twice. Bob > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Koning > Sent: Tuesday, March 07, 2000 10:56 AM > To: CTrobridge@baltimore.com > Cc: helger@cyber.ee; ipsec@lists.tislabs.com > Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like > CFB or OFB ? > > > >>>>> "Chris" == Chris Trobridge writes: > > Chris> It does reinforce the advantages of authentication in ESP. I > Chris> don't know if I've come to the point of assuming ESP > Chris> authentication is pretty much essential through this group or > Chris> though discussions with customers, but what do others think? > > I've been convinced by Steve Bellovin's papers that it is essential. > Unfortunately, we're not currently allowed to reject ESP with null > authenticaton. As far as I'm concerned, that's a bug, but > unfortunately some feel differently. We're definitely telling people > in documentation not to skip authentication. > > Both in software and hardware, there is no performance justification > for omitting authentication. > > paul > > From owner-ipsec@lists.tislabs.com Tue Mar 7 10:17:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19630; Tue, 7 Mar 2000 10:17:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22930 Tue, 7 Mar 2000 11:49:26 -0500 (EST) Date: Tue, 7 Mar 2000 18:55:10 +0200 (EET) Message-Id: <200003071655.SAA23058@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Cc: "'Chris Trobridge'" , "'Andrew Krywaniuk'" , "'IPSEC Mailing List @ tis labs'" Subject: RE: Use of Encryption in Heartbeat Packets In-Reply-To: <006101bf830a$020c37d0$1e0101c8@ANDREWK2.TIMESTEP> References: <1FD60AE4DB6CD2118C420008C74C27B81D0518@baltimore.com> <006101bf830a$020c37d0$1e0101c8@ANDREWK2.TIMESTEP> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 41 min X-Total-Time: 227 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk writes: > Encryption does provide a "quick authentication check." I disagree this. I don't think it is going to be faster for any packet size in normal operation, and for slow ciphers it is going to be very much slower. On the other hand the saving offered by it are quite small compared to the doing the real MAC in the first place. What you are comparing is the speed of 1) HASH(Last-CBC-Block || Message-ID) + Decrypt(1st-block) to the speed of the 2) HMAC-HASH(Rest of the packet) to do the first check, and then in the case 1 you need to do also the Decrypt(rest of the packet after 1st block) + HMAC-HASH(Rest of the packet). Here the case 1 is the encrypted packet having MAC inside the encrypted part and the sequence number in the first block so random packets can be discarded after decrypting that one block. The case 2 is when the packet has only MAC, and no encryption at all. If you don't have any spi's in the packet the packet "Rest of the packet" is going to be only the notify payload (12 + 16 = 28 bytes). So the packet in total is 28 bytes of header + 8 bytes of sequence number + 20 bytes of hash + 28 bytes of notify. The total length is going to be 84 bytes, and the encrypted part of it is 56 bytes. The authenticated part of the message is 28 bytes. If we assume IKE SA is using 3des-md5, then the speeds are about following: 1) md5(last-cbc-block || message-id) = 6 ms 3des-cbc of one block = 20 ms 3des-cbc of the rest of the blocks = 119 ms in total it is going to be 26 ms + 119 ms + 30 ms. 2) Hmac-md5 of 64 bytes = 30 ms. I.e in the DoS case you are saving for only the 4 ms, but in addition you need to do the extra decryption for the rest of the packet, so for each valid packet you waste 145 ms (total decryption time + the IV generation time). If the packet contains 200 byte spi list payload also, then the timing is going to be: 1) md5(last-cbc-block || message-id) = 6 ms 3des-cbc of one block = 20 ms 3des-cbc of the rest of the blocks = 614 ms in total it is going to be 26 ms + 614 ms + 30 ms. 2) Hmac-md5 of 256 bytes = 57 ms I.e in the DoS case you are saving for for 31 ms, but you are then wasting the 640 ms for each valid packet. For blowfish-cbc and md5 the values in the case 1 are little bit different: 1) md5(last-cbc-block || message-id) = 6 ms blowfish-cbc of one block = 4 ms blowfish-cbc of the rest of the blocks = 18 ms So for the DoS case you save 20 ms for the DoS packet and do only 28 ms extra work for valid packet. For the larger packet the numbers are: 1) md5(last-cbc-block || message-id) = 6 ms blowfish-cbc of one block = 4 ms blowfish-cbc of the rest of the blocks = 95 ms And for DoS case you save 47 ms, and you loose 105 ms in the valid packet case. > In formal-speak, encryption provides an O(1) authentication check of a NbnS > indicator of packet validity. (NbnS = Necessary, but not Sufficient) Yes, the time is O(1), but the constant factor is quite large (one hash for the iv and one cbc decryption) compared to the only hmac-hash for the rest of the packet. In the DoS case the saving of the cpu is quite small, but in the valid packet case the wasting of the cpu is quite large. For the faster cipher the numbers are not that bad, but you still waste quite a lot of cpu time for valid packets. I think the gain you get for decrypting the first cbc block first and checking the sequence number first is not enought to justify the wasting of the cpu time for normal valid packets. Ps. The numbers are from our crypto library using 500 MHz alpha. For the hardware accelerated case the overhead of starting the decryption etc is propably also going to play important role. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Mar 7 10:18:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19651; Tue, 7 Mar 2000 10:18:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23515 Tue, 7 Mar 2000 12:07:48 -0500 (EST) Date: Tue, 7 Mar 2000 12:13:38 -0500 Message-Id: <200003071713.MAA08064@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bdoud@ire-ma.com Cc: CTrobridge@baltimore.com, ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? References: <200003071556.KAA06133@tonga.xedia.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Bob" == Bob Doud writes: Bob> Of course, one argument for ESP, Null Auth is when you are Bob> bundling it with AH. That way, you pick up the authentication Bob> of the outer IP header, without duplicating the ICV's twice. Yes, but AH is so much more trouble than ESP authentication. In particular, it takes two passes to use AH if you also use compression (IPCOMP). Also, right now it is permitted to have just ESP (no AH) and yet no authentication. I can see no reason why that should continue. paul From owner-ipsec@lists.tislabs.com Tue Mar 7 10:31:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19818; Tue, 7 Mar 2000 10:31:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23875 Tue, 7 Mar 2000 12:21:25 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B8549F3C@baltimore.com> From: Chris Trobridge To: Bob Doud , Paul Koning Cc: ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Date: Tue, 7 Mar 2000 17:27:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ESP with null auth + AH would be fine. I'm not convinced about the merits of AH in any case. Given that ESP with auth authenticates the SPI, sequence number & payload, it's not possible for an attacker to spoof traffic through by altering the IP header. What does AH achieve? Chris > -----Original Message----- > From: Bob Doud [mailto:bdoud@ire-ma.com] > Sent: 07 March 2000 16:31 > To: Paul Koning; CTrobridge@baltimore.com > Cc: ipsec@lists.tislabs.com > Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like > CFB or OFB ? > > > Of course, one argument for ESP, Null Auth is when you are > bundling it with AH. That way, you pick up the authentication > of the outer IP header, without duplicating the ICV's twice. > > Bob > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Koning > > Sent: Tuesday, March 07, 2000 10:56 AM > > To: CTrobridge@baltimore.com > > Cc: helger@cyber.ee; ipsec@lists.tislabs.com > > Subject: RE: Q: Why IPSEC to be used only in CBC mode & not > other like > > CFB or OFB ? > > > > > > >>>>> "Chris" == Chris Trobridge writes: > > > > Chris> It does reinforce the advantages of authentication > in ESP. I > > Chris> don't know if I've come to the point of assuming ESP > > Chris> authentication is pretty much essential through > this group or > > Chris> though discussions with customers, but what do others think? > > > > I've been convinced by Steve Bellovin's papers that it is essential. > > Unfortunately, we're not currently allowed to reject ESP with null > > authenticaton. As far as I'm concerned, that's a bug, but > > unfortunately some feel differently. We're definitely > telling people > > in documentation not to skip authentication. > > > > Both in software and hardware, there is no performance justification > > for omitting authentication. > > > > paul > > > > > From owner-ipsec@lists.tislabs.com Tue Mar 7 11:18:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20768; Tue, 7 Mar 2000 11:18:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24745 Tue, 7 Mar 2000 12:52:21 -0500 (EST) From: "Bob Doud" To: "Michael Thomas" , "Elzur, Uri" Cc: "Henry Spencer" , "Michael Helm" , Subject: RE: ipsec NICs? Date: Tue, 7 Mar 2000 12:59:44 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <14533.9393.147854.568862@thomasm-u1.cisco.com> X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > > Elzur, Uri writes: > > Several examples might be Enterprise LAN with 100Mbs (and more in the > > future), Servers with 100/1G or backbone resident devices. Pls note that > > when a CPU is overloaded with Enc/Dec or Auth that overcome its power, it > > will not only neglect other application but might also bring the network > > connection to a grinding slow speeds. > > Then you wait for Moore's law to catch up? > > After years of watching the best intentioned > accelerators being consumed by brute force and > ignorance (eg faster main CPU's), I tend to > agree with Henry's comment below -- though there's > usually a window when such beasts are at least > plausible. Our crypto accelerator chips are providing over 155Mbps 3DES/SHA throughput today at $65 list price. Plus, they include Public Key acceleration, RNG and a security CPU on-chip... so there's a pretty good value vs. consuming the cycles on an expensive Pentium. > > What I want to know is whether the current crop > of accelerators can handle tens of thousands of > simultaneous SA's, all with low but bursty > output. I'm not sure where the accelerators > keep the SA context, but if it's actually in > the accelerator itself that's an awful lot of > RAM. If it's on the bus, I'd be concerned about > bus contention with the main CPU. I'm not sure about the other accelerators on the market, but our ADSP 2141 can support up to 2^32 simultaneous SA's (we have one customer doing over 100,000). We allow you to store them either in local memory connected to our chip, or in host PCI memory. As you point out, there is a performance concern when we have to pull them across the PCI bus, but for moderate performance systems, that can be offset by the desire to share system memory. Of course, the other issue that hasn't been mentioned in this thread is the potential for much greater security (protection of Keys and algorithm integrity) with a specialized crypto co-processor. With the 2141, you don't have to worry about leaking a plaintext key since the chip will never let a 'Red key' out. It will only return an encrypted 'Black key' to the application. Bob (See: http://www.ire.com/OEM/dsp.htm ) > > BTW, this situation is common with high fan out > client based systems which want to maintain > medium term to indefinite SA's to a server -- like > residential telephony. Since crypto is the > exception instead of the norm on the net today, > this may be the tip of the iceburg. > > Mike > > > > > thx > > > > Uri Elzur > > uri.elzur@intel.com > > > > > > > > -----Original Message----- > > From: Henry Spencer [mailto:henry@spsystems.net] > > Sent: Monday, March 06, 2000 3:05 PM > > To: Michael Helm > > Cc: ipsec@lists.tislabs.com > > Subject: Re: ipsec NICs? > > > > > > On Sun, 5 Mar 2000, Michael Helm wrote: > > > Is there anyone keeping track of vendors' ipsec-friendly > > > NICs & other networking cards? ... think it's necessary to put > > > at least some crypto support for this set of standards > > > on the hardware in order for it to be practical on a wide > > > scale. > > > > Why? The commodity processors (200MHz Pentiums and the like) currently > > being *thrown out* in favor of newer ones will do IPSEC using 3DES -- a > > software-unfriendly algorithm if there ever was one -- and MD5 at several > > megabits per second. (I'm talking about measured end-to-end data rates > > with real protocols, mind you, not theoretical calculations.) High-end > > consumer-market processors with software-optimized algorithms should take > > this up into the T3 range. > > > > These standards are practical on cheap, commodity computers right now. > > Only people with very fat pipes have a real need for crypto hardware. > > > > Henry Spencer > > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Tue Mar 7 12:31:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21918; Tue, 7 Mar 2000 12:31:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25161 Tue, 7 Mar 2000 14:17:47 -0500 (EST) Message-ID: From: "Lamm, Dennis S Mr (CPF N69DL)" To: "'ipsec@lists.tislabs.com'" Subject: SA Lifetimes Date: Tue, 7 Mar 2000 09:23:02 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm curious what type of SA lifetimes (Phase 2) the group typically implements, experiences, and most importantly, recommends. Some products default to refreshing SAs every 12-24 hours. To be clear, I'm most concerned about refreshing the authentication and encryption keys. I'm aware that RFC 2401 only recommends that the SA lifetime be no greater than the applicable certificate validity period. Any thoughts or insights would be much appreciated. Dennis *************************************** Dennis Lamm, CISSP Network Security Architect (Wang Govt Services) CINCPACFLT Information Assurance Office (N69) 250 Makalapa Drive, Pearl Harbor, HI 96860-3131 EM: lammds@cpf.navy.mil *************************************** From owner-ipsec@lists.tislabs.com Tue Mar 7 12:31:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21919; Tue, 7 Mar 2000 12:31:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25155 Tue, 7 Mar 2000 14:16:43 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Tero Kivinen'" Cc: "'Chris Trobridge'" , "'IPSEC Mailing List @ tis labs'" Subject: RE: Use of Encryption in Heartbeat Packets Date: Tue, 7 Mar 2000 14:28:34 -0500 Message-Id: <009c01bf886b$54c8fec0$1e0101c8@ANDREWK2.TIMESTEP> 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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200003071655.SAA23058@torni.ssh.fi> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (For those who may be wondering, Tero's numbers are based on the packet format which I am planning to use in my forthcoming draft.) If anyone has any further comments, please send them ASAP, as I plan to submit the draft later today. Tero, I don't disagree with your analysis, except on one point. DoS Analyis ----------- In your example with the SPI list, you assume that the SPI list only adds 200 bytes to the packet. This is not necessarily true in the DoS case because the adversary can make the packet as long as he wants. In general, full-packet HMAC authentication does not provide good DoS resistance. Of course, the adversary could still flood the host with small packets, but that is more likely to set off alarm bells on an external monitoring system. Other Anti-clogging Mechanisms ------------------------------ However, there are other possible anti-clogging mechanisms that do not require encryption. I would be amenable to using these instead. For example, if the message id (or some other field in the plaintext of the message) was generated via. a shared prf in a way that depended on the sequence number (e.g. message id = first 32 bits of prf(SKEYID_A, seqno)), then spoofed messages could be easily discarded. Security Weaknesses --------------------------- The bigger issue is whether not encrypting these packets will add any weaknesses to the framework. If I remove encryption from the spec then anyone doing a security analysis of ISAKMP will also have to consider the case of packets that are authenticated but not encrypted (BTW, wasn't there talk of removing the authenticated only bit from the header? This will have to be changed). By making the security of heartbeat packets equivalent to that of quick mode (actually higher because of the sequence number), I guaranteed that this was not the case. If there was some kind of data analysis attack on SKEYID_a that was not practical before, it may become practical when the hash is not encrypted. Also, if people are concerned about the SPI list being sent in the clear, they will have no resort. We both agreed that we did not want encryption to optional. I think I'm starting to change my mind on this issue. Want I don't want is for people to end up saying that they would use my heartbeat format but they are afraid of the possible security implications because it's not encrypted. When I asked people about this topic, the majority of people who responded said that it seemed safer to encrypt the packets and I agree I think what I will do is add a DONT_ENCRYPT option to the negotiation protocol. However, the default setting (and the only MUST support) will be to encrypt the packets. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Tuesday, March 07, 2000 11:55 AM > To: akrywani@newbridge.com > Cc: 'Chris Trobridge'; 'Andrew Krywaniuk'; 'IPSEC Mailing List @ tis > labs' > Subject: RE: Use of Encryption in Heartbeat Packets > > > Andrew Krywaniuk writes: > > Encryption does provide a "quick authentication check." > > I disagree this. I don't think it is going to be faster for any packet > size in normal operation, and for slow ciphers it is going to be very > much slower. On the other hand the saving offered by it are quite > small compared to the doing the real MAC in the first place. > > What you are comparing is the speed of > > 1) HASH(Last-CBC-Block || Message-ID) + Decrypt(1st-block) > > to the speed of the > > 2) HMAC-HASH(Rest of the packet) > > to do the first check, and then in the case 1 you need to do also the > > Decrypt(rest of the packet after 1st block) + > HMAC-HASH(Rest of the packet). > > Here the case 1 is the encrypted packet having MAC inside the > encrypted part and the sequence number in the first block so random > packets can be discarded after decrypting that one block. The case 2 > is when the packet has only MAC, and no encryption at all. > > If you don't have any spi's in the packet the packet "Rest of the > packet" is going to be only the notify payload (12 + 16 = 28 bytes). > So the packet in total is 28 bytes of header + 8 bytes of sequence > number + 20 bytes of hash + 28 bytes of notify. The total length is > going to be 84 bytes, and the encrypted part of it is 56 bytes. The > authenticated part of the message is 28 bytes. > > If we assume IKE SA is using 3des-md5, then the speeds are about > following: > > 1) md5(last-cbc-block || message-id) = 6 ms > 3des-cbc of one block = 20 ms > 3des-cbc of the rest of the blocks = 119 ms > > in total it is going to be 26 ms + 119 ms + 30 ms. > > 2) Hmac-md5 of 64 bytes = 30 ms. > > I.e in the DoS case you are saving for only the 4 ms, but in addition > you need to do the extra decryption for the rest of the packet, so for > each valid packet you waste 145 ms (total decryption time + the IV > generation time). > > If the packet contains 200 byte spi list payload also, then the timing > is going to be: > > 1) md5(last-cbc-block || message-id) = 6 ms > 3des-cbc of one block = 20 ms > 3des-cbc of the rest of the blocks = 614 ms > > in total it is going to be 26 ms + 614 ms + 30 ms. > > 2) Hmac-md5 of 256 bytes = 57 ms > > I.e in the DoS case you are saving for for 31 ms, but you are then > wasting the 640 ms for each valid packet. > > For blowfish-cbc and md5 the values in the case 1 are little bit > different: > > 1) md5(last-cbc-block || message-id) = 6 ms > blowfish-cbc of one block = 4 ms > blowfish-cbc of the rest of the blocks = 18 ms > > So for the DoS case you save 20 ms for the DoS packet and do > only 28 ms > extra work for valid packet. > > For the larger packet the numbers are: > > 1) md5(last-cbc-block || message-id) = 6 ms > blowfish-cbc of one block = 4 ms > blowfish-cbc of the rest of the blocks = 95 ms > > And for DoS case you save 47 ms, and you loose 105 ms in the valid > packet case. > > > In formal-speak, encryption provides an O(1) authentication > check of a NbnS > > indicator of packet validity. (NbnS = Necessary, but not Sufficient) > > Yes, the time is O(1), but the constant factor is quite large (one > hash for the iv and one cbc decryption) compared to the only hmac-hash > for the rest of the packet. > > In the DoS case the saving of the cpu is quite small, but in the valid > packet case the wasting of the cpu is quite large. For the faster > cipher the numbers are not that bad, but you still waste quite a lot > of cpu time for valid packets. > > I think the gain you get for decrypting the first cbc block first and > checking the sequence number first is not enought to justify the > wasting of the cpu time for normal valid packets. > > Ps. The numbers are from our crypto library using 500 MHz alpha. For > the hardware accelerated case the overhead of starting the decryption > etc is propably also going to play important role. > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Tue Mar 7 13:03:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22447; Tue, 7 Mar 2000 13:03:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25338 Tue, 7 Mar 2000 14:55:22 -0500 (EST) Date: Tue, 7 Mar 2000 15:01:17 -0500 Message-Id: <200003072001.PAA16304@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: akrywani@newbridge.com Cc: kivinen@ssh.fi, ipsec@lists.tislabs.com Subject: RE: Use of Encryption in Heartbeat Packets References: <200003071655.SAA23058@torni.ssh.fi> <009c01bf886b$54c8fec0$1e0101c8@ANDREWK2.TIMESTEP> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> I don't disagree with your analysis, except on one point. Andrew> DoS Analyis ----------- In your example with the SPI list, Andrew> you assume that the SPI list only adds 200 bytes to the Andrew> packet. This is not necessarily true in the DoS case because Andrew> the adversary can make the packet as long as he wants. An implementation will want to put sensible bounds on the packet size. There's the 64k UDP limit, of course, but you really need to be able to set limits far lower than that. Not just for DoS resistance but for many other reasons as well. Andrew> In general, full-packet HMAC authentication does not provide Andrew> good DoS resistance. I believe you're making some unstated assumptions there that may not be valid for other implementations. *If* it is practical in an implementation to do crypto in software, *and* to do packet validation on the fly while you're doing that, yes, then your point may be valid. On the other hand, if you're using hardware crypto, as you well may in high end systems, HMAC is definitely the best and most efficient method for verifying that a packet is good. Andrew> Of course, the adversary could still flood the host with Andrew> small packets, but that is more likely to set off alarm bells Andrew> on an external monitoring system. Not necessarily for a DDoS attack, or even if the alarms go off you may not be able to do much about it. paul From owner-ipsec@lists.tislabs.com Tue Mar 7 13:22:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22702; Tue, 7 Mar 2000 13:22:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25374 Tue, 7 Mar 2000 15:06:17 -0500 (EST) Message-Id: <200003072008.MAA22889@potassium.network-alchemy.com> To: akrywani@newbridge.com cc: "'Tero Kivinen'" , "'Chris Trobridge'" , "'IPSEC Mailing List @ tis labs'" Subject: Re: Use of Encryption in Keepalive Packets In-reply-to: Your message of "Tue, 07 Mar 2000 14:28:34 EST." <009c01bf886b$54c8fec0$1e0101c8@ANDREWK2.TIMESTEP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22886.952459737.1@network-alchemy.com> Date: Tue, 07 Mar 2000 12:08:57 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Have you spoken to any of the other vendors that have implemented proprietary keepalive functions? It would be nice to encorporate any insight they might've gotten into your draft. Also, please do not take magic numbers you need from the "Reserved to IANA" (or reserved to anyone else for that matter) numberspace. And include a value to put in a vendor ID payload to identify a consenting party. I know of one vendor that includes the keepalive value in its vendor ID payload as a way to "negotiate" to the lowest acceptable value. Dan. On Tue, 07 Mar 2000 14:28:34 EST you wrote > (For those who may be wondering, Tero's numbers are based on the packet > format which I am planning to use in my forthcoming draft.) > > If anyone has any further comments, please send them ASAP, as I plan to > submit the draft later today. From owner-ipsec@lists.tislabs.com Tue Mar 7 13:29:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22818; Tue, 7 Mar 2000 13:29:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25440 Tue, 7 Mar 2000 15:16:20 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Koning'" , "Andrew Krywaniuk" Cc: , Subject: RE: Use of Encryption in Heartbeat Packets Date: Tue, 7 Mar 2000 15:29:05 -0500 Message-Id: <000001bf8873$c92cdb80$1e0101c8@ANDREWK2.TIMESTEP> 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 8.5, Build 4.71.2173.0 In-Reply-To: <200003072001.PAA16304@tonga.xedia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, Admittedly, "good" is a relative term. What I meant to say is that potentially much faster mechanisms exist. The use of encryption is O(1) relative to packet size, but, as Tero pointed out, the constant is quite large unless you use a fast encryption algorithm. The other mechanism I suggested (a predictable message id) is also O(1) relative to packet size, but the constant is very low. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: Tuesday, March 07, 2000 3:01 PM > To: akrywani@newbridge.com > Cc: kivinen@ssh.fi; ipsec@lists.tislabs.com > Subject: RE: Use of Encryption in Heartbeat Packets > > > >>>>> "Andrew" == Andrew Krywaniuk writes: > > Andrew> I don't disagree with your analysis, except on one point. > > Andrew> DoS Analyis ----------- In your example with the SPI list, > Andrew> you assume that the SPI list only adds 200 bytes to the > Andrew> packet. This is not necessarily true in the DoS case because > Andrew> the adversary can make the packet as long as he wants. > > An implementation will want to put sensible bounds on the packet size. > There's the 64k UDP limit, of course, but you really need to be able > to set limits far lower than that. Not just for DoS resistance but > for many other reasons as well. > > Andrew> In general, full-packet HMAC authentication does not provide > Andrew> good DoS resistance. > > I believe you're making some unstated assumptions there that may not > be valid for other implementations. > > *If* it is practical in an implementation to do crypto in software, > *and* to do packet validation on the fly while you're doing that, yes, > then your point may be valid. > > On the other hand, if you're using hardware crypto, as you > well may in > high end systems, HMAC is definitely the best and most efficient > method for verifying that a packet is good. > > Andrew> Of course, the adversary could still flood the host with > Andrew> small packets, but that is more likely to set off alarm bells > Andrew> on an external monitoring system. > > Not necessarily for a DDoS attack, or even if the alarms go off you > may not be able to do much about it. > > paul > From owner-ipsec@lists.tislabs.com Tue Mar 7 13:50:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23101; Tue, 7 Mar 2000 13:50:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25498 Tue, 7 Mar 2000 15:31:26 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Dan Harkins'" , "Andrew Krywaniuk" Cc: "'Tero Kivinen'" , "'Chris Trobridge'" , "'IPSEC Mailing List @ tis labs'" Subject: RE: Use of Encryption in Keepalive Packets Date: Tue, 7 Mar 2000 15:44:09 -0500 Message-Id: <000101bf8875$e4312380$1e0101c8@ANDREWK2.TIMESTEP> 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 8.5, Build 4.71.2173.0 In-Reply-To: <200003072008.MAA22889@potassium.network-alchemy.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan, > Have you spoken to any of the other vendors that have implemented > proprietary keepalive functions? It would be nice to encorporate any > insight they might've gotten into your draft. I based my draft on the comments I received during the December thread on this list and on private discussions with interested parties. > Also, please do not take magic numbers you need from the > "Reserved to > IANA" (or reserved to anyone else for that matter) numberspace. And > include a value to put in a vendor ID payload to identify a consenting > party. I know of one vendor that includes the keepalive value in its > vendor ID payload as a way to "negotiate" to the lowest > acceptable value. Don't worry about the IANA issues. I took all values from the private range and used a vendor id. I know that we (TimeStep) haven't always been thorough in that regard, but this will change. The idea of using vendor IDs to "negotiate" values drew a lot of criticism last time this topic was broached. So instead I used Config Mode. I know that the people who don't like the DHCP-like features of Config Mode might object to this, but shoe-horning another protocol (e.g. vendor ids, ack'ed notifies) into performing negotiation seemed too kludgy. So if you don't want to support DHCP via Config Mode then just don't implement those attributes. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: Tuesday, March 07, 2000 3:09 PM > To: akrywani@newbridge.com > Cc: 'Tero Kivinen'; 'Chris Trobridge'; 'IPSEC Mailing List @ tis labs' > Subject: Re: Use of Encryption in Keepalive Packets > > > Have you spoken to any of the other vendors that have implemented > proprietary keepalive functions? It would be nice to encorporate any > insight they might've gotten into your draft. > > Also, please do not take magic numbers you need from the > "Reserved to > IANA" (or reserved to anyone else for that matter) numberspace. And > include a value to put in a vendor ID payload to identify a consenting > party. I know of one vendor that includes the keepalive value in its > vendor ID payload as a way to "negotiate" to the lowest > acceptable value. > > Dan. > > On Tue, 07 Mar 2000 14:28:34 EST you wrote > > (For those who may be wondering, Tero's numbers are based > on the packet > > format which I am planning to use in my forthcoming draft.) > > > > If anyone has any further comments, please send them ASAP, > as I plan to > > submit the draft later today. > From owner-ipsec@lists.tislabs.com Tue Mar 7 13:58:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23224; Tue, 7 Mar 2000 13:58:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25607 Tue, 7 Mar 2000 15:51:24 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200003071713.MAA08064@tonga.xedia.com> References: <200003071556.KAA06133@tonga.xedia.com> <200003071713.MAA08064@tonga.xedia.com> Date: Tue, 7 Mar 2000 15:54:38 -0500 To: Paul Koning From: Stephen Kent Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, > >>>>> "Bob" == Bob Doud writes: > > Bob> Of course, one argument for ESP, Null Auth is when you are > Bob> bundling it with AH. That way, you pick up the authentication > Bob> of the outer IP header, without duplicating the ICV's twice. > >Yes, but AH is so much more trouble than ESP authentication. >In particular, it takes two passes to use AH if you also use >compression (IPCOMP). > >Also, right now it is permitted to have just ESP (no AH) and yet no >authentication. I can see no reason why that should continue. Suitable authentication may have been applied previously, e.g., via IPsec at an end system (vs. a gateway) or at a higher layer. Steve From owner-ipsec@lists.tislabs.com Tue Mar 7 14:01:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23280; Tue, 7 Mar 2000 14:01:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25614 Tue, 7 Mar 2000 15:51:47 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200003071556.KAA06133@tonga.xedia.com> References: <1FD60AE4DB6CD2118C420008C74C27B81D0580@baltimore.com> <200003071556.KAA06133@tonga.xedia.com> Date: Tue, 7 Mar 2000 15:52:56 -0500 To: Paul Koning From: Stephen Kent Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Cc: CTrobridge@baltimore.com, helger@cyber.ee, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, > >>>>> "Chris" == Chris Trobridge writes: > > Chris> It does reinforce the advantages of authentication in ESP. I > Chris> don't know if I've come to the point of assuming ESP > Chris> authentication is pretty much essential through this group or > Chris> though discussions with customers, but what do others think? > >I've been convinced by Steve Bellovin's papers that it is essential. >Unfortunately, we're not currently allowed to reject ESP with null >authenticaton. As far as I'm concerned, that's a bug, but >unfortunately some feel differently. We're definitely telling people >in documentation not to skip authentication. > >Both in software and hardware, there is no performance justification >for omitting authentication. I think the technical term here is "wrong" :-). In software implementations, performing authentication on ESP packets adds delay and may become a throughput limiting factor, assuming serial processing. In all systems it adds bytes that must be transmitted. In an era where our wireless friends are pushing for certificate lite, and people are hacking TCP at intermediate points to improve performance, the extra 12 bytes of authentication data may be the proverbial straw in some instances. Thus it is appropriate to not mandate use of authentication in ESP in all circumstances. Steve From owner-ipsec@lists.tislabs.com Tue Mar 7 14:13:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23541; Tue, 7 Mar 2000 14:13:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25707 Tue, 7 Mar 2000 16:00:21 -0500 (EST) Date: Tue, 7 Mar 2000 16:05:56 -0500 Message-Id: <200003072105.QAA17234@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? References: <1FD60AE4DB6CD2118C420008C74C27B81D0580@baltimore.com> <200003071556.KAA06133@tonga.xedia.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> Paul, >> >>>>> "Chris" == Chris Trobridge >> writes: >> Chris> It does reinforce the advantages of authentication in ESP. I Chris> don't know if I've come to the point of assuming ESP Chris> authentication is pretty much essential through this group or Chris> though discussions with customers, but what do others think? >> I've been convinced by Steve Bellovin's papers that it is >> essential. Unfortunately, we're not currently allowed to reject >> ESP with null authenticaton. As far as I'm concerned, that's a >> bug, but unfortunately some feel differently. We're definitely >> telling people in documentation not to skip authentication. >> >> Both in software and hardware, there is no performance >> justification for omitting authentication. Stephen> I think the technical term here is "wrong" :-). Yes, I guess we're disagreeing on this point. Stephen> In software Stephen> implementations, performing authentication on ESP packets Stephen> adds delay and may become a throughput limiting factor, Stephen> assuming serial processing. In all systems it adds bytes Stephen> that must be transmitted. In an era where our wireless Stephen> friends are pushing for certificate lite, and people are Stephen> hacking TCP at intermediate points to improve performance, Stephen> the extra 12 bytes of authentication data may be the Stephen> proverbial straw in some instances. I find these arguments singularly unconvincing in the light of Moore's Law and its data comm equivalent (where the time constant is, if anything, shorter). Thus I tend to say nasty things when I look at things like PPP header compression, or 3 byte integers in ATM SVC signalling protocols, and other stuff designed with the notion that every byte is precious. Those tradeoffs, in my opinion, do far more harm than good. If they can be justified at all, it is only for the short time the underlying assumptions were valid. But the harmful side effects in added complexity last far longer. paul From owner-ipsec@lists.tislabs.com Tue Mar 7 15:20:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25119; Tue, 7 Mar 2000 15:19:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25900 Tue, 7 Mar 2000 16:59:04 -0500 (EST) Message-ID: <08fc01bf8849$8ba99480$b301a8c0@bluesteelnet.com> Reply-To: "Joe Tardo" From: "Joe Tardo" To: "Fabio Zamparelli" , "Philippe Piemont" Cc: References: Subject: Re: ipsec NICs? 3com? Date: Tue, 7 Mar 2000 07:26:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Take a look at: http://www.3com.com/promotions/securenic/index.html Maybe Intel will follow, perhaps, with their own offer? ----- Original Message ----- From: Fabio Zamparelli To: Philippe Piemont Cc: Sent: Tuesday, March 07, 2000 6:38 AM Subject: R: ipsec NICs? 3com? > > > > -----Messaggio originale----- > > Da: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]Per conto di Philippe Piemont > > Inviato: martedì 7 marzo 2000 10.04 > > A: helm@fionn.es.net > > Cc: ipsec@lists.tislabs.com > > Oggetto: Re: ipsec NICs? > > > > > > > > > > Hi Michael > > > > 3Com has 2 IPSec NIC cards working as normal NIC cards exept when > > the IPSec > > client asks to encrypt a conversation: the family name is 3CR990 > > one is dedicated for the servers with all the advanced server > > functionnalities. > > one for the desktops > > Regards > > Philippe > > Very intersesting. > I hope my university will buy at least two 'IPSec Nics' to do some testings > ASAP. I think the test bed will be win2k to be able to test both host2host > and tunneling configurations. > Do you know if 3com's fastethernet products have win2k-IPSec compliant > caracteristics similar to intel? How they fit with Microsoft tcp/ip(sec) > stack? > I try to find out something on 3com site but I think the docs to be not so > updated. > Any link to updated technical whitepapers? > > Thanks, Fabio Zed Zamparelli > > From owner-ipsec@lists.tislabs.com Tue Mar 7 15:21:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25155; Tue, 7 Mar 2000 15:21:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25899 Tue, 7 Mar 2000 16:59:04 -0500 (EST) Message-ID: <71984F8FB76AD211AC3E00A0C9C578C7020DE7E0@hasmsx32.iil.intel.com> From: "Elzur, Uri" To: Michael Thomas , "Elzur, Uri" Cc: Henry Spencer , Michael Helm , ipsec@lists.tislabs.com Subject: RE: ipsec NICs? Date: Tue, 7 Mar 2000 13:34:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, DES/3DES has a characteristics that makes them HW friendly and not SW friendly. Using Moore's law, it is easy to see that at least for the next few years, 100Mb/s and more so, 1Gb/S or faster, can significantly benefit from HW accelerators. I guess Henry's comment below, mentions that T3 will be the limit of the commodity CPUs (when fully consumed) and I agree. As for the number of SA supported. I can see 2 classes of NICs - Server and Client. On a server NIC, the # of SA supported should be higher (range of x00 or even x000). I concur with your analysis as for the best memory location for storing that many SAs. Hence, the right scheme should be memory on the NIC, where value (i.e. number of SA supported on board) correlates with price. Even larger number of SAs might be required for backbone devices and there the cost of additional memory on the NIC may be well justified. Residential Telephony - assuming 64kb/S per connection, 100Mb/S supports 1600 connections (1Gb/S = ~16,000. not to mention vocoders with lower BW per call). If IP based telephony devices, will follow the traditional PBX line density (10,000 lines) for scalability reasons, and may have several NICs for reliability (99.999...), the security enabled NICs will need to support SA numbers in x00 to x000 range. As for the client - what would you consider "high fan out"? The number of E-MAil or other app-servers is normally below 10 per client. As for residential Telephony, I suspect the SAs are setup as part of the call setup and are tear down when the call is over (assuming End2End SA). Hence the # of SA is small again. thx Uri -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, March 07, 2000 5:48 PM To: Elzur, Uri Cc: Henry Spencer; Michael Helm; ipsec@lists.tislabs.com Subject: RE: ipsec NICs? Elzur, Uri writes: > Several examples might be Enterprise LAN with 100Mbs (and more in the > future), Servers with 100/1G or backbone resident devices. Pls note that > when a CPU is overloaded with Enc/Dec or Auth that overcome its power, it > will not only neglect other application but might also bring the network > connection to a grinding slow speeds. Then you wait for Moore's law to catch up? After years of watching the best intentioned accelerators being consumed by brute force and ignorance (eg faster main CPU's), I tend to agree with Henry's comment below -- though there's usually a window when such beasts are at least plausible. What I want to know is whether the current crop of accelerators can handle tens of thousands of simultaneous SA's, all with low but bursty output. I'm not sure where the accelerators keep the SA context, but if it's actually in the accelerator itself that's an awful lot of RAM. If it's on the bus, I'd be concerned about bus contention with the main CPU. BTW, this situation is common with high fan out client based systems which want to maintain medium term to indefinite SA's to a server -- like residential telephony. Since crypto is the exception instead of the norm on the net today, this may be the tip of the iceburg. Mike > > thx > > Uri Elzur > uri.elzur@intel.com > > > > -----Original Message----- > From: Henry Spencer [mailto:henry@spsystems.net] > Sent: Monday, March 06, 2000 3:05 PM > To: Michael Helm > Cc: ipsec@lists.tislabs.com > Subject: Re: ipsec NICs? > > > On Sun, 5 Mar 2000, Michael Helm wrote: > > Is there anyone keeping track of vendors' ipsec-friendly > > NICs & other networking cards? ... think it's necessary to put > > at least some crypto support for this set of standards > > on the hardware in order for it to be practical on a wide > > scale. > > Why? The commodity processors (200MHz Pentiums and the like) currently > being *thrown out* in favor of newer ones will do IPSEC using 3DES -- a > software-unfriendly algorithm if there ever was one -- and MD5 at several > megabits per second. (I'm talking about measured end-to-end data rates > with real protocols, mind you, not theoretical calculations.) High-end > consumer-market processors with software-optimized algorithms should take > this up into the T3 range. > > These standards are practical on cheap, commodity computers right now. > Only people with very fat pipes have a real need for crypto hardware. > > Henry Spencer > henry@spsystems.net > > > > > > From owner-ipsec@lists.tislabs.com Tue Mar 7 16:30:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26396; Tue, 7 Mar 2000 16:30:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26190 Tue, 7 Mar 2000 18:21:02 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200003072105.QAA17234@tonga.xedia.com> References: <1FD60AE4DB6CD2118C420008C74C27B81D0580@baltimore.com> <200003071556.KAA06133@tonga.xedia.com> <200003072105.QAA17234@tonga.xedia.com> Date: Tue, 7 Mar 2000 18:26:40 -0500 To: Paul Koning From: Stephen Kent Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, I guess we must simply disagree. I too hate to see shortsighted tradeoffs, but the world is full of them, and out standards environment has many examples. I might agree that the extra bandwidth devoted to the integrity is not too awful, and I agree that suitable hardware can parallel process the authentication data and not make it a bottleneck. However, the Internet (and the IETF) has a long history of favoring software over hardware when it comes to these tradeoffs, and I'm not in favor of making IPsec the exception in this instance. Also, I see very little evidence that the optional use of the authentication feature of ESP adds significant complexity to the protocol, since many (most?) folks agree that having an authentication-only mode for ESP is a good idea. Steve From owner-ipsec@lists.tislabs.com Tue Mar 7 19:28:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07170; Tue, 7 Mar 2000 19:28:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26733 Tue, 7 Mar 2000 21:00:45 -0500 (EST) Date: Wed, 8 Mar 2000 04:06:42 +0200 (EET) Message-Id: <200003080206.EAA30074@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Joern Sierwald CC: Subject: RE: Use of Encryption in Heartbeat Packets In-Reply-To: <3.0.5.32.20000307183032.031ed100@smtp.datafellows.com> References: <006101bf830a$020c37d0$1e0101c8@ANDREWK2.TIMESTEP> <1FD60AE4DB6CD2118C420008C74C27B81D0518@baltimore.com> <200003071655.SAA23058@torni.ssh.fi> <3.0.5.32.20000307183032.031ed100@smtp.datafellows.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joern Sierwald writes: > ms usually is "milliseconds", right? > The number look more like microseconds. Ups, true. The numbers in my previous email are microseconds, not milliseconds. That happens when you have too long vacations and too much emails to read after coming back. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Mar 7 19:40:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08197; Tue, 7 Mar 2000 19:40:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26812 Tue, 7 Mar 2000 21:20:09 -0500 (EST) Date: Wed, 8 Mar 2000 04:25:56 +0200 (EET) Message-Id: <200003080225.EAA23727@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: Tero Kivinen To: Cc: "'Chris Trobridge'" , "'IPSEC Mailing List @ tis labs'" Subject: RE: Use of Encryption in Heartbeat Packets In-Reply-To: <009c01bf886b$54c8fec0$1e0101c8@ANDREWK2.TIMESTEP> References: <200003071655.SAA23058@torni.ssh.fi> <009c01bf886b$54c8fec0$1e0101c8@ANDREWK2.TIMESTEP> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 14 min X-Total-Time: 16 min Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id VAA26809 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk writes: > DoS Analyis > ----------- > In your example with the SPI list, you assume that the SPI list only adds > 200 bytes to the packet. This is not necessarily true in the DoS case > because the adversary can make the packet as long as he wants. True, but lets say the attacker adds 2048 bytes of spi list to the packet. HMAC-MD5 of that 2048 bytes takes 308 µs (microseconds, my previous email used ms instead of proper µs). That is still much faster than decrypting even the 200 byte packet. If the attacker adds more you can ignore the packet because it is too big. > In general, full-packet HMAC authentication does not provide good DoS > resistance. We are already using full-packet HMAC authentication in the ESP and AH protocols, so I don't really think this is an issue here... If somebody wants to consume our HMAC-MD5 calculation resources then he can send random full sized ESP packets. > Security Weaknesses > --------------------------- > The bigger issue is whether not encrypting these packets will add any > weaknesses to the framework. True. I haven't seen any real weakness because of clear text heartbeat packets. > If there was some kind of data analysis attack on SKEYID_a that was not > practical before, it may become practical when the hash is not encrypted. > Also, if people are concerned about the SPI list being sent in the clear, > they will have no resort. We are already generating HMAC-MD5 key from the SKEYID_e that is used to calculate the ESP authentication MAC. In the ESP packet the result of the MAC is stored in the packet after encryption. So if there is such attack which gains from the seeing data, HMAC-MD5 hash of data pairs, then we have much more serious problems than just breaking heartbeats... > We both agreed that we did not want encryption to optional. I think I'm > starting to change my mind on this issue. I think it is better to select either one and stick to it. IKE has way too options already, I don't want to add another one. If WG thinks we must encrypt the packets then we encrypt them and thats fine... Perhaps it is better to wait before everybody has time to read the draft and then we can ask about this in the Adelaide IETF meeting. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Mar 7 21:09:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA13263; Tue, 7 Mar 2000 21:09:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA27067 Tue, 7 Mar 2000 22:42:41 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Tero Kivinen'" Cc: "'Chris Trobridge'" , "'IPSEC Mailing List @ tis labs'" Subject: RE: Use of Encryption in Heartbeat Packets Date: Tue, 7 Mar 2000 22:55:30 -0500 Message-Id: <000901bf88b2$266e1cd0$1e0101c8@ANDREWK2.TIMESTEP> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200003080225.EAA23727@torni.ssh.fi> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Tero, > > DoS Analysis > > ----------- > > In your example with the SPI list, you assume that the SPI > list only adds > > 200 bytes to the packet. This is not necessarily true in > the DoS case > > because the adversary can make the packet as long as he wants. > > True, but lets say the attacker adds 2048 bytes of spi list to the > packet. HMAC-MD5 of that 2048 bytes takes 308 µs (microseconds, my > previous email used ms instead of proper µs). That is still much > faster than decrypting even the 200 byte packet. With 3DES, yes. With AES, probably not. > > In general, full-packet HMAC authentication does not > provide good (restate: optimal) DoS > > resistance. > > We are already using full-packet HMAC authentication in the ESP and AH > protocols, so I don't really think this is an issue here... If > somebody wants to consume our HMAC-MD5 calculation resources then he > can send random full sized ESP packets. But part of your argument for not wanting to use encryption is that ISAKMP might be running on software but ESP may be in hardware. Therefore, the attack might be more serious when it is mounted against ISAKMP. Anyway, I think the idea of generating per-packet anti-clogging tokens with a shared prf is worth looking into. > > We both agreed that we did not want encryption to optional. > I think I'm > > starting to change my mind on this issue. > > I think it is better to select either one and stick to it. IKE has way > too options already, I don't want to add another one. If WG thinks we > must encrypt the packets then we encrypt them and thats fine... > > Perhaps it is better to wait before everybody has time to read the > draft and then we can ask about this in the Adelaide IETF meeting. If the issue can be resolved as simply as that, this is fine with me. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Mar 8 12:15:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA18388; Wed, 8 Mar 2000 12:15:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00855 Wed, 8 Mar 2000 13:29:35 -0500 (EST) Date: Wed, 8 Mar 2000 13:35:30 -0500 Message-Id: <200003081835.NAA18960@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: RE: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? References: <1FD60AE4DB6CD2118C420008C74C27B81D0580@baltimore.com> <200003071556.KAA06133@tonga.xedia.com> <200003072105.QAA17234@tonga.xedia.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> Paul, I guess we must simply disagree. I too hate to see Stephen> shortsighted tradeoffs, but the world is full of them, and Stephen> out standards environment has many examples. I might agree Stephen> that the extra bandwidth devoted to the integrity is not too Stephen> awful, and I agree that suitable hardware can parallel Stephen> process the authentication data and not make it a Stephen> bottleneck. However, the Internet (and the IETF) has a long Stephen> history of favoring software over hardware when it comes to Stephen> these tradeoffs, and I'm not in favor of making IPsec the Stephen> exception in this instance. But in software the delta from authentication is small, too. Stephen> Also, I see very little Stephen> evidence that the optional use of the authentication feature Stephen> of ESP adds significant complexity to the protocol, since Stephen> many (most?) folks agree that having an authentication-only Stephen> mode for ESP is a good idea. Actually, at this point there's very little reason to have the authentication-only mode. But we were talking about the encryption-only mode. It includes a change in packet format, different sequence number algorithms. Most importantly, it means exposing an option to the user and network manager, and then telling them that the option is there but shouldn't be used (except if you're really sure that it's safe, which is asking quite a lot from a typical network manager). paul From owner-ipsec@lists.tislabs.com Wed Mar 8 13:35:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA19542; Wed, 8 Mar 2000 13:35:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01363 Wed, 8 Mar 2000 15:11:04 -0500 (EST) Message-ID: <38C6B58D.45688E70@storm.ca> Date: Wed, 08 Mar 2000 15:18:21 -0500 From: Sandy Harris X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jeff Fowler CC: IP Security List Subject: Re: ipsec NICs? References: <38C44A8D.83D9E912@ewd.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jeff Fowler wrote: > > On Mon, 6 Mar 2000, Henry Spencer wrote: > > > ... If it runs at a few tens of megabits and > > costs a thousand dollars, you're probably better off with CPUs. > > > > The new 3Com 3CR9990 10/100 Ethernet NIC supports Windows 2000 > IPSec offload at rates of up 90 megabits/sec when using ESP with > 3DES+MD5 and it costs between $120-140. IPSec crypto offloading to > a NIC also significantly improves the host system CPU utilization when > doing 3DES. We have seen CPU utilization drop from over 80% to 20% > when Windows 2000 ESP-3DES is offloaded to the 3CR9990 NIC. > Except that, according to the 3Com web pagee at: http://www.3com.com/products/dsheets/400517a.html#1 this offers only single DES outside the US and Canada. Anyone not already aware that single DES is dangerously insecure might want to look at: http://www.freeswan.org/freeswan_trees/freeswan-1.3/doc/DES.html Nice as hardware assists might be, if they don't deliver real security then you're far better off with software that does. From owner-ipsec@lists.tislabs.com Wed Mar 8 14:13:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19959; Wed, 8 Mar 2000 14:13:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01573 Wed, 8 Mar 2000 15:50:13 -0500 (EST) Message-ID: <19398D273324D3118A2B0008C7E9A56907AE6648@SIT.platinum.corp.microsoft.com> From: Chun Ye To: "'Sandy Harris'" , Jeff Fowler Cc: IP Security List Subject: RE: ipsec NICs? Date: Wed, 8 Mar 2000 12:36:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you can't do 3DES in certain countries, then it doesn't matter whether it is done software or hardware. --Chun -----Original Message----- From: Sandy Harris [mailto:sandy@storm.ca] Sent: Wednesday, March 08, 2000 12:18 PM To: Jeff Fowler Cc: IP Security List Subject: Re: ipsec NICs? Jeff Fowler wrote: > > On Mon, 6 Mar 2000, Henry Spencer wrote: > > > ... If it runs at a few tens of megabits and > > costs a thousand dollars, you're probably better off with CPUs. > > > > The new 3Com 3CR9990 10/100 Ethernet NIC supports Windows 2000 > IPSec offload at rates of up 90 megabits/sec when using ESP with > 3DES+MD5 and it costs between $120-140. IPSec crypto offloading to > a NIC also significantly improves the host system CPU utilization when > doing 3DES. We have seen CPU utilization drop from over 80% to 20% > when Windows 2000 ESP-3DES is offloaded to the 3CR9990 NIC. > Except that, according to the 3Com web pagee at: http://www.3com.com/products/dsheets/400517a.html#1 this offers only single DES outside the US and Canada. Anyone not already aware that single DES is dangerously insecure might want to look at: http://www.freeswan.org/freeswan_trees/freeswan-1.3/doc/DES.html Nice as hardware assists might be, if they don't deliver real security then you're far better off with software that does. From owner-ipsec@lists.tislabs.com Wed Mar 8 14:28:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA20140; Wed, 8 Mar 2000 14:28:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01735 Wed, 8 Mar 2000 16:22:45 -0500 (EST) Message-ID: <71984F8FB76AD211AC3E00A0C9C578C7020DEBA9@hasmsx32.iil.intel.com> From: "Elzur, Uri" To: Joe Tardo , Fabio Zamparelli , Philippe Piemont Cc: ipsec@lists.tislabs.com Subject: RE: ipsec NICs? 3com? Date: Wed, 8 Mar 2000 13:21:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA01707 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe pls see other mail (a day or two ago) on Intel products offereing please look at the following URLs http://www.intel.com/network/products/desktop_adapters.htm?iid=netsite+home& http://www.intel.com/network/products/security.htm http://www.intel.com/network/products/pro100smgmt.htm Thx Uri -----Original Message----- From: Joe Tardo [mailto:jtardo@broadcom.com] Sent: Tuesday, March 07, 2000 5:27 PM To: Fabio Zamparelli; Philippe Piemont Cc: ipsec@lists.tislabs.com Subject: Re: ipsec NICs? 3com? Take a look at: http://www.3com.com/promotions/securenic/index.html Maybe Intel will follow, perhaps, with their own offer? ----- Original Message ----- From: Fabio Zamparelli To: Philippe Piemont Cc: Sent: Tuesday, March 07, 2000 6:38 AM Subject: R: ipsec NICs? 3com? > > > > -----Messaggio originale----- > > Da: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]Per conto di Philippe Piemont > > Inviato: martedì 7 marzo 2000 10.04 > > A: helm@fionn.es.net > > Cc: ipsec@lists.tislabs.com > > Oggetto: Re: ipsec NICs? > > > > > > > > > > Hi Michael > > > > 3Com has 2 IPSec NIC cards working as normal NIC cards exept when > > the IPSec > > client asks to encrypt a conversation: the family name is 3CR990 > > one is dedicated for the servers with all the advanced server > > functionnalities. > > one for the desktops > > Regards > > Philippe > > Very intersesting. > I hope my university will buy at least two 'IPSec Nics' to do some testings > ASAP. I think the test bed will be win2k to be able to test both host2host > and tunneling configurations. > Do you know if 3com's fastethernet products have win2k-IPSec compliant > caracteristics similar to intel? How they fit with Microsoft tcp/ip(sec) > stack? > I try to find out something on 3com site but I think the docs to be not so > updated. > Any link to updated technical whitepapers? > > Thanks, Fabio Zed Zamparelli > > From owner-ipsec@lists.tislabs.com Wed Mar 8 14:46:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA20401; Wed, 8 Mar 2000 14:46:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01843 Wed, 8 Mar 2000 16:38:40 -0500 (EST) Date: Wed, 8 Mar 2000 16:42:52 -0500 (EST) From: Henry Spencer To: Chun Ye cc: "'Sandy Harris'" , IP Security List Subject: RE: ipsec NICs? In-Reply-To: <19398D273324D3118A2B0008C7E9A56907AE6648@SIT.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 8 Mar 2000, Chun Ye wrote: > If you can't do 3DES in certain countries, then it doesn't matter whether it > is done software or hardware. True, but that was not the issue Sandy was addressing. The issue is not whether it is legal to use 3DES in Ruritania, but what implementations of it can be obtained there. Software for it is available everywhere, thanks to Linux FreeS/WAN and OpenBSD. Hardware "assists" are useless toys if they come only with 1DES because of US export regulations. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Mar 8 15:10:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20752; Wed, 8 Mar 2000 15:10:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01966 Wed, 8 Mar 2000 16:51:14 -0500 (EST) Date: Wed, 8 Mar 2000 16:55:50 -0500 (EST) From: Henry Spencer To: Chun Ye cc: "'Sandy Harris'" , IP Security List Subject: RE: ipsec NICs? In-Reply-To: <19398D273324D3118A2B0008C7E9A56907AE664F@SIT.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 8 Mar 2000, Chun Ye wrote: >> The issue is not whether it is legal to use 3DES in Ruritania, but what >> implementations of it can be obtained there. Software for it is available >> everywhere, thanks to Linux FreeS/WAN and OpenBSD... > > Windows 2000 does 3DES too. Just want to clarify. Yes, as do a number of other US-based software packages. I mentioned Linux FreeS/WAN and OpenBSD in particular because they are available free of charge and are maintained outside the US, which offers a much stronger guarantee of long-term availability, independent of changes in US policy and/or corporate policy. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Mar 8 15:19:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20924; Wed, 8 Mar 2000 15:19:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02050 Wed, 8 Mar 2000 17:08:59 -0500 (EST) Message-ID: <19398D273324D3118A2B0008C7E9A56907AE664F@SIT.platinum.corp.microsoft.com> From: Chun Ye To: "'Henry Spencer'" , Chun Ye Cc: "'Sandy Harris'" , IP Security List Subject: RE: ipsec NICs? Date: Wed, 8 Mar 2000 13:42:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Windows 2000 does 3DES too. Just want to clarify. --Chun -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Wednesday, March 08, 2000 1:43 PM To: Chun Ye Cc: 'Sandy Harris'; IP Security List Subject: RE: ipsec NICs? On Wed, 8 Mar 2000, Chun Ye wrote: > If you can't do 3DES in certain countries, then it doesn't matter whether it > is done software or hardware. True, but that was not the issue Sandy was addressing. The issue is not whether it is legal to use 3DES in Ruritania, but what implementations of it can be obtained there. Software for it is available everywhere, thanks to Linux FreeS/WAN and OpenBSD. Hardware "assists" are useless toys if they come only with 1DES because of US export regulations. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 9 00:52:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA17549; Thu, 9 Mar 2000 00:52:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA03545 Thu, 9 Mar 2000 02:03:08 -0500 (EST) From: "Josef Pojsl" Date: Thu, 9 Mar 2000 08:09:05 +0100 To: Chun Ye Cc: ipsec@lists.tislabs.com Subject: Re: ipsec NICs? Message-ID: <20000309080905.A17678@regent.in.skynet.cz> Mail-Followup-To: Chun Ye , ipsec@lists.tislabs.com References: <19398D273324D3118A2B0008C7E9A56907AE664F@SIT.platinum.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.1i In-Reply-To: <19398D273324D3118A2B0008C7E9A56907AE664F@SIT.platinum.corp.microsoft.com>; from chunye@Exchange.Microsoft.com on Wed, Mar 08, 2000 at 01:42:52PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Mar 08, 2000 at 01:42:52PM -0800, Chun Ye wrote: > Windows 2000 does 3DES too. Just want to clarify. As far as I understand, this subthread is about international availability. Are you saying that international versions of Win2K are going to be equipped with 3DES IPsec? I guess they would be limited to single DES... Regards, Josef From owner-ipsec@lists.tislabs.com Thu Mar 9 02:06:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA20728; Thu, 9 Mar 2000 02:06:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA03954 Thu, 9 Mar 2000 03:45:51 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "Josef Pojsl" Cc: Chun Ye , ipsec@lists.tislabs.com Subject: Re: ipsec NICs? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Mar 2000 03:18:35 -0500 Message-Id: <20000309081840.E6ADB41F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20000309080905.A17678@regent.in.skynet.cz>, "Josef Pojsl" writes: > On Wed, Mar 08, 2000 at 01:42:52PM -0800, Chun Ye wrote: > > Windows 2000 does 3DES too. Just want to clarify. > > As far as I understand, this subthread is about international > availability. Are you saying that international versions > of Win2K are going to be equipped with 3DES IPsec? > I guess they would be limited to single DES... > I can't speak for 3DES, but they did get permission to export 128-bit crypto: http://www.microsoft.com/PressPass/press/2000/Jan00/encryptionPR.asp --Steve Bellovin From owner-ipsec@lists.tislabs.com Thu Mar 9 04:44:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA28332; Thu, 9 Mar 2000 04:44:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04624 Thu, 9 Mar 2000 06:22:36 -0500 (EST) Message-Id: <200003091128.GAA24444@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-ike-hash-revised-01.txt Date: Thu, 09 Mar 2000 06:28:35 -0500 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 : Fixing IKE Phase 1 & 2 Authentication HASH Author(s) : T. Kivinen Filename : draft-ietf-ipsec-ike-hash-revised-01.txt Pages : 8 Date : 08-Mar-00 This document defines new method of calculating the authentication HASH of the IKE [RFC-2409] protocol. It fixes known problems with the IKE. The way the HASH is currently defined in the [RFC-2409] does not authen- ticate the generic ISAKMP [RFC-2408] header, nor does it authenticate any extra payloads inside phase 1 packets. This causes a security prob- lem when using extra payloads as already defined in the IKE and DOI [RFC-2407] (vendor ID payload, INITIAL-CONTACT notification etc). This document defines three methods how to negotiate the new HASH method. All methods tries to be backward compatible as much as possible. Only one of those methods must be selected by the working group and all the other should be removed from this document. There is also suggestion how to fix the Phase 2 authentication hashes so that they will also authenti- cate the generic ISAKMP header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-hash-revised-01.txt 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-ike-hash-revised-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-ike-hash-revised-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: <20000308131641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-hash-revised-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-hash-revised-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000308131641.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Mar 9 04:48:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA28383; Thu, 9 Mar 2000 04:47:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04630 Thu, 9 Mar 2000 06:22:41 -0500 (EST) Message-Id: <200003091128.GAA24493@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-cbc-00.txt Date: Thu, 09 Mar 2000 06:28:40 -0500 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 : The Candidate AES Cipher Algorithms and Their Use With IPsec Author(s) : S. Frankel, R. Glenn, S. Kelly Filename : draft-ietf-ipsec-ciph-aes-cbc-00.txt Pages : 15 Date : 08-Mar-00 This document describes the use of the AES Cipher Algorithms in Ci- pher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Pay- load (ESP). This Internet Draft specifies the use of each of the 5 AES finalist candidates in the ESP Header. Once the AES cipher is chosen, this document will be changed to reflect that choice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-00.txt 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-cbc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20000308131656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-cbc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000308131656.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Mar 9 08:32:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04902; Thu, 9 Mar 2000 08:31:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05258 Thu, 9 Mar 2000 09:12:37 -0500 (EST) Date: 9 Mar 2000 00:10:35 -0000 Message-ID: <20000309001035.28083.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipsec@lists.tislabs.com Subject: MAC speeds References: <1FD60AE4DB6CD2118C420008C74C27B81D0518@baltimore.com> <006101bf830a$020c37d0$1e0101c8@ANDREWK2.TIMESTEP> <200003071655.SAA23058@torni.ssh.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen reports a time of 154000 cycles (308 microseconds) for HMAC-MD5 on 2048 bytes on a 500MHz Alpha. That's slower than today's fast ciphers, notably the AES candidates, which are below 40 cycles/byte. Some people seem to be making decisions on this basis. But there are faster implementations of MD5. Furthermore, there are much faster MACs. My hash127 takes under 9800 cycles, plus the time to encrypt one 16-byte block, on an Alpha, UltraSPARC, Pentium, Pentium-II, etc. The forgery chance/bit is provably below 1/2^130 if the encryption is secure. See http://cr.yp.to/hash127/faq.html for precise guarantees. ---Dan From owner-ipsec@lists.tislabs.com Thu Mar 9 09:02:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05343; Thu, 9 Mar 2000 09:02:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00211 Thu, 9 Mar 2000 10:19:21 -0500 (EST) Date: Thu, 9 Mar 2000 16:13:37 +0100 (MET) From: Bart Preneel To: Bill Manning cc: "D. J. Bernstein" , ipsec@lists.tislabs.com Subject: Re: MAC speeds In-Reply-To: <200003091455.GAA06198@zed.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes it can be made faster. See http://www.esat.kuleuven.ac.be/~bosselae/fast.html --Bart On Thu, 9 Mar 2000, Bill Manning wrote: > % > % Tero Kivinen reports a time of 154000 cycles (308 microseconds) for > % HMAC-MD5 on 2048 bytes on a 500MHz Alpha. > % > % That's slower than today's fast ciphers, notably the AES candidates, > % which are below 40 cycles/byte. Some people seem to be making decisions > % on this basis. > % > % But there are faster implementations of MD5. Furthermore, there are > % much faster MACs. > ... > % ---Dan > > I'm not sure that MD5 can be made too much faster. > see: > > http://www.isi.edu/~touch/pubs/sigcomm95.html > > --bill > From owner-ipsec@lists.tislabs.com Thu Mar 9 09:04:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05384; Thu, 9 Mar 2000 09:04:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05539 Thu, 9 Mar 2000 09:49:58 -0500 (EST) From: Bill Manning Message-Id: <200003091455.GAA06198@zed.isi.edu> Subject: Re: MAC speeds To: djb@cr.yp.to (D. J. Bernstein) Date: Thu, 9 Mar 2000 06:55:52 -0800 (PST) Cc: ipsec@lists.tislabs.com In-Reply-To: <20000309001035.28083.qmail@cr.yp.to> from "D. J. Bernstein" at Mar 09, 2000 12:10:35 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk % % Tero Kivinen reports a time of 154000 cycles (308 microseconds) for % HMAC-MD5 on 2048 bytes on a 500MHz Alpha. % % That's slower than today's fast ciphers, notably the AES candidates, % which are below 40 cycles/byte. Some people seem to be making decisions % on this basis. % % But there are faster implementations of MD5. Furthermore, there are % much faster MACs. ... % ---Dan I'm not sure that MD5 can be made too much faster. see: http://www.isi.edu/~touch/pubs/sigcomm95.html --bill From owner-ipsec@lists.tislabs.com Thu Mar 9 09:50:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06136; Thu, 9 Mar 2000 09:50:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00794 Thu, 9 Mar 2000 11:35:08 -0500 (EST) Date: Thu, 9 Mar 2000 11:41:03 -0500 Message-Id: <200003091641.LAA20425@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bart.Preneel@esat.kuleuven.ac.be Cc: bmanning@ISI.EDU, djb@cr.yp.to, ipsec@lists.tislabs.com Subject: Re: MAC speeds References: <200003091455.GAA06198@zed.isi.edu> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Bart" == Bart Preneel writes: Bart> Yes it can be made faster. See Bart> http://www.esat.kuleuven.ac.be/~bosselae/fast.html Bart> --Bart Bart> On Thu, 9 Mar 2000, Bill Manning wrote: >> % % Tero Kivinen reports a time of 154000 cycles (308 >> microseconds) for % HMAC-MD5 on 2048 bytes on a 500MHz Alpha. % % >> That's slower than today's fast ciphers, notably the AES >> candidates, % which are below 40 cycles/byte. Some people seem to >> be making decisions % on this basis. % % But there are faster >> implementations of MD5. Furthermore, there are % much faster MACs. >> ... % ---Dan >> >> I'm not sure that MD5 can be made too much faster. see: >> >> http://www.isi.edu/~touch/pubs/sigcomm95.html Antoon's numbers are quite impressive. On the other hand, the number quoted from Tero is very bad even for C code run through a poor compiler. I make it to be about 4800 cycles per hash block. I get about 1600 cycles per block on a MIPS processor, which is a single issue machine, for C code run through gcc. Neither has Rotate as a primitive instruction, so they are at a bit of a disadvantage compared to the x86, but it seems reasonable that you should be able to get down to about 1k cycles per block or so. paul From owner-ipsec@lists.tislabs.com Thu Mar 9 14:48:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10062; Thu, 9 Mar 2000 14:48:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02044 Thu, 9 Mar 2000 15:55:17 -0500 (EST) Date: Thu, 9 Mar 2000 23:01:11 +0200 (EET) Message-Id: <200003092101.XAA26384@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: I-D ACTION:draft-ietf-ipsec-ike-hash-revised-01.txt In-Reply-To: <200003091128.GAA24444@ietf.org> References: <200003091128.GAA24444@ietf.org> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Internet-Drafts@ietf.org writes: > 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 : Fixing IKE Phase 1 & 2 Authentication HASH > Author(s) : T. Kivinen > Filename : draft-ietf-ipsec-ike-hash-revised-01.txt > Pages : 8 > Date : 08-Mar-00 > Here is a short summary of the changes in the document: * Added section to describe how phase 2 authentication hashes should be changed to fix the unauthenticated isakmp header problem in the phase 2 exchnages. * Changed the authentication hash to be hash of hashes instead of hash of the full packets. This way the memory consumption used to before calculating the hash is smaller, and the same per packet hash can also used to detect retransmission packets. * Added more text saying that the template hash/sig payload must contain generic payload header, but only the contents of the hash/sig field itself is all zeros. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Mar 9 16:43:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11879; Thu, 9 Mar 2000 16:43:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02619 Thu, 9 Mar 2000 18:21:18 -0500 (EST) Date: Fri, 10 Mar 2000 01:27:16 +0200 (EET) Message-Id: <200003092327.BAA21573@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: Tero Kivinen To: "D. J. Bernstein" Cc: ipsec@lists.tislabs.com Subject: MAC speeds In-Reply-To: <20000309001035.28083.qmail@cr.yp.to> References: <1FD60AE4DB6CD2118C420008C74C27B81D0518@baltimore.com> <006101bf830a$020c37d0$1e0101c8@ANDREWK2.TIMESTEP> <200003071655.SAA23058@torni.ssh.fi> <20000309001035.28083.qmail@cr.yp.to> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 28 min X-Total-Time: 137 min Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA02611 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk D. J. Bernstein writes: > Tero Kivinen reports a time of 154000 cycles (308 microseconds) for > HMAC-MD5 on 2048 bytes on a 500MHz Alpha. BTW, that compilation was without optimizations, i.e for debugging compilation. When using fully optimized compilation the speed for 2048 byte HMAC-MD5 is 140 microseconds. With bigger blocks the speed of the HMAC-MD5 is about 29 MB/sec compared to the 2 MB/sec for 3des. That 29 MB/sec gives about 16 cycles / byte. For that shorter buffer (2048 bytes) the speed is 34 cycles / byte. For even shorter buffer (256 bytes) the speed drops to 53 cycles / byte (the constant overhead of the HMAC algorithm grows quite large at that point). > That's slower than today's fast ciphers, notably the AES candidates, > which are below 40 cycles/byte. Some people seem to be making decisions > on this basis. The speed of the AES ciphers in our library are: twofish 12 MB/sec 40 cycles/byte rc6 10 MB/sec 48 cycles/byte mars 8 MB/sec 60 cycles/byte rijndael 10 MB/sec 48 cycles/byte So if change my previous mail to use numbers from the optimizated compilation: ---------------------------------------------------------------------- If we assume IKE SA is using 3des-md5, then the speeds are about following: 1) md5(last-cbc-block || message-id) = 3 µs 3des-cbc of one block = 5 µs 3des-cbc of the rest of the blocks = 21 µs in total it is going to be 8 µs + 21 µs + 15 µs. 2) Hmac-md5 of 64 bytes = 15 µs. I.e in the DoS case you are saving for 7 µs, but in addition you need to do the extra decryption for the rest of the packet, so for each valid packet you waste 29 µs (total decryption time + the IV generation time). If the packet contains 200 byte spi list payload also, then the timing is going to be: 1) md5(last-cbc-block || message-id) = 3 µs 3des-cbc of one block = 5 µs 3des-cbc of the rest of the blocks = 107 µs in total it is going to be 8 µs + 107 µs + 27 µs. 2) Hmac-md5 of 256 bytes = 27 µs I.e in the DoS case you are saving for for 19 µs, but you are then wasting the 115 µs for each valid packet. For blowfish-cbc and md5 the values in the case 1 are little bit different: 1) md5(last-cbc-block || message-id) = 3 µs blowfish-cbc of one block = 1 µs blowfish-cbc of the rest of the blocks = 4 µs So for the DoS case you save 11 µs for the DoS packet and do only 8 µs extra work for valid packet. For the larger packet the numbers are: 1) md5(last-cbc-block || message-id) = 3 µs blowfish-cbc of one block = 1 µs blowfish-cbc of the rest of the blocks = 19 µs And for DoS case you save 23 µs, and you loose 23 µs in the valid packet case. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Mar 9 17:24:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA12737; Thu, 9 Mar 2000 17:24:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02719 Thu, 9 Mar 2000 19:00:41 -0500 (EST) From: fisher@hollywood.engr.sgi.com (William Fisher) Message-Id: <200003100003.QAA23788@hollywood.engr.sgi.com> Subject: Re: MAC speeds To: pkoning@xedia.com (Paul Koning) Date: Thu, 10 Mar 100 16:03:01 -0800 (PST) Cc: Bart.Preneel@esat.kuleuven.ac.be, bmanning@ISI.EDU, djb@cr.yp.to, ipsec@lists.tislabs.com, fisher@hollywood.engr.sgi.com (William Fisher) In-Reply-To: <200003091641.LAA20425@tonga.xedia.com> from "Paul Koning" at Mar 10, 0 11:41:03 am Reply-To: fisher@sgi.com X-Mailer: ELM [version 2.4 PL3] Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > >>>>> "Bart" == Bart Preneel writes: > > Bart> Yes it can be made faster. See > Bart> http://www.esat.kuleuven.ac.be/~bosselae/fast.html > > Bart> --Bart > > Bart> On Thu, 9 Mar 2000, Bill Manning wrote: > > >> % % Tero Kivinen reports a time of 154000 cycles (308 > >> microseconds) for % HMAC-MD5 on 2048 bytes on a 500MHz Alpha. % % > >> That's slower than today's fast ciphers, notably the AES > >> candidates, % which are below 40 cycles/byte. Some people seem to > >> be making decisions % on this basis. % % But there are faster > >> implementations of MD5. Furthermore, there are % much faster MACs. > >> ... % ---Dan > >> > >> I'm not sure that MD5 can be made too much faster. see: > >> > >> http://www.isi.edu/~touch/pubs/sigcomm95.html > > Antoon's numbers are quite impressive. On the other hand, the number > quoted from Tero is very bad even for C code run through a poor > compiler. I make it to be about 4800 cycles per hash block. I get > about 1600 cycles per block on a MIPS processor, which is a single > issue machine, for C code run through gcc. Neither has Rotate as a > primitive instruction, so they are at a bit of a disadvantage compared > to the x86, but it seems reasonable that you should be able to get > down to about 1k cycles per block or so. > > paul > On the gcc code generated for the MD5 case, did any of the following attached MIPS IV instructions get emitted to partially overcome the lack of a generic rotate instruction on the MIPS processor? I will compile your code if you send me a pointer to it using SGI compilers on processors with support MIPS III and the MIPS IV instruction sets. I didn't find a pointer to the code on Antoon's web site containing the Pentium numbers. Since the R10K/12K series are out-of-order execution processors with two arithmetic units, which possibly might reduce the 1600 cycles per block count. You can get absolute clock counts on the R10K/R12K series via appropriate reading of the right hardware register, to avoid estimating the true amount of overlap. From the MIPS IV Instruction Set Manual, Version 3.1, dated January 1995, pages A-140 through A-143 the supported instructions include: 1) SRA => Shift Word Right Arithmetic SRA rd,rt,sa Arithmetic right shift a word by a fixed number of bits On 32-Bit Processors: The contents of the low-order 32-bit word of GPR 'rt' are shifted right, duplicating the sign-bit(bit31) in the emptied bits; The word results is placed in GPR 'rd'. The bit shift count is specified by 'sa'. If 'rd' is a 64-bit register, the result word is sign-extended. On 64-Bit Processors: On 64-bit processorsm if GPR 'rt' does not contain a sign-extended 32-bit value (Bits 63..31) then the results of the operation is undefined. 2) SRAV => Shift Word Right Arithmetic Variable SRA sd,rt,rs Arithmetic right shift a word by a variable number of bits Similar to SRA but where the right shift count is contained in the low-order 5 bits of the GPR 'rs' 3) SRL => Shift Word Right Logical SRA rd,rt,sa Logical right shift a word by a fixed number of bits. On 32-Bit Processors: The contents of the low-order 32-bit word of GPR 'rt' are shifted right, inserting zero's into the empied bits; The word results is placed in GPR 'rd'. The bit shift count is specified by 'sa'. If 'rd' is a 64-bit register, the result word is sign-extended. On 64-Bit Processors: On 64-bit processorsm if GPR 'rt' does not contain a sign-extended 32-bit value (Bits 63..31 equal) then the results of the operation is undefined. 4) SRLV => Shift Word Right Logical Variable SRA rd,rt,rs Logical right shift a word by a variable number of bits. Similar to SRL but where the right shift count is contained in the low-order 5 bits of the GPR 'rs' 5) SWL => Store Work Left SWL rt,offset(base) Store the most-significant part of the word to an unaligned memory address. The 16-bit signed 'offset' is added to the contents of GPR 'base' to form an effective address (EffAddr) EffAddr is the address of the most-significant of four consecutive bytes forming a workd in memory (W) starting at an arbitrary byte coundary. A part of W, the most significant one to four bytes, is in the aligned word containing EffAddr. The same number of the most sighnificant (left) bytes from the word in GPR 'rt' are stored into these bytes of W. If GPR 'rt'is a 64-bit register, the source word is the low word of the register. The gory details in pictures can be found in the reference manual. 6) SWR => Store Work Right Store the least-significant part of the word to an unaligned memory address. Similar to SWL, except the least-significant(right) bytes from the word in GPR 'rt' are stored into these bytes in W. -- Bill From owner-ipsec@lists.tislabs.com Fri Mar 10 04:00:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA14087; Fri, 10 Mar 2000 04:00:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA04680 Fri, 10 Mar 2000 05:25:09 -0500 (EST) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D27D2D@new-exc1.ctron.com> From: "Waters, Stephen" To: ipsec@lists.tislabs.com Subject: VPN traffic and Firewall traffic in the same 'box' Date: Fri, 10 Mar 2000 10:30:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm interested in what folk think on the 'wisdom' of performing Firewall and VPN gateway (IPSEC) features in the same system/gateway/router. Some customers are apprehensive about dealing with 'dirty' traffic and 'clean' traffic in the same security system could present risks, others are happy for these features to co-exist. The company I work with, and I'm sure many others, have a few 'fully managed' firewalls/DMZ to reduce the risks, and require small remote sites to use these main firewalls. The VPN equipment is separate, even with independent Internet feeds. This model has some scalability issues I guess, and it seems wasteful for remote sites using Internet-based VPNs to access the corporate network to not have their own direct firewall features. Others have augmented an existing firewall with VPN functionality, or purchase dual personality devices from the outset. I have been involved in some LAN-LAN VPN offerings that offer a good price and SLA on the understanding that the connection will not allow (simple filtering) traffic onto the wider Internet, but just between sister LAN sites. I guess this keeps the 'off-network' traffic costs down for the provider. In this case, simple access filters (on the private interface) and VPN on the public side, would seem plenty. Views? Cheers, Steve. From owner-ipsec@lists.tislabs.com Fri Mar 10 04:43:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA17099; Fri, 10 Mar 2000 04:43:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04927 Fri, 10 Mar 2000 06:21:19 -0500 (EST) Message-Id: <200003101127.GAA28033@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-ike-auth-ecdsa-00.txt Date: Fri, 10 Mar 2000 06:27:11 -0500 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 : IKE Authentication Using ECDSA Author(s) : P. Fahn Filename : draft-ietf-ipsec-ike-auth-ecdsa-00.txt Pages : 4 Date : 09-Mar-00 This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) protocol. ECDSA provides authentication and non-repudiation with benefits of computational efficiency, small signature sizes, and minimal bandwidth, compared to other available digital signature methods. This document adds ECDSA capability to IKE without introducing any changes to existing IKE operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-00.txt 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-ike-auth-ecdsa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20000309135830.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-auth-ecdsa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000309135830.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Mar 10 11:12:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25639; Fri, 10 Mar 2000 11:12:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA06301 Fri, 10 Mar 2000 12:13:30 -0500 (EST) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Fri, 10 Mar 2000 19:19:38 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: "D. J. Bernstein" cc: ipsec@lists.tislabs.com Subject: Re: MAC speeds In-Reply-To: <20000309001035.28083.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 9 Mar 2000, D. J. Bernstein wrote: > Tero Kivinen reports a time of 154000 cycles (308 microseconds) for > HMAC-MD5 on 2048 bytes on a 500MHz Alpha. > > That's slower than today's fast ciphers, notably the AES candidates, > which are below 40 cycles/byte. Some people seem to be making decisions > on this basis. Just a quick note that AES candidates run _much_ faster on a Pentium II but also on Alpha. For example, my own implementations of RC6, Rijndael, Twofish and MARS on P2 run with speed 13.9, 14.8, 17.9, 19.1 cycles per byte, respectively. On Alpha 21264, the best implementations obtain in average 20-30 cycles per byte - but I also guess they are much less optimised than mine. For comparison, Bosselaers' SHA-1 implementation (on Pentium, not on Pentium II) takes 13.1 cycles per byte. (and RIPEMD-160 --- 15.8 --- is slower than RC6 and Rijndael). (As I hope up-to-date) speed Information about AES candidates can be obtained from http://home.cyber.ee/helger/aes. If anybody knows personally something that is missing from this table there, please let me know! Helger Lipmaa http://home.cyber.ee/helger From owner-ipsec@lists.tislabs.com Fri Mar 10 13:20:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27324; Fri, 10 Mar 2000 13:20:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA07032 Fri, 10 Mar 2000 14:53:15 -0500 (EST) To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@cs.berkeley.edu (David A. Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Q: Why IPSEC to be used only in CBC mode & not other like CFBor OFB? Date: 10 Mar 2000 11:21:18 -0800 Organization: A poorly-installed InterNetNews site Lines: 26 Distribution: isaac Message-ID: <8abhve$hd2$1@blowfish.isaac.cs.berkeley.edu> References: <38C437F4.3C7A71EF@cisco.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In article <38C437F4.3C7A71EF@cisco.com>, David A. McGrew wrote: > there are some attacks to which stream ciphers, and ECB, OFB, and > counter modes are more vulnerable than CBC mode. Biham's key collision > attack and Hellman's time-memory tradeoff attack [...] I have to disagree with you on this point. I believe the attacks you cited only work against OFB or counter mode if you use a fixed IV (e.g., all zeros). But it is well-known that this is a bad idea, no matter what mode you use. So I don't think these considerations should prevent us from using counter mode. Note that Steve Kent has pointed out concerns with the stream cipher modes (although one can plausibly argue that there are systems-level countermeasures available). > As has already been pointed out, the O(2^32) attack against CBC is a > chosen plaintext attack, and it only recovers a small number of unknown > plaintext blocks. I think there might be a small typo here. The birthday attack against CBC mode is a ciphertext-only attack (where a little bit of information on the plaintext leaks), and is definitely not a chosen plaintext attack. From owner-ipsec@lists.tislabs.com Sat Mar 11 07:49:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02521; Sat, 11 Mar 2000 07:49:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09649 Sat, 11 Mar 2000 09:00:40 -0500 (EST) Message-ID: <38CA536A.7913988C@cisco.com> Date: Sat, 11 Mar 2000 06:08:42 -0800 From: "David A. McGrew" X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "David A. Wagner" CC: ipsec@lists.tislabs.com Subject: Re: Q: Why IPSEC to be used only in CBC mode & not other like CFBor OFB? References: <38C437F4.3C7A71EF@cisco.com> <8abhve$hd2$1@blowfish.isaac.cs.berkeley.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, thanks for your comments, more inline: "David A. Wagner" wrote: > > In article <38C437F4.3C7A71EF@cisco.com>, > David A. McGrew wrote: > > there are some attacks to which stream ciphers, and ECB, OFB, and > > counter modes are more vulnerable than CBC mode. Biham's key collision > > attack and Hellman's time-memory tradeoff attack [...] > > I have to disagree with you on this point. > > I believe the attacks you cited only work against OFB or counter mode > if you use a fixed IV (e.g., all zeros). But it is well-known that > this is a bad idea, no matter what mode you use. > yes, this is an important point. Still, if the key is longer than the blocksize, Biham's attack is more efficient than an exhaustive search. > So I don't think these considerations should prevent us from using > counter mode. I agree. I did not mean to suggest that any modes be excluded from consideration, but rather to reply to Rupesh's request for information. David From owner-ipsec@lists.tislabs.com Sat Mar 11 09:20:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03150; Sat, 11 Mar 2000 09:20:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10229 Sat, 11 Mar 2000 11:10:39 -0500 (EST) Message-Id: <200003111616.QAA16818@orchard.arlington.ma.us> To: Bart Preneel cc: Bill Manning , "D. J. Bernstein" , ipsec@lists.tislabs.com Subject: Re: MAC speeds In-Reply-To: Message from Bart Preneel of "Thu, 09 Mar 2000 16:13:37 +0100." Date: Sat, 11 Mar 2000 11:16:26 -0500 From: Bill Sommerfeld Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Among other tweaks, the existing freeware md5 implementations I've seen typically have at least one unnecessary copy which can be avoided when you know something about the processor you're targeting. I don't have numbers handy from when I tuned it at a previous job, but just eliminating that copy made a significant difference. - Bill From owner-ipsec@lists.tislabs.com Mon Mar 13 11:32:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20551; Mon, 13 Mar 2000 11:32:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17176 Mon, 13 Mar 2000 12:25:06 -0500 (EST) Message-Id: <200003101741.JAA05388@omega.cisco.com> X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 10 Mar 2000 09:53:55 -0800 To: ipsec@lists.tislabs.com From: Gopal Dommety Subject: GRE extensions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello: I am attaching the GRE addendum/extensions. As you go through the draft at places identified by # there are request for comments. I have split the sequence no into two subfeilds (the other option is to define an acknowledgement like PPTP WHEN such a need it felt). Please send your comments to gre@ops.ietf.org mailing list. you can subscribe to this mailing list by sending an email to gre-request@ops.ietf.org Thanks Gopal Network Working Group Gopal Dommety INTERNET DRAFT cisco Systems March 2000 Expires October 2000 Key and Sequence Number Extensions to GRE draft-dommety-gre-ext-00.txt Status of this Memo This document is a submission by the Network Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the gre@ops.ietf.org mailing list. Distribution of this memo is unlimited. This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE (Generic Routing Encapsulation) Header [1]. GRE specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. Dommety [Page 1] Internet Draft Key and Sequence Number Extensions to GRE February 2000 1. Introduction Current specification of Generic Routing Encapsulation [1] specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This document describes enhancements by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1]. The Key field is used to create separate sub-tunnels within a GRE Tunnel. Sequence Number field is used to maintain sequence of packets within a GRE Tunnel. 1.1. Specification Language The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. In addition, the following words are used to signify the requirements of the specification. Silently discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter. 2. Extensions to GRE Header The GRE packet header[1] has the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The proposed GRE header will have the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Sequence Number (Optional)| Tx Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key Present (bit 2) If the Key Present bit is set to 1, then it indicates that the Key field is present in the GRE header. Otherwise, the Key field is not present in the GRE header. Sequence Number Present (bit 3) If the Sequence Number Present bit is set to 1, then it indicates that the Sequence Number field is present. Otherwise, the Sequence Number field is not present in the GRE header. The Key and Sequence Present bits are chosen to be compatible with RFC 1701 [2]. 2.1. Key Field (4 octets) The Key field contains a four octet number which was inserted by the encapsulator. The actual method by which this Key is obtained is beyond the scope of this document. Key field is intended to be used for creating separate sub-tunnels within a GRE Tunnel and the Key field identifies the sub-tunnel. 2.2. Sequence Number (4 octets) The Sequence Number field is divided into two sub-fields (Tx and Rx sequence number). These subfields are inserted by the encapsulator when Sequence Number Present Bit is set . Tx Sequence Number MUST be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. The intended use of the Tx Sequence Field is to provide unreliable and in-order delivery. If the Key present bit (bit 2) is set, the sequence number is specific to the sub-tunnel identified by the Key field. The Tx sequence number value ranges from 1 to 65535. The first datagram is sent with a Tx sequence number of 1. The Tx sequence number is thus a free running counter represented modulo 65536, with the exception that 1 is used when modulo 65536 results in 0 (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0. #Q The Rx can be the Tx sequence number of the last successfully decap pack. And say that how you use this info is implementation dependent. I am currently saying Rx sequence no is set to 0. Comments? When the decapsulator receives an out-of sequence packet it SHOULD be silently discarded. Additionally, reordering of out-of sequence packets MAY be performed by the decapsulator for improved performance and tolerance to reordering in the network (since the state of the stateful compression or encryption is reset by packet loss, it might help the performance to tolerate some amount of packet reordering in the network by buffering). Exact buffering schemes are outside the scope of this document. Note that the Tx sequence number is used to detect lost packets and/or restore the original sequence of packets that may have been reordered during transport. A packet is considered an out-of-sequence packet if the Tx sequence number of the received packet is lesser than or equal to the Tx sequence number of last successfully decapsulated packet. The Tx sequence number of a received message is considered less than or equal to the last successfully received Tx sequence number if its value lies in the range of the last received Tx sequence number and the preceding 32766 values, inclusive. For example, if the last successfully received Tx sequence number was 15, then messages with Tx sequence numbers 1 through 15, as well as 32784 through 65535, would be considered less than or equal. Such a message would be considered an out-of-sequence packet and ignored from processing. If the received packet is an in-sequence packet, it is successfully de capsulated. Note that the TX sequence number is used to detect lost packets and/or restore the original sequence of packets (with buffering) that may have been reordered during transport. #C I have considered trying to have a different starting point for TX sequence nos during rollover and initial starting point. This would let a node identify if the other end reset (like agent advertisement sequence no to identify reboot and normal rollover). This is useful if we keep turning on and off sequence nos option in a tunnel. Since there is no security it is easy for others to reset the sequence also. Comments? 3. IANA Considerations 4. Acknowledgments 5. References [1] Farinacci, D., Li, T., Hnaks, S., Meyer, D. and Traina, P., "Generic Routing Encapsulation (GRE)," draft-meyer-gre-update-03.txt, January 2000. [2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems, October 1994. [3] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Dommety [Page 4] Internet Draft Key and Sequence Number extensions to GRE February 2000 Author Information Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: gdommety@cisco.com Dommety Thank You. Regards, Gopal ------------------------------------------------------------------------------------------------------------- Gopal Dommety 408 525 1404 gdommety@cisco.com Cisco Systems, San Jose, CA, 95051 From owner-ipsec@lists.tislabs.com Mon Mar 13 11:34:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20656; Mon, 13 Mar 2000 11:34:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17199 Mon, 13 Mar 2000 12:26:58 -0500 (EST) Message-Id: <200003101733.JAA04158@omega.cisco.com> X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 10 Mar 2000 09:45:57 -0800 To: udlr@sophia.inria.fr From: Gopal Dommety Subject: GRE extensions Cc: msdp@antc.uoregon.edu, ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello: I am attaching the GRE addendum/extensions. As you go through the draft at places identified by # there are request for comments. I have split the sequence no into two subfeilds (the other option is to define an acknowledgement like PPTP WHEN such a need it felt). Please send your comments to gre@ops.ietf.org mailing list. you can subscribe to this mailing list by sending an email to gre-request@ops.ietf.org Thanks Gopal Network Working Group Gopal Dommety INTERNET DRAFT cisco Systems March 2000 Expires October 2000 Key and Sequence Number Extensions to GRE draft-dommety-gre-ext-00.txt Status of this Memo This document is a submission by the Network Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the gre@ops.ietf.org mailing list. Distribution of this memo is unlimited. This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE (Generic Routing Encapsulation) Header [1]. GRE specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. Dommety [Page 1] Internet Draft Key and Sequence Number Extensions to GRE February 2000 1. Introduction Current specification of Generic Routing Encapsulation [1] specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This document describes enhancements by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1]. The Key field is used to create separate sub-tunnels within a GRE Tunnel. Sequence Number field is used to maintain sequence of packets within a GRE Tunnel. 1.1. Specification Language The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. In addition, the following words are used to signify the requirements of the specification. Silently discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter. 2. Extensions to GRE Header The GRE packet header[1] has the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The proposed GRE header will have the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Sequence Number (Optional)| Tx Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key Present (bit 2) If the Key Present bit is set to 1, then it indicates that the Key field is present in the GRE header. Otherwise, the Key field is not present in the GRE header. Sequence Number Present (bit 3) If the Sequence Number Present bit is set to 1, then it indicates that the Sequence Number field is present. Otherwise, the Sequence Number field is not present in the GRE header. The Key and Sequence Present bits are chosen to be compatible with RFC 1701 [2]. 2.1. Key Field (4 octets) The Key field contains a four octet number which was inserted by the encapsulator. The actual method by which this Key is obtained is beyond the scope of this document. Key field is intended to be used for creating separate sub-tunnels within a GRE Tunnel and the Key field identifies the sub-tunnel. 2.2. Sequence Number (4 octets) The Sequence Number field is divided into two sub-fields (Tx and Rx sequence number). These subfields are inserted by the encapsulator when Sequence Number Present Bit is set . Tx Sequence Number MUST be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. The intended use of the Tx Sequence Field is to provide unreliable and in-order delivery. If the Key present bit (bit 2) is set, the sequence number is specific to the sub-tunnel identified by the Key field. The Tx sequence number value ranges from 1 to 65535. The first datagram is sent with a Tx sequence number of 1. The Tx sequence number is thus a free running counter represented modulo 65536, with the exception that 1 is used when modulo 65536 results in 0 (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0. #Q The Rx can be the Tx sequence number of the last successfully decap pack. And say that how you use this info is implementation dependent. I am currently saying Rx sequence no is set to 0. Comments? When the decapsulator receives an out-of sequence packet it SHOULD be silently discarded. Additionally, reordering of out-of sequence packets MAY be performed by the decapsulator for improved performance and tolerance to reordering in the network (since the state of the stateful compression or encryption is reset by packet loss, it might help the performance to tolerate some amount of packet reordering in the network by buffering). Exact buffering schemes are outside the scope of this document. Note that the Tx sequence number is used to detect lost packets and/or restore the original sequence of packets that may have been reordered during transport. A packet is considered an out-of-sequence packet if the Tx sequence number of the received packet is lesser than or equal to the Tx sequence number of last successfully decapsulated packet. The Tx sequence number of a received message is considered less than or equal to the last successfully received Tx sequence number if its value lies in the range of the last received Tx sequence number and the preceding 32766 values, inclusive. For example, if the last successfully received Tx sequence number was 15, then messages with Tx sequence numbers 1 through 15, as well as 32784 through 65535, would be considered less than or equal. Such a message would be considered an out-of-sequence packet and ignored from processing. If the received packet is an in-sequence packet, it is successfully de capsulated. Note that the TX sequence number is used to detect lost packets and/or restore the original sequence of packets (with buffering) that may have been reordered during transport. #C I have considered trying to have a different starting point for TX sequence nos during rollover and initial starting point. This would let a node identify if the other end reset (like agent advertisement sequence no to identify reboot and normal rollover). This is useful if we keep turning on and off sequence nos option in a tunnel. Since there is no security it is easy for others to reset the sequence also. Comments? 3. IANA Considerations 4. Acknowledgments 5. References [1] Farinacci, D., Li, T., Hnaks, S., Meyer, D. and Traina, P., "Generic Routing Encapsulation (GRE)," draft-meyer-gre-update-03.txt, January 2000. [2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems, October 1994. [3] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Dommety [Page 4] Internet Draft Key and Sequence Number extensions to GRE February 2000 Author Information Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: gdommety@cisco.com Dommety Thank You. Regards, Gopal ------------------------------------------------------------------------------------------------------------- Gopal Dommety 408 525 1404 gdommety@cisco.com Cisco Systems, San Jose, CA, 95051 From owner-ipsec@lists.tislabs.com Mon Mar 13 11:39:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20897; Mon, 13 Mar 2000 11:39:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17190 Mon, 13 Mar 2000 12:25:57 -0500 (EST) Message-ID: <71984F8FB76AD211AC3E00A0C9C578C7020DF6E2@hasmsx32.iil.intel.com> From: "Elzur, Uri" To: Tero Kivinen , "D. J. Bernstein" Cc: ipsec@lists.tislabs.com Subject: RE: MAC speeds Date: Mon, 13 Mar 2000 03:03:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id FAA15678 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen writes: >The speed of the AES ciphers in our library are: > >twofish 12 MB/sec 40 cycles/byte >rc6 10 MB/sec 48 cycles/byte >mars 8 MB/sec 60 cycles/byte >rijndael 10 MB/sec 48 cycles/byte Why is Serpent not on this list? Thx Uri Elzur uri.elzur@intel.com -----Original Message----- From: Tero Kivinen [mailto:kivinen@ssh.fi] Sent: Friday, March 10, 2000 1:27 AM To: D. J. Bernstein Cc: ipsec@lists.tislabs.com Subject: MAC speeds D. J. Bernstein writes: > Tero Kivinen reports a time of 154000 cycles (308 microseconds) for > HMAC-MD5 on 2048 bytes on a 500MHz Alpha. BTW, that compilation was without optimizations, i.e for debugging compilation. When using fully optimized compilation the speed for 2048 byte HMAC-MD5 is 140 microseconds. With bigger blocks the speed of the HMAC-MD5 is about 29 MB/sec compared to the 2 MB/sec for 3des. That 29 MB/sec gives about 16 cycles / byte. For that shorter buffer (2048 bytes) the speed is 34 cycles / byte. For even shorter buffer (256 bytes) the speed drops to 53 cycles / byte (the constant overhead of the HMAC algorithm grows quite large at that point). > That's slower than today's fast ciphers, notably the AES candidates, > which are below 40 cycles/byte. Some people seem to be making decisions > on this basis. The speed of the AES ciphers in our library are: twofish 12 MB/sec 40 cycles/byte rc6 10 MB/sec 48 cycles/byte mars 8 MB/sec 60 cycles/byte rijndael 10 MB/sec 48 cycles/byte So if change my previous mail to use numbers from the optimizated compilation: ---------------------------------------------------------------------- If we assume IKE SA is using 3des-md5, then the speeds are about following: 1) md5(last-cbc-block || message-id) = 3 µs 3des-cbc of one block = 5 µs 3des-cbc of the rest of the blocks = 21 µs in total it is going to be 8 µs + 21 µs + 15 µs. 2) Hmac-md5 of 64 bytes = 15 µs. I.e in the DoS case you are saving for 7 µs, but in addition you need to do the extra decryption for the rest of the packet, so for each valid packet you waste 29 µs (total decryption time + the IV generation time). If the packet contains 200 byte spi list payload also, then the timing is going to be: 1) md5(last-cbc-block || message-id) = 3 µs 3des-cbc of one block = 5 µs 3des-cbc of the rest of the blocks = 107 µs in total it is going to be 8 µs + 107 µs + 27 µs. 2) Hmac-md5 of 256 bytes = 27 µs I.e in the DoS case you are saving for for 19 µs, but you are then wasting the 115 µs for each valid packet. For blowfish-cbc and md5 the values in the case 1 are little bit different: 1) md5(last-cbc-block || message-id) = 3 µs blowfish-cbc of one block = 1 µs blowfish-cbc of the rest of the blocks = 4 µs So for the DoS case you save 11 µs for the DoS packet and do only 8 µs extra work for valid packet. For the larger packet the numbers are: 1) md5(last-cbc-block || message-id) = 3 µs blowfish-cbc of one block = 1 µs blowfish-cbc of the rest of the blocks = 19 µs And for DoS case you save 23 µs, and you loose 23 µs in the valid packet case. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Mar 13 11:41:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21029; Mon, 13 Mar 2000 11:41:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17191 Mon, 13 Mar 2000 12:26:02 -0500 (EST) Date: 11 Mar 2000 20:10:34 -0000 Message-ID: <20000311201034.28120.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipsec@lists.tislabs.com Subject: Re: MAC speeds References: <20000309001035.28083.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Helger Lipmaa writes: > For comparison, Bosselaers' SHA-1 implementation (on Pentium, not on > Pentium II) takes 13.1 cycles per byte. My MAC takes 4.4 cycles per byte on the original Pentium. (This comparison is slightly unfair, because my MAC provides 128 bits of security, while SHA-1-based MACs can hope for 160 bits of security.) ---Dan From owner-ipsec@lists.tislabs.com Mon Mar 13 21:05:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA12291; Mon, 13 Mar 2000 21:05:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19426 Mon, 13 Mar 2000 22:31:58 -0500 (EST) Message-ID: <38CDB40A.83EBE1DB@isi.edu> Date: Mon, 13 Mar 2000 19:37:46 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipsec@lists.tislabs.com, touch@ISI.EDU, larse@ISI.EDU Subject: Summary of transport mode use in overlay nets References: <200002172232.OAA27551@rum.isi.edu> <38AD7B5E.2783D9DE@mam.gov.tr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To follow-up on the earlier discussion of the use of transport mode for overlay networks, the following I-D was submitted on Friday. While I didn't get an ACK, I also didn't get a NACK either :-) It describes our use of IPSEC transport mode in the X-Bone. Until it is available 'at the usual places', it can be obtained at: http://www.isi.edu/touch/pubs/ipsec-vpn-00.txt (FYI - 'ipsec' in the proposed filename refers to the protocol, not the WG) I hope to discuss this further in Adelaide. -- Joe INTERNET-DRAFT Joe Touch and Lars Eggert draft-touch-ipsec-vpn-00.txt USC/ISI March 10, 2000 Expires: Sept. 10, 2000 Use of IPSEC Transport Mode for Virtual Networks Abstract This document addresses the use of IPSEC to secure the virtual links of an overlay network. It addresses how IPSEC tunnel mode can conflict with dynamic routing in an overlay, due to the dependence of both the security association (SA) and the IP tunnel encapsulation header on the header of the incoming packet. An alternative is proposed, where IP tunnel encapsulation occurs as a separate initial step, followed by IPSEC transport mode on the result. The tunnel header is determined by the source header, and the SA is determined by the tunnel header. The result is consistent with dynamic routing in the overlay. This document discusses this alternative, and its impact on IPSEC. -- From owner-ipsec@lists.tislabs.com Tue Mar 14 07:42:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11349; Tue, 14 Mar 2000 07:42:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21331 Tue, 14 Mar 2000 08:46:21 -0500 (EST) Message-ID: <71984F8FB76AD211AC3E00A0C9C578C702157335@hasmsx32.iil.intel.com> From: "Elzur, Uri" To: "D. J. Bernstein" , ipsec@lists.tislabs.com Subject: RE: MAC speeds Date: Mon, 13 Mar 2000 11:06:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk D. J. Bernstein writes: >My MAC takes 4.4 cycles per byte on the original Pentium. Does it include the HMAC function? What is the sensitivity per data size? thx Uri Elzur uri.elzur@intel.com -----Original Message----- From: D. J. Bernstein [mailto:djb@cr.yp.to] Sent: Saturday, March 11, 2000 10:11 PM To: ipsec@lists.tislabs.com Subject: Re: MAC speeds Helger Lipmaa writes: > For comparison, Bosselaers' SHA-1 implementation (on Pentium, not on > Pentium II) takes 13.1 cycles per byte. My MAC takes 4.4 cycles per byte on the original Pentium. (This comparison is slightly unfair, because my MAC provides 128 bits of security, while SHA-1-based MACs can hope for 160 bits of security.) ---Dan From owner-ipsec@lists.tislabs.com Tue Mar 14 10:32:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14367; Tue, 14 Mar 2000 10:32:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22112 Tue, 14 Mar 2000 11:57:28 -0500 (EST) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Tue, 14 Mar 2000 19:03:28 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: "Elzur, Uri" cc: "D. J. Bernstein" , ipsec@lists.tislabs.com Subject: RE: MAC speeds In-Reply-To: <71984F8FB76AD211AC3E00A0C9C578C702157335@hasmsx32.iil.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 13 Mar 2000, Elzur, Uri wrote: > D. J. Bernstein writes: > >My MAC takes 4.4 cycles per byte on the original Pentium. > > Does it include the HMAC function? What is the sensitivity per data size? And may be the most important question. Where is it published (but on web)? How much scrutinity has it achieved from community? Helger From owner-ipsec@lists.tislabs.com Tue Mar 14 12:53:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16921; Tue, 14 Mar 2000 12:53:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23110 Tue, 14 Mar 2000 13:53:16 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Subject: Heartbeats draft available Date: Tue, 14 Mar 2000 14:05:45 -0500 Message-Id: <000a01bf8de8$4d951c10$1e0101c8@ANDREWK2.TIMESTEP> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, The heartbeats draft is now available (actually it has been for some time) at http://search.ietf.org/internet-drafts/draft-krywaniuk-ipsec-heartbeats-00.t xt. Sorry for the late announcement. The reason for the delay is that I was expecting it to be filed as a WG document instead of a private submission, but apparently there was some miscommunication somewhere along the line. I will get this sorted out later. In the meantime: --- Internet Engineering Task Force Andrew Krywaniuk IP Security Working Group Newbridge Networks Corporation Internet Draft T. Kivinen SSH Communications Security March 8, 2000 Using Isakmp Heartbeats for Dead Peer Detection Abstract This document describes a method for sending heartbeat packets (sometimes called keep-alives) across an ISAKMP SA in order to detect when a peer has crashed or has become otherwise unreachable. A method for negotiating the heartbeat parameters is also provided. --- Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Tue Mar 14 15:12:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19374; Tue, 14 Mar 2000 15:12:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23887 Tue, 14 Mar 2000 16:45:15 -0500 (EST) Message-ID: <38CEB4C9.2F60565B@redcreek.com> Date: Tue, 14 Mar 2000 13:53:13 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: akrywani@newbridge.com CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available References: <000a01bf8de8$4d951c10$1e0101c8@ANDREWK2.TIMESTEP> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk wrote: > Using Isakmp Heartbeats for Dead Peer Detection > > > Abstract > > This document describes a method for sending heartbeat packets > (sometimes called keep-alives) across an ISAKMP SA in order to detect > when a peer has crashed or has become otherwise unreachable. A method > for negotiating the heartbeat parameters is also provided. > --- > > Andrew Howdy, So the list back in November/December spent alot of energy debating between doing heart-beats in ISAKMP, or in-band in each IPsec SA, or out-of-band in a seperate and dedicated IPsec SA. While I readily agree that a simple tallying of the posts shows a majority arguing in favor of doing heartbeats in ISAKMP, could you please spend a little time anyway going over your justifications for this approach above the others. The biggest challenge I see is that doing heart beats in ISAKMP should not be considered reliable since an implementation is not required to keep its ISAKMP SAs around for the lifetime of its IPsec SAs. And an unreliable heartbeat protocol seems like a poor idea. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Tue Mar 14 18:05:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA25284; Tue, 14 Mar 2000 18:05:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24394 Tue, 14 Mar 2000 19:46:08 -0500 (EST) Message-ID: <20000315005145.11710.qmail@web4006.mail.yahoo.com> Date: Tue, 14 Mar 2000 16:51:45 -0800 (PST) From: HyungTech H Subject: Do we need L2TP additionally in following IPSec-ed case? To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1804289383-953081505=:11635" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --0-1804289383-953081505=:11635 Content-Type: text/plain; charset=us-ascii Hello, I wonder whether IPsec combined with L2TP has more advantage over IPSec alone: Dial-up User <===(1)======>RAS based on Radius(provided by ISP) Dial-up User <====(2)=====>IPSec GateWay to companyA's Premise (1): Dial-up User establishes InternetConnection using ISP (2): Using IPSec remote Client(on Windows), the user exhanges data(TCP/IP, NetBios) with some host within companyA's Premise protected by IPSec GateWay. In above case, do we need to use L2TP additionally for intensifying security? If so , can you tell me details? --------------------------------- Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. --0-1804289383-953081505=:11635 Content-Type: text/html; charset=us-ascii

Hello,

I wonder whether IPsec combined with L2TP has more
advantage over IPSec alone:


Dial-up User <===(1)======>RAS based on Radius(provided by ISP)
Dial-up User  <====(2)=====>IPSec GateWay to companyA's Premise

(1): Dial-up User establishes InternetConnection using ISP

(2): Using IPSec remote Client(on Windows), the user exhanges data(TCP/IP, NetBios) with some host within companyA's Premise protected by IPSec GateWay.

In above case, do we need to use L2TP  additionally for intensifying security?

If so  , can you tell me details?

 


Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger. --0-1804289383-953081505=:11635-- From owner-ipsec@lists.tislabs.com Tue Mar 14 18:13:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA26451; Tue, 14 Mar 2000 18:13:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24436 Tue, 14 Mar 2000 20:05:24 -0500 (EST) Message-ID: <38CEE3B1.7CA6A353@redcreek.com> Date: Tue, 14 Mar 2000 17:13:21 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Joe Touch CC: ipsec@lists.tislabs.com, larse@ISI.EDU Subject: Re: Summary of transport mode use in overlay nets References: <200002172232.OAA27551@rum.isi.edu> <38AD7B5E.2783D9DE@mam.gov.tr> <38CDB40A.83EBE1DB@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe Touch wrote: > > Use of IPSEC Transport Mode for Virtual Networks > > Abstract > > This document addresses the use of IPSEC to secure the virtual links > of an overlay network. It addresses how IPSEC tunnel mode can > conflict with dynamic routing in an overlay, due to the dependence of > both the security association (SA) and the IP tunnel encapsulation > header on the header of the incoming packet. An alternative is > proposed, where IP tunnel encapsulation occurs as a separate initial > step, followed by IPSEC transport mode on the result. The tunnel > header is determined by the source header, and the SA is determined > by the tunnel header. The result is consistent with dynamic routing > in the overlay. This document discusses this alternative, and its > impact on IPSEC. > > -- Howdy, I'm not sure I understand your suggested flow of processing. So let me try and phrase it in my words and you tell me what bits I've got wrong. ( This is not sarcasim, but is honest confusion resolution ) Inbound Processing: When you recieve a packet on an inbound interface, you do a policy DB search for matching selectors. When you find a tunnel mode selector, you apply the outter IP headers to the packet but do NOT yet apply any security services to the packet. Instead, you do another policy DB search for selectors which match this new outer header. Then finding a transport mode selector, you apply those security services to the packet. (implementors may search for efficiencies as long as they achieve the above result) Outbound Processing: A packet arrives out of a transport mode SA. You de-security service the thing and do a policy lookup to find that, yes this matches your transport policy. Now you have to have some type of indicator (which I dont get yet) to let you know that you still have to decapsulate this packet. After decapsulation, you do another policy lookup to see that the inner packet matches a policy of yours, but you seem to have no SPI to match it against now. Any clarifications would be appreciated. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Wed Mar 15 07:43:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06350; Wed, 15 Mar 2000 07:43:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26611 Wed, 15 Mar 2000 09:13:23 -0500 (EST) Message-ID: <01d901bf8e25$67331b80$a2cb8489@engtanlk.nus.edu.sg> To: From: "ICON'2000 Secretariat" Subject: LAST day to call for papers. Have you submitted your paper? Date: Wed, 15 Mar 2000 10:15:25 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D6_01BF8E68.75565B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01D6_01BF8E68.75565B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All A Gentle Reminder * Kindly ignore this email if you have received this before. Thank you for your kind attention. The 8th IEEE International Conference On Networks will be held from September 5- 8, 2000 in Singapore. The aim of the conference is to = provide an international forum for experts to promote, share and discuss various issues and developments in the broad field of computer and communication networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for special sessions/panel discussions. More information on the scope of the conference and the guidelines for the submission of contributions can be obtained at this web site :http://www.comp.nus.edu.sg/~icon/ We look forward to your participation. Thank you. Icon 2000 organizing Committee ------=_NextPart_000_01D6_01BF8E68.75565B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All
 
A Gentle Reminder

* Kindly ignore this email if you have = received=20 this before.
Thank you for your kind attention.

The 8th IEEE International Conference On Networks will be held=20 from

September 5- 8, 2000 in Singapore. The aim of the conference = is to=20 provide

an international forum for experts to promote, share and = discuss=20 various

issues and developments in the broad field of computer = and=20 communication

networks. We thus seek and solicit your=20 contributions

in the form of original/unpublished papers, = tutorials, and=20 topics for

special sessions/panel discussions. More information = on the=20 scope of the

conference and the guidelines for the submission of=20 contributions can

be obtained at this web site :http://www.comp.nus.edu.sg/~ic= on/



We=20 look forward to your participation. Thank you.

Icon 2000 = organizing=20 Committee
------=_NextPart_000_01D6_01BF8E68.75565B80-- From owner-ipsec@lists.tislabs.com Wed Mar 15 07:48:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06453; Wed, 15 Mar 2000 07:48:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26626 Wed, 15 Mar 2000 09:14:25 -0500 (EST) Date: 14 Mar 2000 22:32:29 -0000 Message-ID: <20000314223229.26334.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipsec@lists.tislabs.com Subject: Re: MAC speeds References: <71984F8FB76AD211AC3E00A0C9C578C702157335@hasmsx32.iil.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A comparison to HMAC appears in http://cr.yp.to/hash127/faq.html Computing a MAC on 64 bytes of data takes 557 Pentium cycles plus the time for your favorite encryption function on a 16-byte block. The paper, which I recently submitted to J. Cryptology, is at http://cr.yp.to/papers.html#hash127 Asking how much scrutiny a Wegman-Carter-type authentication system has received is like asking how much scrutiny counter mode has received: you're missing the point. The security is _provably_ as good as the encryption function you plug in. ---Dan From owner-ipsec@lists.tislabs.com Wed Mar 15 08:45:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08075; Wed, 15 Mar 2000 08:45:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26901 Wed, 15 Mar 2000 10:22:11 -0500 (EST) Date: Wed, 15 Mar 2000 10:27:47 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: MAC speeds In-Reply-To: <20000314223229.26334.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 14 Mar 2000, D. J. Bernstein wrote: > Asking how much scrutiny a Wegman-Carter-type authentication system has > received is like asking how much scrutiny counter mode has received: > you're missing the point. The security is _provably_ as good as the > encryption function you plug in. That just shifts the problem one step: how much scrutiny has that proof had? (As the infamous Demillo/Lipton/Perlis paper pointed out, proofs are just as subject to errors and oversights as programs are.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Mar 15 08:47:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08155; Wed, 15 Mar 2000 08:47:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26957 Wed, 15 Mar 2000 10:29:03 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Henry Spencer Cc: IP Security List Subject: Re: MAC speeds Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Mar 2000 10:34:55 -0500 Message-Id: <20000315153505.DA43741F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Henry Spe ncer writes: > On 14 Mar 2000, D. J. Bernstein wrote: > > Asking how much scrutiny a Wegman-Carter-type authentication system has > > received is like asking how much scrutiny counter mode has received: > > you're missing the point. The security is _provably_ as good as the > > encryption function you plug in. > > That just shifts the problem one step: how much scrutiny has that proof had? > (As the infamous Demillo/Lipton/Perlis paper pointed out, proofs are just as > subject to errors and oversights as programs are.) Right. Also bear in mind that proofs often make assumptions about ideal encryption functions, ideal hash functions, etc. But ideal cryptographic functions aren't subject to things like linear and differential cryptanalysis. --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Mar 15 17:45:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22920; Wed, 15 Mar 2000 17:45:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28628 Wed, 15 Mar 2000 18:45:43 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Ricky Charlet'" Cc: Subject: RE: Heartbeats draft available Date: Wed, 15 Mar 2000 18:58:17 -0500 Message-Id: <000601bf8eda$560a17e0$1e0101c8@ANDREWK2.TIMESTEP> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-reply-to: <38CEB4C9.2F60565B@redcreek.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > While I > readily agree > that a simple tallying of the posts shows a majority arguing > in favor of > doing heartbeats in ISAKMP, could you please spend a little > time anyway > going over your justifications for this approach above the others. Hi Ricky, Let me first state that the draft specifies two things: a) A framework for negotiating and implementing heartbeats. b) A default mode of operation that has been chosen for interoperability. If you want to define some other mode of operation for use with your own products (e.g. phase 2 heartbeats), the framework lets you do this. Just define a new heartbeat type from the private range, exchange vendor ids, and you're set. Consenting parties can replace any of the 3 layers we describe in the draft. But as for part b, let's face it... When you're defining a standard interoperability mode, vendor support DOES matter, and the majority of support was for a phase 1 approach. Even when I talked to some of the vendors who do "dangle" phase 1 SAs, many of them were still in favour of using phase 1 heartbeats. Most vendors who dangle SAs say they do so only when they are low on memory, so they will still be able to use heartbeats most of the time. We also wanted the default mode to be easy to understand and easy to implement. With the heartbeat protocol, you can implement the bare minimum set of requirements and still be guaranteed of interoperability with the peer. Phase 2 heartbeats do have a number of advantages over phase 1 heartbeats, but there are also a lot of added complications, which would make it difficult to define a simple phase 2 heartbeat mode that is suitable for interoperability. Some of the complications: using hijacked SAs (mixing customer traffic with management traffic -- our customers don't like this), interactions with the accounting service (requires two traffic counters), need for a policy hole to allow the heartbeat traffic, negotiation of which exact SA parameters to use, flexibility of packet format, potential of defeating the peer's inactivity timeout mechanism. Allowing all of the common scenarios that various vendors want to support would require a much more elaborate negotiation scheme. And it doesn't seem fair to legislate all or most of the above behaviours. Which is why you are free to define your own protocol for private use, at which point you can make whatever assumptions you want about the peer's configuration. It's impossible to please everybody. But all things considered, I would rather have a heartbeat protocol that has to be turned off under low memory conditions than a protocol that causes interoperability nightmares because it is too difficult to negotiate. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Thu Mar 16 07:41:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11190; Thu, 16 Mar 2000 07:41:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA01476 Thu, 16 Mar 2000 08:41:34 -0500 (EST) Date: 16 Mar 2000 02:02:23 -0000 Message-ID: <20000316020223.11140.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipsec@lists.tislabs.com Subject: Re: MAC speeds References: <20000315153505.DA43741F16@SIGABA.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steven M. Bellovin writes: > Also bear in mind that proofs often make assumptions about ideal > encryption functions, ideal hash functions, etc. You seem to be confusing two different parts of the literature. There are many papers proving the security of various secret-key constructions against various attacks, under the assumption that the participants share a long uniform random secret string. Trivial example: the Mauborgne cipher, also known as the one-time pad. We think that long secrets can be safely generated from short secrets. The same systems appear to be secure when the long string is replaced by Rijndael_k(0) Rijndael_k(1) Rijndael_k(2) ... for a uniform random 128-bit key k. If there's no fast algorithm with a noticeable chance of distinguishing the Rijndael output from a uniform random string of the same length---i.e., if Rijndael is unpredictable---then there's no fast algorithm to break these secret-key constructions; and conversely. Of course, we don't know how to prove that Rijndael is unpredictable. But we think it is, and if we find that we're wrong then we'll start using a different function. The unpredictability assumption is not some artificial restriction in the proofs; it describes exactly what we need to guarantee security. In contrast, the ``ideal hash function'' papers put restrictions on the attacker. The Rabin-Williams signature system, for example, is provably secure _against generic attacks_ if factoring is difficult; here a ``generic attack'' uses a hash function as an oracle, and ``secure'' means that the average probability of success over all functions is small. This is comforting, but it doesn't imply that the system is secure against real attacks; maybe the hash function we use interacts badly with the rest of the system. ---Dan From owner-ipsec@lists.tislabs.com Thu Mar 16 07:43:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11281; Thu, 16 Mar 2000 07:43:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA01475 Thu, 16 Mar 2000 08:41:34 -0500 (EST) Date: 16 Mar 2000 01:02:03 -0000 Message-ID: <20000316010203.4348.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipsec@lists.tislabs.com Subject: Re: MAC speeds References: <20000314223229.26334.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > how much scrutiny has that proof had? Authentication systems of this type have been known for 25 years and are the subject of dozens of articles. The security proofs are easy and work with any ``universal'' hash function. The fact that the particular hash function I'm using is ``universal'' is taught in undergraduate algebra courses and appears in hundreds of books. What's new is the fact that this function can be computed at extremely high speed. You can worry about errors in the proof that the code computes the right function, just as you can worry about bugs in any other bignum code, but this is completely different from worrying about unknown attacks on, for example, SHA. ---Dan From owner-ipsec@lists.tislabs.com Thu Mar 16 08:06:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12010; Thu, 16 Mar 2000 08:06:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01687 Thu, 16 Mar 2000 09:23:13 -0500 (EST) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE9448@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: ipsec@lists.tislabs.com Subject: AES draft query Date: Thu, 16 Mar 2000 06:29:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Page 9 of the draft recommends 3240-bit Diffie-Hellmans for 128-bit AES, 7945-bit Diffie-Hellmans for 192-bit AES, and 15430-bit Diffie-Hellmans for 256-bit AES. It is worth discussing whether these requirements address a real perceived threat or are at best theoretical in nature. While the defers the discussion on how they were derived to a reference, it is easy enough to guess how they were obtained: select the Diffie-Hellman modulus size at the point where computing the discrete logarithm becomes just as expensive as attacking the symmetric key directly. However, unlike symmetric algorithms, public key operations like Diffie-Hellmans have a real cost, so this may not be the best way to set the requirement, even if it is theoretically the "right" way to do the job. Even if you believe Moore's law will remain true for the forseeable future, 8K and 15K still represent about 9 and 11 more generations of processors, respectively, before you get performance most users will tolerate. The most credible study I've seen estimating key strengths is Lenstra and Verheul's "Selecting Cryptographic Key Sizes", November 15, 1999. They estimate that 4K modular exponentiations will still be secure from any reasonable attacks for the next 50 years. So why should there be a requirement for anything above about 4K Diffie-Hellmans at this time? On the point of Diffie-Hellman modulus sizes, the draft's requirements seem to be way out of line both in regard to the state of technology and in regard to the nature of the perceived possible threats in the time frames when the draft will be applicable. What am I missing? -- Jesse Walker From owner-ipsec@lists.tislabs.com Thu Mar 16 11:08:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16383; Thu, 16 Mar 2000 11:08:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02445 Thu, 16 Mar 2000 11:45:25 -0500 (EST) Message-ID: From: "Gallagher, Mick" To: "'HyungTech H'" Cc: ipsec@lists.tislabs.com Subject: RE: Do we need L2TP additionally in following IPSec-ed case? Date: Thu, 16 Mar 2000 16:51:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8F67.D13683BC" 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_01BF8F67.D13683BC Content-Type: text/plain; charset="iso-8859-1" As I understand, the advantage of using IPSec secured L2TP sessions, as opposed to IPSec alone, is the fact that PPP can be used to configure the dial-up-user's IP connection. In this way, the dial-up-user can appear to be on a subnet assigned by the corporate server. In the 'pure IPSec' scenario, the IP address of the user must appear to the corporate network as the address assigned by the ISP. A newcomer to IPSec, I'm not aware of any IPSec interface configuration facility. Hope this helps, Mick -----Original Message----- From: HyungTech H [mailto:hhkte@yahoo.com] Sent: 15 March 2000 00:52 To: ipsec@lists.tislabs.com Subject: Do we need L2TP additionally in following IPSec-ed case? Hello, I wonder whether IPsec combined with L2TP has more advantage over IPSec alone: Dial-up User <===(1)======>RAS based on Radius(provided by ISP) Dial-up User <====(2)=====>IPSec GateWay to companyA's Premise (1): Dial-up User establishes InternetConnection using ISP (2): Using IPSec remote Client(on Windows), the user exhanges data(TCP/IP, NetBios) with some host within companyA's Premise protected by IPSec GateWay. In above case, do we need to use L2TP additionally for intensifying security? If so , can you tell me details? _____ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger . ------_=_NextPart_001_01BF8F67.D13683BC Content-Type: text/html; charset="iso-8859-1"
As I understand, the advantage of using IPSec secured L2TP sessions, as opposed to IPSec alone, is the fact that PPP can be used to configure the dial-up-user's IP connection.
 
In this way, the dial-up-user can appear to be on a subnet assigned by the corporate server.
 
In the 'pure IPSec' scenario, the IP address of the user must appear to the corporate network as the address assigned by the ISP.
 
A newcomer to IPSec, I'm not aware of any IPSec interface configuration facility.
 
Hope this helps,
Mick
-----Original Message-----
From: HyungTech H [mailto:hhkte@yahoo.com]
Sent: 15 March 2000 00:52
To: ipsec@lists.tislabs.com
Subject: Do we need L2TP additionally in following IPSec-ed case?

Hello,

I wonder whether IPsec combined with L2TP has more
advantage over IPSec alone:


Dial-up User <===(1)======>RAS based on Radius(provided by ISP)
Dial-up User  <====(2)=====>IPSec GateWay to companyA's Premise

(1): Dial-up User establishes InternetConnection using ISP

(2): Using IPSec remote Client(on Windows), the user exhanges data(TCP/IP, NetBios) with some host within companyA's Premise protected by IPSec GateWay.

In above case, do we need to use L2TP  additionally for intensifying security?

If so  , can you tell me details?

 


Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
------_=_NextPart_001_01BF8F67.D13683BC-- From owner-ipsec@lists.tislabs.com Thu Mar 16 12:35:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA18461; Thu, 16 Mar 2000 12:35:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02883 Thu, 16 Mar 2000 13:14:21 -0500 (EST) Message-ID: <38D12625.29B53766@redcreek.com> Date: Thu, 16 Mar 2000 10:21:25 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gallagher, Mick" CC: "'HyungTech H'" , ipsec@lists.tislabs.com Subject: Re: Do we need L2TP additionally in following IPSec-ed case? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Gallagher, Mick" wrote: > > As I understand, the advantage of using IPSec secured L2TP sessions, > as opposed to IPSec alone, is the fact that PPP can be used to > configure the dial-up-user's IP connection. > > In this way, the dial-up-user can appear to be on a subnet assigned by > the corporate server. > This is somewhat correct. > In the 'pure IPSec' scenario, the IP address of the user must appear > to the corporate network as the address assigned by the ISP. This is incorrect. See below. > > A newcomer to IPSec, I'm not aware of any IPSec interface > configuration facility. > I would suggest subscribing to the ipsra working group list, where we will be evaluating at least two other configuration facilities which provide some or all of this same functionality. That list is at ietf-ipsra@vpnc.org. To subscribe to the mailing list, send a message to ietf-ipsra-request@vpnc.org with the single word subscribe in the body of the message. Scott From owner-ipsec@lists.tislabs.com Thu Mar 16 12:41:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA18642; Thu, 16 Mar 2000 12:41:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02810 Thu, 16 Mar 2000 13:02:40 -0500 (EST) Message-ID: From: "Linn, John" To: "'Walker, Jesse'" , ipsec@lists.tislabs.com Subject: RE: AES draft query Date: Thu, 16 Mar 2000 13:17:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jesse, Good points. While the incremental cost of additional symmetric key bits beyond the anticipated state of the art is "almost free", this is very much not true for increasing the number of asymmetric key bits used to transport those symmetric keys. An RSA Laboratories paper with further analysis on key size issues is now being finalized for web publication, probably within the next couple of weeks; I'll post a citation when it's available. --jl > -----Original Message----- > From: Walker, Jesse [mailto:jesse.walker@intel.com] > Sent: Thursday, March 16, 2000 9:29 AM > To: ipsec@lists.tislabs.com > Subject: AES draft query > > > Page 9 of the draft recommends 3240-bit Diffie-Hellmans for > 128-bit AES, > 7945-bit Diffie-Hellmans for 192-bit AES, and 15430-bit > Diffie-Hellmans for > 256-bit AES. It is worth discussing whether these > requirements address a > real perceived threat or are at best theoretical in nature. > While the defers > the discussion on how they were derived to a reference, it is > easy enough to > guess how they were obtained: select the Diffie-Hellman > modulus size at the > point where computing the discrete logarithm becomes just as > expensive as > attacking the symmetric key directly. However, unlike > symmetric algorithms, > public key operations like Diffie-Hellmans have a real cost, > so this may not > be the best way to set the requirement, even if it is > theoretically the > "right" way to do the job. Even if you believe Moore's law > will remain true > for the forseeable future, 8K and 15K still represent about 9 > and 11 more > generations of processors, respectively, before you get > performance most > users will tolerate. The most credible study I've seen estimating key > strengths is Lenstra and Verheul's "Selecting Cryptographic > Key Sizes", > November 15, 1999. They estimate that 4K modular > exponentiations will still > be secure from any reasonable attacks for the next 50 years. > So why should > there be a requirement for anything above about 4K > Diffie-Hellmans at this > time? On the point of Diffie-Hellman modulus sizes, the draft's > requirements seem to be way out of line both in regard to the state of > technology and in regard to the nature of the perceived > possible threats in > the time frames when the draft will be applicable. What am I missing? > > -- Jesse Walker > > From owner-ipsec@lists.tislabs.com Thu Mar 16 14:44:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA21996; Thu, 16 Mar 2000 14:44:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03489 Thu, 16 Mar 2000 15:26:20 -0500 (EST) Message-Id: <3.0.1.32.20000316153203.00a82cb0@adga.ca> X-Sender: frousseau@adga.ca X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 16 Mar 2000 15:32:03 -0500 To: ipsec@lists.tislabs.com From: Francois Rousseau Subject: Re: AES draft query Cc: jesse.walker@intel.com In-Reply-To: <392A357CE6FFD111AC3E00A0C99848B002FE9448@hdsmsx31.hd.intel .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This same draft also recommends 248-bit Elliptic Curve Diffie-Hellmans (ECDH) for 128-bit AES, 376-bit ECDH for 192-bit AES, and 504-bit ECDH for 256-bit AES. However, note that Appendix 6 to FIPS 188-2 recommends ECDH modulus sizes that are a slightly larger than the those recommended in this draft. Appendix 6 to FIPS 188-2 recommends 283-bit Elliptic Curve Diffie-Hellmans (ECDH) for 128-bit AES, 409-bit ECDH for 192-bit AES, and 571-bit ECDH for 256-bit AES over a "Binary Field" and 256-bit Elliptic Curve Diffie-Hellmans (ECDH) for 128-bit AES, 384-bit ECDH for 192-bit AES, and 521-bit ECDH for 256-bit AES over a "Prime Field". Francois Rousseau At 06:29 AM 16/03/00 -0800, Walker, Jesse wrote: >Page 9 of the draft recommends 3240-bit Diffie-Hellmans for 128-bit AES, >7945-bit Diffie-Hellmans for 192-bit AES, and 15430-bit Diffie-Hellmans for >256-bit AES. It is worth discussing whether these requirements address a >real perceived threat or are at best theoretical in nature. While the defers >the discussion on how they were derived to a reference, it is easy enough to >guess how they were obtained: select the Diffie-Hellman modulus size at the >point where computing the discrete logarithm becomes just as expensive as >attacking the symmetric key directly. However, unlike symmetric algorithms, >public key operations like Diffie-Hellmans have a real cost, so this may not >be the best way to set the requirement, even if it is theoretically the >"right" way to do the job. Even if you believe Moore's law will remain true >for the forseeable future, 8K and 15K still represent about 9 and 11 more >generations of processors, respectively, before you get performance most >users will tolerate. The most credible study I've seen estimating key >strengths is Lenstra and Verheul's "Selecting Cryptographic Key Sizes", >November 15, 1999. They estimate that 4K modular exponentiations will still >be secure from any reasonable attacks for the next 50 years. So why should >there be a requirement for anything above about 4K Diffie-Hellmans at this >time? On the point of Diffie-Hellman modulus sizes, the draft's >requirements seem to be way out of line both in regard to the state of >technology and in regard to the nature of the perceived possible threats in >the time frames when the draft will be applicable. What am I missing? > >-- Jesse Walker From owner-ipsec@lists.tislabs.com Thu Mar 16 14:55:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA22475; Thu, 16 Mar 2000 14:55:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03605 Thu, 16 Mar 2000 16:05:04 -0500 (EST) Message-Id: <200003162110.QAA19908@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-heartbeats-00.txt Date: Thu, 16 Mar 2000 16:10:53 -0500 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 Isakmp Heartbeats for Dead Peer Detection Author(s) : A. Krywaniuk, T. Kivinen Filename : draft-ietf-ipsec-heartbeats-00.txt Pages : 30 Date : 15-Mar-00 This document describes a method for sending heartbeat packets (sometimes called keep-alives) across an ISAKMP SA in order to detect when a peer has crashed or has become otherwise unreachable. A method for negotiating the heartbeat parameters is also provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-heartbeats-00.txt 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-heartbeats-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-heartbeats-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <20000315132223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-heartbeats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-heartbeats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000315132223.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Mar 16 16:45:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25027; Thu, 16 Mar 2000 16:45:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04013 Thu, 16 Mar 2000 18:01:34 -0500 (EST) From: "Jeff Kleiman" To: Subject: RE: Do we need L2TP additionally in following IPSec-ed case? Date: Thu, 16 Mar 2000 18:07:45 -0500 Message-ID: <005801bf8f9c$70b42eb0$f9fea8c0@balrog.tril-inc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01BF8F72.87DE26B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0059_01BF8F72.87DE26B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit It is possible to make the user appear to be on a subnet assigned by the corporate server with the addition of some client functionality beyond the core IPSec specification. My company's IPSec client allows the user to configure one or more virtual adapters with IP addresses and then bind these virtual adapters to physical or dial-up adapters. The net effect of this is that it is possible to support tunnel mode IPSec in which the inner IP address looks to the corporate gateway like an IP address within the corporate subnet. This allows easy routing of return packets as well as potentially access to resources on the corporate network that restrict access to IP addresses outside the subnet. This of course does not solve the problem of how you get the IP address across - a topic that is currently being discussed in the IPSRA working group. Jeff Kleiman ---- Trilogy, Inc. [http://www.tril-inc.com] Provider of core IPSec technology and consulting services -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Gallagher, Mick Sent: Thursday, March 16, 2000 11:51 AM To: 'HyungTech H' Cc: ipsec@lists.tislabs.com Subject: RE: Do we need L2TP additionally in following IPSec-ed case? As I understand, the advantage of using IPSec secured L2TP sessions, as opposed to IPSec alone, is the fact that PPP can be used to configure the dial-up-user's IP connection. In this way, the dial-up-user can appear to be on a subnet assigned by the corporate server. In the 'pure IPSec' scenario, the IP address of the user must appear to the corporate network as the address assigned by the ISP. A newcomer to IPSec, I'm not aware of any IPSec interface configuration facility. Hope this helps, Mick -----Original Message----- From: HyungTech H [mailto:hhkte@yahoo.com] Sent: 15 March 2000 00:52 To: ipsec@lists.tislabs.com Subject: Do we need L2TP additionally in following IPSec-ed case? Hello, I wonder whether IPsec combined with L2TP has more advantage over IPSec alone: Dial-up User <===(1)======>RAS based on Radius(provided by ISP) Dial-up User <====(2)=====>IPSec GateWay to companyA's Premise (1): Dial-up User establishes InternetConnection using ISP (2): Using IPSec remote Client(on Windows), the user exhanges data(TCP/IP, NetBios) with some host within companyA's Premise protected by IPSec GateWay. In above case, do we need to use L2TP additionally for intensifying security? If so , can you tell me details? ---------------------------------------------------------------------------- Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. ------=_NextPart_000_0059_01BF8F72.87DE26B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It is possible to make the user appear to be on a subnet assigned by = the=20 corporate server with the addition of some client functionality beyond = the core=20 IPSec specification. My company's IPSec client allows the user to = configure one=20 or more virtual adapters with IP addresses and then bind these virtual = adapters=20 to physical or dial-up adapters. The net effect of this is that it is = possible=20 to support tunnel mode IPSec in which the inner IP address looks to the=20 corporate gateway like an IP address within the corporate subnet. This = allows=20 easy routing of return packets as well as potentially access to = resources on the=20 corporate network that restrict access to IP addresses outside the = subnet.

This of course does not solve the problem of how you get the IP = address=20 across - a topic that is currently being discussed in the IPSRA working=20 group.

Jeff Kleiman

----

Trilogy, Inc. [http://www.tril-inc.com]
Provider of core IPSec = technology=20 and consulting services

-----Original Message-----
From: = owner-ipsec@lists.tislabs.com=20 [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Gallagher,=20 Mick
Sent: Thursday, March 16, 2000 11:51 AM
To: = 'HyungTech=20 H'
Cc: ipsec@lists.tislabs.com
Subject: RE: Do we = need L2TP=20 additionally in following IPSec-ed case?

As I=20 understand, the advantage of using IPSec secured L2TP sessions, as = opposed to=20 IPSec alone, is the fact that PPP can be used to configure the=20 dial-up-user's IP connection.
 
In=20 this way, the dial-up-user can appear to be on a subnet assigned by = the=20 corporate server.
 
In the=20 'pure IPSec' scenario, the IP address of the user must appear to the = corporate=20 network as the address assigned by the ISP.
 
A=20 newcomer to IPSec, I'm not aware of any IPSec interface configuration=20 facility.
 
Hope=20 this helps,
Mick
-----Original Message-----
From: HyungTech H=20 [mailto:hhkte@yahoo.com]
Sent: 15 March 2000 = 00:52
To:=20 ipsec@lists.tislabs.com
Subject: Do we need L2TP = additionally in=20 following IPSec-ed case?

Hello,

I wonder whether IPsec combined with L2TP has more =
advantage over IPSec alone:


Dial-up User <=3D=3D=3D(1)=3D=3D=3D=3D=3D=3D>RAS based = on Radius(provided by ISP)=20
Dial-up User  <=3D=3D=3D=3D(2)=3D=3D=3D=3D=3D>IPSec = GateWay to companyA's=20 Premise

(1): Dial-up User establishes InternetConnection using ISP

(2): Using IPSec remote Client(on Windows), the user = exhanges=20 data(TCP/IP, NetBios) with some host within companyA's Premise = protected by=20 IPSec GateWay.

In above case, do we need to use = L2TP  additionally=20 for intensifying security?

If so  , can you tell me details?

 


Do You Yahoo!?
Talk to your friends online with Yahoo! = Messenger.
------=_NextPart_000_0059_01BF8F72.87DE26B0-- From owner-ipsec@lists.tislabs.com Thu Mar 16 17:00:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA25424; Thu, 16 Mar 2000 17:00:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04070 Thu, 16 Mar 2000 18:34:12 -0500 (EST) Message-ID: <38D170D2.DAC1AAAE@isi.edu> Date: Thu, 16 Mar 2000 15:40:02 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ricky Charlet CC: ipsec@lists.tislabs.com, larse@ISI.EDU, touch@ISI.EDU Subject: Re: Summary of transport mode use in overlay nets References: <200002172232.OAA27551@rum.isi.edu> <38AD7B5E.2783D9DE@mam.gov.tr> <38CDB40A.83EBE1DB@isi.edu> <38CEE3B1.7CA6A353@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk FWIW - the ID is now on-line at the usual places. Ricky Charlet wrote: > > Joe Touch wrote: > > > > Use of IPSEC Transport Mode for Virtual Networks ... > > -- > > Howdy, > I'm not sure I understand your suggested flow of processing. So let me > try and phrase it in my words and you tell me what bits I've got wrong. > ( This is not sarcasim, but is honest confusion resolution ) The terminology below is a little swapped from what I'm familiar with; in our ID (and in the IPsec arch doc), inbound = into the host/gateway, outbound = leaving. > Inbound Processing: > When you recieve a packet on an inbound interface, you do a policy DB > search for matching selectors. When you find a tunnel mode selector, you > apply the outter IP headers to the packet but do NOT yet apply any > security services to the packet. Instead, you do another policy DB > search for selectors which match this new outer header. Then finding a > transport mode selector, you apply those security services to the > packet. (implementors may search for efficiencies as long as they > achieve the above result) Outbound - when we send a packet on an outbound ... 1. we don't use IPsec for IPIP encapsulation. We use 'conventional' tunnels, e.g., gif on FreeBSD + KAME 2. as a result of (1), we don't do any policy DB search on the outgoing packet itself; first, we IPIP encapsulate, THEN the packet goes back through IP packet processing. This time, it matches the policy DB, and IPSEC occurs. That's the main point - we do IPIP encapsulation based on routing rules, and AFTER THAT do IPSEC on the resulting encapsulated packet. > Outbound Processing: > A packet arrives out of a transport mode SA. You de-security service > the thing and do a policy lookup to find that, yes this matches your > transport policy. Now you have to have some type of indicator (which I > dont get yet) to let you know that you still have to decapsulate this > packet. After decapsulation, you do another policy lookup to see that > the inner packet matches a policy of yours, but you seem to have no SPI > to match it against now. Inbound - a packet arrives. here there are two options: A. the receiver can use a tunnel-mode SA in which case, all the security of tunnel-mode SA receiver processing is available, including checks of the header of the inner packet. This has been tested in FreeBSD 3.4 with KAME IPSEC. We're not sure if other stacks behave identically, but we can find nothing in the tunnel-mode spec that indicates they should do otherwise. B. the receiver can use a transport-mode SA, followed by IPIP decapsulation as a separate step far as we can determine, the IPSEC Arch document indicates that packets, once de-transport-IPSEC'd, are supposed to carry a tag indicated "yes, this packet has already been through this site's IPSEC, and here is the SA that worked". The IPIP decapsulation can potentially check this during decapsulation. I.e., the idea behind retaining the SA with the packet is so subsequent processing can check the SA and do additional processing if needed. While we're not sure how/if/whether this is implemented, or how to activate it if so, it seems moot since we can already use (A). We hope this helps clarify things... Joe (and Lars) From owner-ipsec@lists.tislabs.com Fri Mar 17 02:46:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA28824; Fri, 17 Mar 2000 02:46:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA05632 Fri, 17 Mar 2000 03:49:21 -0500 (EST) Message-Id: <200003170853.AAA15902@omega.cisco.com> X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 17 Mar 2000 01:06:27 -0800 To: gre@ops.ietf.org From: Gopal Dommety Subject: GRE Extensions (Modified) Cc: udlr@sophia.inria.fr, msdp@antc.uoregon.edu, ipsec@lists.tislabs.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, l2tp@ipsec.org, tsgp@3gpp2.org, tsga@3gpp2.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello: I have changed the sequence no to be 4 bytes. The changes request by most have been made. A remining issue is regarding the behaviour when both sequence no and the Key are present. There are two options: 1. Have sequence no per Key. This will give better granularity with added complexity of implementation. 2. Sequence no for the tunnel irrespective of the Key. Let me know your opinion. Thanks Gopal Network Working Group Gopal Dommety INTERNET DRAFT cisco Systems Category: Standards Track March 2000 Title: draft-dommety-gre-ext-01.txt Expires October 2000 Key and Sequence Number Extensions to GRE draft-dommety-gre-ext-01.txt Status of this Memo This document is a submission by the Network Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the gre@ops.ietf.org mailing list. Distribution of this memo is unlimited. This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE (Generic Routing Encapsulation) Header [1]. GRE specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. Dommety [Page 1] Internet Draft Key and Sequence Number Extensions to GRE February 2000 1. Introduction Current specification of Generic Routing Encapsulation [1] specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This document describes enhancements by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1]. The Key field is used to create separate sub-tunnels within a GRE Tunnel. Sequence Number field is used to maintain sequence of packets within a GRE Tunnel. 1.1. Specification Language The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. In addition, the following words are used to signify the requirements of the specification. Silently discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter. 2. Extensions to GRE Header The GRE packet header[1] has the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The proposed GRE header will have the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key Present (bit 2) If the Key Present bit is set to 1, then it indicates that the Key field is present in the GRE header. Otherwise, the Key field is not present in the GRE header. Sequence Number Present (bit 3) If the Sequence Number Present bit is set to 1, then it indicates that the Sequence Number field is present. Otherwise, the Sequence Number field is not present in the GRE header. The Key and Sequence Present bits are chosen to be compatible with RFC 1701 [2]. 2.1. Key Field (4 octets) The Key field contains a four octet number which was inserted by the encapsulator. The actual method by which this Key is obtained is beyond the scope of this document. Key field is intended to be used for creating separate sub-tunnels within a GRE Tunnel and the Key field identifies the sub-tunnel. 2.2. Sequence Number (4 octets) The Sequence Number field is a four byte feild and is inserted by the encapsulator when Sequence Number Present Bit is set. The Sequence Number MUST be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. The intended use of the Sequence Field is to provide unreliable and in-order delivery. If the Key present bit (bit 2) is set, the sequence number is specific to the sub-tunnel identified by the Key field. Note that packets without the sequence bit set can be sent in between packets with the sequence bit set. The sequence number value ranges from 1 to 2**32-1. The first datagram is sent with a sequence number of 1. The sequence number is thus a free running counter represented modulo 2**32, with the exception that 1 is used when modulo 2**32 results in 0 (i.e., rollover to 1 instead of 0). When the decapsulator receives an out-of sequence packet it SHOULD be silently discarded. Additionally, reordering of out-of sequence packets MAY be performed by the decapsulator for improved performance and tolerance to reordering in the network (since the state of the stateful compression or encryption is reset by packet loss, it might help the performance to tolerate some amount of packet reordering in the network by buffering). Exact buffering schemes are outside the scope of this document. Note that the sequence number is used to detect lost packets and/or restore the original sequence of packets that may have been reordered during transport. A packet is considered an out-of-sequence packet if the sequence number of the received packet is lesser than or equal to the sequence number of last successfully decapsulated packet. The sequence number of a received message is considered less than or equal to the last successfully received sequence number if its value lies in the range of the last received sequence number and the preceding 65534 values, inclusive. If the received packet is an in-sequence packet, it is successfully decapsulated. Note that the sequence number is used to detect lost packets and/or restore the original sequence of packets (with buffering) that may have been reordered during transport. Use of the sequence number option should be used appropriately; in particular, it is a good idea a avoid using when tunneling protocols that have higher layer in-order delivery mechanisms or are tolerant to out-of-order delivery. If only at certain instances the protocol being carried in the GRE tunnel requires in-sequence delivery, only the corresponding packets encapsulated in a GRE header can be sent with the sequence bit set. Mechanisims to determine which packets need to be sent in-sequence and the signaling mechanisims are outside the scope of this document. 3. IANA Considerations 4. Acknowledgments 5. References [1] Farinacci, D., Li, T., Hnaks, S., Meyer, D. and Traina, P., "Generic Routing Encapsulation (GRE)," draft-meyer-gre-update-03.txt, January 2000. [2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems, October 1994. [3] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Dommety [Page 4] Internet Draft Key and Sequence Number extensions to GRE February 2000 Author Information Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: gdommety@cisco.com Dommety Thank You. Regards, Gopal ------------------------------------------------------------------------------------------------------------- Gopal Dommety 408 525 1404 gdommety@cisco.com Cisco Systems, San Jose, CA, 95051 From owner-ipsec@lists.tislabs.com Fri Mar 17 09:56:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18717; Fri, 17 Mar 2000 09:56:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07301 Fri, 17 Mar 2000 11:11:34 -0500 (EST) Message-Id: <200003171611.IAA17317@jittlov.qualcomm.com> X-Sender: rhsu@fezik.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Fri, 17 Mar 2000 08:12:08 -0800 To: Gopal Dommety , tsgp@3gpp2.org From: Raymond Hsu Subject: Re: GRE Extensions (Modified) Cc: udlr@sophia.inria.fr, msdp@antc.uoregon.edu, ipsec@lists.tislabs.com, MOBILE-IP@standards.nortelnetworks.com, l2tp@ipsec.org, tsgp@3gpp2.org, tsga@3gpp2.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Gopal: In TR-45.6's R-P interface (aka A10 interface), we may use the first option in the direction from the PDSN to the PCF. In this direction, we've identified scenarios where some mobiles require in-sequence delivery and some don't. Since each mobile is identified by the Key field over the R-P interface, we need option 1. However, in the direction from the PCF to the PDSN, we don't have a strong requirement per mobile basis; thus, option 2 is adequate. Therefore, my recommendation is that both options should be allowed in the GRE draft. Regards, Raymond Hsu At 01:06 AM 3/17/00 -0800, Gopal Dommety wrote: >Hello: > >I have changed the sequence no to be 4 bytes. The changes request by >most have been made. > >A remining issue is regarding the behaviour when both sequence no and >the Key are present. There are two options: > >1. Have sequence no per Key. This will give better granularity with > added complexity of implementation. > >2. Sequence no for the tunnel irrespective of the Key. > >Let me know your opinion. > >Thanks >Gopal > > >Network Working Group Gopal Dommety >INTERNET DRAFT cisco Systems >Category: Standards Track March 2000 >Title: draft-dommety-gre-ext-01.txt > >Expires October 2000 > > Key and Sequence Number Extensions to GRE > draft-dommety-gre-ext-01.txt > >Status of this Memo > > This document is a submission by the Network Working Group of the > Internet Engineering Task Force (IETF). Comments should be submitted > to the gre@ops.ietf.org mailing list. > > Distribution of this memo is unlimited. > > This document is an Internet Draft and is in full conformance with > all provisions of Section 10 of RFC2026. Internet Drafts are working > documents of the Internet Engineering Task Force (IETF), its areas, > and working groups. Note that other groups may also distribute > working documents as Internet Drafts. > > Internet Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > >Abstract > > This document describes extensions by which two fields, Key and >Sequence Number, can be optionally carried in the GRE (Generic Routing >Encapsulation) Header [1]. GRE specifies a protocol for encapsulation >of an arbitrary network layer protocol over another arbitrary network >layer protocol. > >Dommety [Page 1] > >Internet Draft Key and Sequence Number Extensions to GRE February 2000 > >1. Introduction > > Current specification of Generic Routing Encapsulation [1] specifies >a protocol for encapsulation of an arbitrary network layer protocol >over another arbitrary network layer protocol. This document describes >enhancements by which two fields, Key and Sequence Number, can be >optionally carried in the GRE Header [1]. The Key field is used to >create separate sub-tunnels within a GRE Tunnel. Sequence Number field >is used to maintain sequence of packets within a GRE Tunnel. > >1.1. Specification Language > > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in RFC 2119 [3]. > > In addition, the following words are used to signify the > requirements of the specification. > > Silently discard > The implementation discards the datagram without > further processing, and without indicating an error > to the sender. The implementation SHOULD provide the > capability of logging the error, including the contents > of the discarded datagram, and SHOULD record the event > in a statistics counter. > >2. Extensions to GRE Header > > The GRE packet header[1] has the following format: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |C| Reserved0 | Ver | Protocol Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Checksum (optional) | Reserved1 (Optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The proposed GRE header will have the following format: > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |C| |K|S| Reserved0 | Ver | Protocol Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Checksum (optional) | Reserved1 (Optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key (optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number (Optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Key Present (bit 2) > > If the Key Present bit is set to 1, then it indicates that the Key > field is present in the GRE header. Otherwise, the Key field is > not present in the GRE header. > > Sequence Number Present (bit 3) > > If the Sequence Number Present bit is set to 1, then it indicates > that the Sequence Number field is present. Otherwise, the > Sequence Number field is not present in the GRE header. > > The Key and Sequence Present bits are chosen to be compatible > with RFC 1701 [2]. > >2.1. Key Field (4 octets) > > The Key field contains a four octet number which was inserted by > the encapsulator. The actual method by which this Key is obtained > is beyond the scope of this document. Key field is intended to be > used for creating separate sub-tunnels within a GRE Tunnel and the > Key field identifies the sub-tunnel. > >2.2. Sequence Number (4 octets) > > The Sequence Number field is a four byte feild and is inserted by > the encapsulator when Sequence Number Present Bit is set. The > Sequence Number MUST be used by the receiver to establish the > order in which packets have been transmitted from the encapsulator > to the receiver. The intended use of the Sequence Field is to > provide unreliable and in-order delivery. If the Key present bit > (bit 2) is set, the sequence number is specific to the sub-tunnel > identified by the Key field. Note that packets without the sequence > bit set can be sent in between packets with the sequence bit set. > > The sequence number value ranges from 1 to 2**32-1. The first > datagram is sent with a sequence number of 1. The sequence > number is thus a free running counter represented modulo 2**32, > with the exception that 1 is used when modulo 2**32 results in 0 > (i.e., rollover to 1 instead of 0). > > When the decapsulator receives an out-of sequence packet it SHOULD > be silently discarded. Additionally, reordering of out-of sequence > packets MAY be performed by the decapsulator for improved > performance and tolerance to reordering in the network (since the > state of the stateful compression or encryption is reset by packet > loss, it might help the performance to tolerate some amount of > packet reordering in the network by buffering). Exact buffering > schemes are outside the scope of this document. Note that the > sequence number is used to detect > lost packets and/or restore the original sequence of packets that > may have been reordered during transport. > > A packet is considered an out-of-sequence packet if the sequence > number of the received packet is lesser than or equal to the > sequence number of last successfully decapsulated > packet. The sequence number of a received message is considered > less than or equal to the last successfully received sequence number > if its value lies in the range of the last received sequence number > and the preceding 65534 values, inclusive. > > > If the received packet is an in-sequence packet, it is > successfully decapsulated. Note that the sequence number is used > to detect lost packets and/or restore the original sequence of > packets (with buffering) that may have been reordered during > transport. Use of the sequence number option should be used > appropriately; in particular, it is a good idea a avoid using when > tunneling protocols that have higher layer in-order delivery > mechanisms or are tolerant to out-of-order delivery. If only at certain > instances the protocol being carried in the GRE tunnel requires > in-sequence delivery, only the corresponding packets encapsulated > in a GRE header can be sent with the sequence bit set. Mechanisims > to determine which packets need to be sent in-sequence and the > signaling mechanisims are outside the scope of this document. > > > > >3. IANA Considerations > >4. Acknowledgments > > >5. References > > [1] Farinacci, D., Li, T., Hnaks, S., Meyer, D. and Traina, P., > "Generic Routing Encapsulation (GRE)," > draft-meyer-gre-update-03.txt, January 2000. > > [2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic > Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems, > October 1994. > > [3] Bradner S., "Key words for use in RFCs to Indicate Requirement > Levels", RFC 2119, March 1997. > > >Dommety [Page 4] > >Internet Draft Key and Sequence Number extensions to GRE February 2000 > >Author Information > > Gopal Dommety > Cisco Systems, Inc. > 170 West Tasman Drive > San Jose, CA 95134 > e-mail: gdommety@cisco.com > >Dommety > > > > > >Thank You. >Regards, >Gopal >--------------------------------------------------------------------------- ---------------------------------- > >Gopal Dommety >408 525 1404 >gdommety@cisco.com >Cisco Systems, San Jose, CA, 95051 > >--- >You are currently subscribed to tsgp as: rhsu@qualcomm.com > From owner-ipsec@lists.tislabs.com Fri Mar 17 09:57:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18729; Fri, 17 Mar 2000 09:57:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07285 Fri, 17 Mar 2000 11:10:30 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Pete McCann To: Gopal Dommety Cc: gre@ops.ietf.org, udlr@sophia.inria.fr, msdp@antc.uoregon.edu, ipsec@lists.tislabs.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, l2tp@ipsec.org, tsgp@3gpp2.org, tsga@3gpp2.org Subject: GRE Extensions (Modified) In-Reply-To: <200003170853.AAA15902@omega.cisco.com> References: <200003170853.AAA15902@omega.cisco.com> X-Mailer: VM 6.33 under Emacs 19.34.2 Message-Id: <20000317151636.74DB757042@king.research.bell-labs.com> Date: Fri, 17 Mar 2000 09:16:36 -0600 (CST) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The sequence number should definitely be per key! That way we can tunnel multiple streams, one per key. Each needs its own sequencing. -Pete Gopal Dommety (GD) writes: GD> Hello: GD> I have changed the sequence no to be 4 bytes. The changes request by GD> most have been made. GD> A remining issue is regarding the behaviour when both sequence no and GD> the Key are present. There are two options: GD> 1. Have sequence no per Key. This will give better granularity with GD> added complexity of implementation. GD> 2. Sequence no for the tunnel irrespective of the Key. From owner-ipsec@lists.tislabs.com Fri Mar 17 12:55:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22524; Fri, 17 Mar 2000 12:55:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07795 Fri, 17 Mar 2000 13:07:35 -0500 (EST) Message-ID: <38D27642.1395A6A7@redcreek.com> Date: Fri, 17 Mar 2000 10:15:30 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: akrywani@newbridge.com CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available References: <000601bf8eda$560a17e0$1e0101c8@ANDREWK2.TIMESTEP> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk wrote: > > > While I > > readily agree > > that a simple tallying of the posts shows a majority arguing > > in favor of > > doing heartbeats in ISAKMP, could you please spend a little > > time anyway > > going over your justifications for this approach above the others. > > Hi Ricky, > > Let me first state that the draft specifies two things: > > a) A framework for negotiating and implementing heartbeats. > b) A default mode of operation that has been chosen for interoperability. > > If you want to define some other mode of operation for use with your own > products (e.g. phase 2 heartbeats), the framework lets you do this. Just > define a new heartbeat type from the private range, exchange vendor ids, and > you're set. Consenting parties can replace any of the 3 layers we describe > in the draft. > > But as for part b, let's face it... When you're defining a standard > interoperability mode, vendor support DOES matter, and the majority of > support was for a phase 1 approach. > > Even when I talked to some of the vendors who do "dangle" phase 1 SAs, many > of them were still in favour of using phase 1 heartbeats. Most vendors who > dangle SAs say they do so only when they are low on memory, so they will > still be able to use heartbeats most of the time. > > We also wanted the default mode to be easy to understand and easy to > implement. With the heartbeat protocol, you can implement the bare minimum > set of requirements and still be guaranteed of interoperability with the > peer. > > Phase 2 heartbeats do have a number of advantages over phase 1 heartbeats, > but there are also a lot of added complications, which would make it > difficult to define a simple phase 2 heartbeat mode that is suitable for > interoperability. > > Some of the complications: using hijacked SAs (mixing customer traffic with > management traffic -- our customers don't like this), interactions with the > accounting service (requires two traffic counters), need for a policy hole > to allow the heartbeat traffic, negotiation of which exact SA parameters to > use, flexibility of packet format, potential of defeating the peer's > inactivity timeout mechanism. > > Allowing all of the common scenarios that various vendors want to support > would require a much more elaborate negotiation scheme. And it doesn't seem > fair to legislate all or most of the above behaviours. Which is why you are > free to define your own protocol for private use, at which point you can > make whatever assumptions you want about the peer's configuration. > > It's impossible to please everybody. But all things considered, I would > rather have a heartbeat protocol that has to be turned off under low memory > conditions than a protocol that causes interoperability nightmares because > it is too difficult to negotiate. > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. Howdy Andrew, You make some decent points and there well said. But I've pondered it a bit and I would like to advocate for using a much simpler mechanism, in-band in each phase 2 SA. PHASE 2 IN_BAND KEEPALIVE PROPOSAL: The mechanism is ping. The configuration requirements are that you allow one IP address each from your tunnel endpoint security gateways in among your endpoint lists so that the ping is protected by your phase2 SA. You will have to suffer the keepalive traffic in your statistics be they used for monitoring and/or accounting. As long as your SA is not otherwise receiving traffic, ping the peer gateway address once per configurable period X. After Y successive non-responses, mark the state of your SA as 'down'. Keep trying the pings and after Y successive good responses, mark the state as 'up'. Done. ( This idea is so simple that I do not claim authorship, I'm sure it came up on the list before. ) If the working group so feels, we could radify several heartbeat/keepalive mechanisms. In that case Andrew's/Tero's and my proposals are not competative. But if we think that is unweildy, or we are just too lazy and we only want one recommended keepalive mechanism, then choose your side or make up a new one and say your piece. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Fri Mar 17 14:53:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24351; Fri, 17 Mar 2000 14:53:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08136 Fri, 17 Mar 2000 15:31:33 -0500 (EST) Message-Id: <200003172036.MAA03129@omega.cisco.com> X-Sender: gdommety@omega.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 17 Mar 2000 12:49:00 -0800 To: Raymond Hsu , tsgp@3gpp2.org From: Gopal Dommety Subject: Re: GRE Extensions (Modified) Cc: udlr@sophia.inria.fr, msdp@antc.uoregon.edu, ipsec@lists.tislabs.com, MOBILE-IP@standards.nortelnetworks.com, l2tp@ipsec.org, tsgp@3gpp2.org, tsga@3gpp2.org In-Reply-To: <200003171611.IAA17317@jittlov.qualcomm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ray and Pete: Thanks. I agree with both of you. That is why the current version has this description. There was comment on the performance and that it might not be good to couple Key and sequence. So, I wanted to get opinion. Ray, even in the PCF to PDSN direction, we don't absolutely need it. We can do with option 2, but the performance may effected. If you want to do some sort of buffering and reodering, not having a sequence no will hurt performance (basically the sequence no will not have per session significance). In the draft, we have option 1 as of now. Unless there is a major objections let us leave it as it is. thanks Gopal At 08:12 AM 17/03/00 -0800, Raymond Hsu wrote: >Hi Gopal: > >In TR-45.6's R-P interface (aka A10 interface), we may use the first option >in the direction >from the PDSN to the PCF. In this direction, we've identified scenarios >where some mobiles >require in-sequence delivery and some don't. Since each mobile is >identified by the Key field >over the R-P interface, we need option 1. However, in the direction from >the PCF to the PDSN, >we don't have a strong requirement per mobile basis; thus, option 2 is >adequate. Therefore, >my recommendation is that both options should be allowed in the GRE draft. > >Regards, > >Raymond Hsu > >At 01:06 AM 3/17/00 -0800, Gopal Dommety wrote: >>Hello: >> >>I have changed the sequence no to be 4 bytes. The changes request by >>most have been made. >> >>A remining issue is regarding the behaviour when both sequence no and >>the Key are present. There are two options: >> >>1. Have sequence no per Key. This will give better granularity with >> added complexity of implementation. >> >>2. Sequence no for the tunnel irrespective of the Key. >> >>Let me know your opinion. >> >>Thanks >>Gopal >> >> >>Network Working Group Gopal Dommety >>INTERNET DRAFT cisco Systems >>Category: Standards Track March 2000 >>Title: draft-dommety-gre-ext-01.txt >> >>Expires October 2000 >> >> Key and Sequence Number Extensions to GRE >> draft-dommety-gre-ext-01.txt >> >>Status of this Memo >> >> This document is a submission by the Network Working Group of the >> Internet Engineering Task Force (IETF). Comments should be submitted >> to the gre@ops.ietf.org mailing list. >> >> Distribution of this memo is unlimited. >> >> This document is an Internet Draft and is in full conformance with >> all provisions of Section 10 of RFC2026. Internet Drafts are working >> documents of the Internet Engineering Task Force (IETF), its areas, >> and working groups. Note that other groups may also distribute >> working documents as Internet Drafts. >> >> Internet Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet Drafts as reference >> material or to cite them other than as "work in progress." >> >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt. >> >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> >>Abstract >> >> This document describes extensions by which two fields, Key and >>Sequence Number, can be optionally carried in the GRE (Generic Routing >>Encapsulation) Header [1]. GRE specifies a protocol for encapsulation >>of an arbitrary network layer protocol over another arbitrary network >>layer protocol. >> >>Dommety [Page 1] >> >>Internet Draft Key and Sequence Number Extensions to GRE February 2000 >> >>1. Introduction >> >> Current specification of Generic Routing Encapsulation [1] specifies >>a protocol for encapsulation of an arbitrary network layer protocol >>over another arbitrary network layer protocol. This document describes >>enhancements by which two fields, Key and Sequence Number, can be >>optionally carried in the GRE Header [1]. The Key field is used to >>create separate sub-tunnels within a GRE Tunnel. Sequence Number field >>is used to maintain sequence of packets within a GRE Tunnel. >> >>1.1. Specification Language >> >> The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >> this document are to be interpreted as described in RFC 2119 [3]. >> >> In addition, the following words are used to signify the >> requirements of the specification. >> >> Silently discard >> The implementation discards the datagram without >> further processing, and without indicating an error >> to the sender. The implementation SHOULD provide the >> capability of logging the error, including the contents >> of the discarded datagram, and SHOULD record the event >> in a statistics counter. >> >>2. Extensions to GRE Header >> >> The GRE packet header[1] has the following format: >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |C| Reserved0 | Ver | Protocol Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Checksum (optional) | Reserved1 (Optional) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> The proposed GRE header will have the following format: >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |C| |K|S| Reserved0 | Ver | Protocol Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Checksum (optional) | Reserved1 (Optional) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Key (optional) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence Number (Optional) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Key Present (bit 2) >> >> If the Key Present bit is set to 1, then it indicates that the Key >> field is present in the GRE header. Otherwise, the Key field is >> not present in the GRE header. >> >> Sequence Number Present (bit 3) >> >> If the Sequence Number Present bit is set to 1, then it indicates >> that the Sequence Number field is present. Otherwise, the >> Sequence Number field is not present in the GRE header. >> >> The Key and Sequence Present bits are chosen to be compatible >> with RFC 1701 [2]. >> >>2.1. Key Field (4 octets) >> >> The Key field contains a four octet number which was inserted by >> the encapsulator. The actual method by which this Key is obtained >> is beyond the scope of this document. Key field is intended to be >> used for creating separate sub-tunnels within a GRE Tunnel and the >> Key field identifies the sub-tunnel. >> >>2.2. Sequence Number (4 octets) >> >> The Sequence Number field is a four byte feild and is inserted by >> the encapsulator when Sequence Number Present Bit is set. The >> Sequence Number MUST be used by the receiver to establish the >> order in which packets have been transmitted from the encapsulator >> to the receiver. The intended use of the Sequence Field is to >> provide unreliable and in-order delivery. If the Key present bit >> (bit 2) is set, the sequence number is specific to the sub-tunnel >> identified by the Key field. Note that packets without the sequence >> bit set can be sent in between packets with the sequence bit set. >> >> The sequence number value ranges from 1 to 2**32-1. The first >> datagram is sent with a sequence number of 1. The sequence >> number is thus a free running counter represented modulo 2**32, >> with the exception that 1 is used when modulo 2**32 results in 0 >> (i.e., rollover to 1 instead of 0). >> >> When the decapsulator receives an out-of sequence packet it SHOULD >> be silently discarded. Additionally, reordering of out-of sequence >> packets MAY be performed by the decapsulator for improved >> performance and tolerance to reordering in the network (since the >> state of the stateful compression or encryption is reset by packet >> loss, it might help the performance to tolerate some amount of >> packet reordering in the network by buffering). Exact buffering >> schemes are outside the scope of this document. Note that the >> sequence number is used to detect >> lost packets and/or restore the original sequence of packets that >> may have been reordered during transport. >> >> A packet is considered an out-of-sequence packet if the sequence >> number of the received packet is lesser than or equal to the >> sequence number of last successfully decapsulated >> packet. The sequence number of a received message is considered >> less than or equal to the last successfully received sequence number >> if its value lies in the range of the last received sequence number >> and the preceding 65534 values, inclusive. >> >> >> If the received packet is an in-sequence packet, it is >> successfully decapsulated. Note that the sequence number is used >> to detect lost packets and/or restore the original sequence of >> packets (with buffering) that may have been reordered during >> transport. Use of the sequence number option should be used >> appropriately; in particular, it is a good idea a avoid using when >> tunneling protocols that have higher layer in-order delivery >> mechanisms or are tolerant to out-of-order delivery. If only at certain >> instances the protocol being carried in the GRE tunnel requires >> in-sequence delivery, only the corresponding packets encapsulated >> in a GRE header can be sent with the sequence bit set. Mechanisims >> to determine which packets need to be sent in-sequence and the >> signaling mechanisims are outside the scope of this document. >> >> >> >> >>3. IANA Considerations >> >>4. Acknowledgments >> >> >>5. References >> >> [1] Farinacci, D., Li, T., Hnaks, S., Meyer, D. and Traina, P., >> "Generic Routing Encapsulation (GRE)," >> draft-meyer-gre-update-03.txt, January 2000. >> >> [2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic >> Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems, >> October 1994. >> >> [3] Bradner S., "Key words for use in RFCs to Indicate Requirement >> Levels", RFC 2119, March 1997. >> >> >>Dommety [Page 4] >> >>Internet Draft Key and Sequence Number extensions to GRE February 2000 >> >>Author Information >> >> Gopal Dommety >> Cisco Systems, Inc. >> 170 West Tasman Drive >> San Jose, CA 95134 >> e-mail: gdommety@cisco.com >> >>Dommety >> >> >> >> >> >>Thank You. >>Regards, >>Gopal >>--------------------------------------------------------------------------- >---------------------------------- >> >>Gopal Dommety >>408 525 1404 >>gdommety@cisco.com >>Cisco Systems, San Jose, CA, 95051 >> >>--- >>You are currently subscribed to tsgp as: rhsu@qualcomm.com >> > Thank You. Regards, Gopal ------------------------------------------------------------------------------------------------------------- Gopal Dommety 408 525 1404 gdommety@cisco.com Cisco Systems, San Jose, CA, 95051 From owner-ipsec@lists.tislabs.com Fri Mar 17 15:23:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24789; Fri, 17 Mar 2000 15:23:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08448 Fri, 17 Mar 2000 17:14:16 -0500 (EST) Date: Fri, 17 Mar 2000 14:20:14 -0800 (PST) From: Joe Touch Message-Id: <200003172220.OAA07373@boreas.isi.edu> To: ipsec@lists.tislabs.com Subject: Announcing X-Bone VPN/overlay software release Sender: owner-ipsec@lists.tislabs.com Precedence: bulk xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x x x XX XX X-BONE Overlay System x x X X x x XX Software Release x x X X x x XX XX March 2000 x x x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx The X-Bone system for automated deployment of VPN / overlay networks is now publicly available. This is the first major public release, v1.2. X-Bone dynamically deploys and manages Internet overlays to reduce configuration effort and increase network component sharing. X-Bone discovers, configures, and monitors network resources to create overlays over existing IP networks. The X-Bone is implemented in Perl, and open source is provided. The X-Bone can be used for: - deploying VPNs - sharing lab or wide-area networks for multiple, concurrent projects for testing protocols and apps on new topologies X-Bone uses two-layer IP in IP tunneled overlays and supports existing applications and unmodified routing, multicast, and DNS services. X-Bone also support IPSec within overlays. Applications can use the X-Bone without modification or recompilation. The X-Bone is available for the following operating systems: - FreeBSD CAIRN 2.5, 3.*, 3.* + KAME IPsec patches - Linux RedHat 6.0, 6.0 + NIST Cerberus IPsec patches, 6.1 The FreeBSD port and Linux RPM have been submitted to the FreeBSD ports and RedHat Linux RPMs sites; further information and details and the port and RPM files are currently available at: http://www.isi.edu/xbone/ - Joe Touch Project Leader, X-Bone group, USC/ISI touch@isi.edu http://www.isi.edu/touch +1 (310) 448-9151 ------------------------------------------------------------------- Effort sponsored by the Defense Advanced Research Projects Agency (DARPA)and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-98-1-0200. Copyright (c) 1998-2000 by the University of Southern California. All rights reserved. ------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Fri Mar 17 15:25:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24850; Fri, 17 Mar 2000 15:25:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08453 Fri, 17 Mar 2000 17:14:17 -0500 (EST) Date: Fri, 17 Mar 2000 14:18:04 -0800 (PST) From: Joe Touch Message-Id: <200003172218.OAA06767@boreas.isi.edu> To: ipsec@lists.tislabs.com Subject: Announcing X-Bone VPN/overlay software release Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To: ipsec@lists.tislabs.com From owner-ipsec@lists.tislabs.com Fri Mar 17 16:05:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25535; Fri, 17 Mar 2000 16:05:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08537 Fri, 17 Mar 2000 17:36:32 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 17 Mar 2000 15:41:45 -0700 From: "Hilarie Orman" To: , , Subject: RE: AES draft query Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA08534 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You might want to also look at draft-orman-public-key-lengths-00.txt which does discuss selecting key exchange system strength to match the system cryptographic strength requirements. Hilarie From owner-ipsec@lists.tislabs.com Fri Mar 17 16:05:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25536; Fri, 17 Mar 2000 16:05:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08555 Fri, 17 Mar 2000 17:37:20 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 17 Mar 2000 15:42:32 -0700 From: "Hilarie Orman" To: , , Subject: RE: AES draft query Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA08552 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk These issues are discussed in draft-orman-public-key-lengths-00.txt on which commentary is solicited. Hilarie >>> "Linn, John" 03/16/00 11:17AM >>> Jesse, Good points. While the incremental cost of additional symmetric key bits beyond the anticipated state of the art is "almost free", this is very much not true for increasing the number of asymmetric key bits used to transport those symmetric keys. An RSA Laboratories paper with further analysis on key size issues is now being finalized for web publication, probably within the next couple of weeks; I'll post a citation when it's available. --jl > -----Original Message----- > From: Walker, Jesse [mailto:jesse.walker@intel.com] > Sent: Thursday, March 16, 2000 9:29 AM > To: ipsec@lists.tislabs.com > Subject: AES draft query > > > Page 9 of the draft recommends 3240-bit Diffie-Hellmans for > 128-bit AES, > 7945-bit Diffie-Hellmans for 192-bit AES, and 15430-bit > Diffie-Hellmans for > 256-bit AES. It is worth discussing whether these > requirements address a > real perceived threat or are at best theoretical in nature. > While the defers > the discussion on how they were derived to a reference, it is > easy enough to > guess how they were obtained: select the Diffie-Hellman > modulus size at the > point where computing the discrete logarithm becomes just as > expensive as > attacking the symmetric key directly. However, unlike > symmetric algorithms, > public key operations like Diffie-Hellmans have a real cost, > so this may not > be the best way to set the requirement, even if it is > theoretically the > "right" way to do the job. Even if you believe Moore's law > will remain true > for the forseeable future, 8K and 15K still represent about 9 > and 11 more > generations of processors, respectively, before you get > performance most > users will tolerate. The most credible study I've seen estimating key > strengths is Lenstra and Verheul's "Selecting Cryptographic > Key Sizes", > November 15, 1999. They estimate that 4K modular > exponentiations will still > be secure from any reasonable attacks for the next 50 years. > So why should > there be a requirement for anything above about 4K > Diffie-Hellmans at this > time? On the point of Diffie-Hellman modulus sizes, the draft's > requirements seem to be way out of line both in regard to the state of > technology and in regard to the nature of the perceived > possible threats in > the time frames when the draft will be applicable. What am I missing? > > -- Jesse Walker > > From owner-ipsec@lists.tislabs.com Fri Mar 17 17:13:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA26868; Fri, 17 Mar 2000 17:13:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08870 Fri, 17 Mar 2000 18:50:39 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: "Hilarie Orman" cc: jesse.walker@intel.com, ipsec@lists.tislabs.com, jlinn@rsasecurity.com Message-ID: <852568A5.0083390E.00@smtpmail.certicom.com> Date: Fri, 17 Mar 2000 15:54:20 -0800 Subject: RE: AES draft query Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk absolutely correct. but there is also 2 key 3des. as schneier and whiting recently pointed out: http://www.counterpane.com/aes-comparison.html key size is increased at the cost of performance with all AES canidates. So why would one use larger strength AES algorithms without using the corresponding strength with public-key? cheers - john "Hilarie Orman" on 17.03.2000 15:45:20 To: John Harleman/Certicom@Certicom cc: jesse.walker@intel.com, ipsec@lists.tislabs.com, jlinn@rsasecurity.com Subject: RE: AES draft query Note that 3DES key length has only a loose relation to the strength of the algorithm and the strength requirement of users. The key length is what it is because 3*56 = 168. It's often the case that you can get a cipher that has a long key length and is fast. In that case, you don't worry about whether or not the key has more strength than you need. To date that luxury does not exist for scalable key exchange algorithms - each bit of strength costs a lot in computation cost. Thus, the desire to adjust the key exchange strength to minimum system requirement (or the maximum tolerable computation effort). Hilarie >>> "John Harleman" 03/17/00 04:34PM >>> I fully appreciate the security that 128-bit symmetric brings. Key sizes such as this for AES or 112-bit symmetric for 2-key 3DES are understandable since they are the next logical jump in size above 80-bit symmetric (160-bit ECC and 1,024 RSA). However, 192-bit AES or 256-AES coupled with lesser strength public-key is misleading since the security of the system is only as strong as the weakest link. So my question would be why would anybody implement AES at key strengths above 128-bits or 3DES at 168-bits without using the correspondingly strong public-key size? cheers - john "Hilarie Orman" on 17.03.2000 14:42:32 To: jesse.walker@intel.com, ipsec@lists.tislabs.com, jlinn@rsasecurity.com cc: (bcc: John Harleman/Certicom) Subject: RE: AES draft query These issues are discussed in draft-orman-public-key-lengths-00.txt on which commentary is solicited. Hilarie >>> "Linn, John" 03/16/00 11:17AM >>> Jesse, Good points. While the incremental cost of additional symmetric key bits beyond the anticipated state of the art is "almost free", this is very much not true for increasing the number of asymmetric key bits used to transport those symmetric keys. An RSA Laboratories paper with further analysis on key size issues is now being finalized for web publication, probably within the next couple of weeks; I'll post a citation when it's available. --jl > -----Original Message----- > From: Walker, Jesse [mailto:jesse.walker@intel.com] > Sent: Thursday, March 16, 2000 9:29 AM > To: ipsec@lists.tislabs.com > Subject: AES draft query > > > Page 9 of the draft recommends 3240-bit Diffie-Hellmans for > 128-bit AES, > 7945-bit Diffie-Hellmans for 192-bit AES, and 15430-bit > Diffie-Hellmans for > 256-bit AES. It is worth discussing whether these > requirements address a > real perceived threat or are at best theoretical in nature. > While the defers > the discussion on how they were derived to a reference, it is > easy enough to > guess how they were obtained: select the Diffie-Hellman > modulus size at the > point where computing the discrete logarithm becomes just as > expensive as > attacking the symmetric key directly. However, unlike > symmetric algorithms, > public key operations like Diffie-Hellmans have a real cost, > so this may not > be the best way to set the requirement, even if it is > theoretically the > "right" way to do the job. Even if you believe Moore's law > will remain true > for the forseeable future, 8K and 15K still represent about 9 > and 11 more > generations of processors, respectively, before you get > performance most > users will tolerate. The most credible study I've seen estimating key > strengths is Lenstra and Verheul's "Selecting Cryptographic > Key Sizes", > November 15, 1999. They estimate that 4K modular > exponentiations will still > be secure from any reasonable attacks for the next 50 years. > So why should > there be a requirement for anything above about 4K > Diffie-Hellmans at this > time? On the point of Diffie-Hellman modulus sizes, the draft's > requirements seem to be way out of line both in regard to the state of > technology and in regard to the nature of the perceived > possible threats in > the time frames when the draft will be applicable. What am I missing? > > -- Jesse Walker > > From owner-ipsec@lists.tislabs.com Fri Mar 17 17:14:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA26906; Fri, 17 Mar 2000 17:14:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08824 Fri, 17 Mar 2000 18:41:12 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 17 Mar 2000 16:45:20 -0700 From: "Hilarie Orman" To: Cc: , , Subject: RE: AES draft query Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA08820 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Note that 3DES key length has only a loose relation to the strength of the algorithm and the strength requirement of users. The key length is what it is because 3*56 = 168. It's often the case that you can get a cipher that has a long key length and is fast. In that case, you don't worry about whether or not the key has more strength than you need. To date that luxury does not exist for scalable key exchange algorithms - each bit of strength costs a lot in computation cost. Thus, the desire to adjust the key exchange strength to minimum system requirement (or the maximum tolerable computation effort). Hilarie >>> "John Harleman" 03/17/00 04:34PM >>> I fully appreciate the security that 128-bit symmetric brings. Key sizes such as this for AES or 112-bit symmetric for 2-key 3DES are understandable since they are the next logical jump in size above 80-bit symmetric (160-bit ECC and 1,024 RSA). However, 192-bit AES or 256-AES coupled with lesser strength public-key is misleading since the security of the system is only as strong as the weakest link. So my question would be why would anybody implement AES at key strengths above 128-bits or 3DES at 168-bits without using the correspondingly strong public-key size? cheers - john "Hilarie Orman" on 17.03.2000 14:42:32 To: jesse.walker@intel.com, ipsec@lists.tislabs.com, jlinn@rsasecurity.com cc: (bcc: John Harleman/Certicom) Subject: RE: AES draft query These issues are discussed in draft-orman-public-key-lengths-00.txt on which commentary is solicited. Hilarie >>> "Linn, John" 03/16/00 11:17AM >>> Jesse, Good points. While the incremental cost of additional symmetric key bits beyond the anticipated state of the art is "almost free", this is very much not true for increasing the number of asymmetric key bits used to transport those symmetric keys. An RSA Laboratories paper with further analysis on key size issues is now being finalized for web publication, probably within the next couple of weeks; I'll post a citation when it's available. --jl > -----Original Message----- > From: Walker, Jesse [mailto:jesse.walker@intel.com] > Sent: Thursday, March 16, 2000 9:29 AM > To: ipsec@lists.tislabs.com > Subject: AES draft query > > > Page 9 of the draft recommends 3240-bit Diffie-Hellmans for > 128-bit AES, > 7945-bit Diffie-Hellmans for 192-bit AES, and 15430-bit > Diffie-Hellmans for > 256-bit AES. It is worth discussing whether these > requirements address a > real perceived threat or are at best theoretical in nature. > While the defers > the discussion on how they were derived to a reference, it is > easy enough to > guess how they were obtained: select the Diffie-Hellman > modulus size at the > point where computing the discrete logarithm becomes just as > expensive as > attacking the symmetric key directly. However, unlike > symmetric algorithms, > public key operations like Diffie-Hellmans have a real cost, > so this may not > be the best way to set the requirement, even if it is > theoretically the > "right" way to do the job. Even if you believe Moore's law > will remain true > for the forseeable future, 8K and 15K still represent about 9 > and 11 more > generations of processors, respectively, before you get > performance most > users will tolerate. The most credible study I've seen estimating key > strengths is Lenstra and Verheul's "Selecting Cryptographic > Key Sizes", > November 15, 1999. They estimate that 4K modular > exponentiations will still > be secure from any reasonable attacks for the next 50 years. > So why should > there be a requirement for anything above about 4K > Diffie-Hellmans at this > time? On the point of Diffie-Hellman modulus sizes, the draft's > requirements seem to be way out of line both in regard to the state of > technology and in regard to the nature of the perceived > possible threats in > the time frames when the draft will be applicable. What am I missing? > > -- Jesse Walker > > From owner-ipsec@lists.tislabs.com Fri Mar 17 17:16:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA26947; Fri, 17 Mar 2000 17:16:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08789 Fri, 17 Mar 2000 18:31:39 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: "Hilarie Orman" cc: jesse.walker@intel.com, ipsec@lists.tislabs.com, jlinn@rsasecurity.com Message-ID: <852568A5.008178CD.00@smtpmail.certicom.com> Date: Fri, 17 Mar 2000 15:34:30 -0800 Subject: RE: AES draft query Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I fully appreciate the security that 128-bit symmetric brings. Key sizes such as this for AES or 112-bit symmetric for 2-key 3DES are understandable since they are the next logical jump in size above 80-bit symmetric (160-bit ECC and 1,024 RSA). However, 192-bit AES or 256-AES coupled with lesser strength public-key is misleading since the security of the system is only as strong as the weakest link. So my question would be why would anybody implement AES at key strengths above 128-bits or 3DES at 168-bits without using the correspondingly strong public-key size? cheers - john "Hilarie Orman" on 17.03.2000 14:42:32 To: jesse.walker@intel.com, ipsec@lists.tislabs.com, jlinn@rsasecurity.com cc: (bcc: John Harleman/Certicom) Subject: RE: AES draft query These issues are discussed in draft-orman-public-key-lengths-00.txt on which commentary is solicited. Hilarie >>> "Linn, John" 03/16/00 11:17AM >>> Jesse, Good points. While the incremental cost of additional symmetric key bits beyond the anticipated state of the art is "almost free", this is very much not true for increasing the number of asymmetric key bits used to transport those symmetric keys. An RSA Laboratories paper with further analysis on key size issues is now being finalized for web publication, probably within the next couple of weeks; I'll post a citation when it's available. --jl > -----Original Message----- > From: Walker, Jesse [mailto:jesse.walker@intel.com] > Sent: Thursday, March 16, 2000 9:29 AM > To: ipsec@lists.tislabs.com > Subject: AES draft query > > > Page 9 of the draft recommends 3240-bit Diffie-Hellmans for > 128-bit AES, > 7945-bit Diffie-Hellmans for 192-bit AES, and 15430-bit > Diffie-Hellmans for > 256-bit AES. It is worth discussing whether these > requirements address a > real perceived threat or are at best theoretical in nature. > While the defers > the discussion on how they were derived to a reference, it is > easy enough to > guess how they were obtained: select the Diffie-Hellman > modulus size at the > point where computing the discrete logarithm becomes just as > expensive as > attacking the symmetric key directly. However, unlike > symmetric algorithms, > public key operations like Diffie-Hellmans have a real cost, > so this may not > be the best way to set the requirement, even if it is > theoretically the > "right" way to do the job. Even if you believe Moore's law > will remain true > for the forseeable future, 8K and 15K still represent about 9 > and 11 more > generations of processors, respectively, before you get > performance most > users will tolerate. The most credible study I've seen estimating key > strengths is Lenstra and Verheul's "Selecting Cryptographic > Key Sizes", > November 15, 1999. They estimate that 4K modular > exponentiations will still > be secure from any reasonable attacks for the next 50 years. > So why should > there be a requirement for anything above about 4K > Diffie-Hellmans at this > time? On the point of Diffie-Hellman modulus sizes, the draft's > requirements seem to be way out of line both in regard to the state of > technology and in regard to the nature of the perceived > possible threats in > the time frames when the draft will be applicable. What am I missing? > > -- Jesse Walker > > From owner-ipsec@lists.tislabs.com Fri Mar 17 19:21:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA06296; Fri, 17 Mar 2000 19:21:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09010 Fri, 17 Mar 2000 19:54:36 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Ricky Charlet'" Cc: Subject: RE: Heartbeats draft available Date: Fri, 17 Mar 2000 20:06:32 -0500 Message-Id: <001401bf9076$334984a0$1e0101c8@ANDREWK2.TIMESTEP> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <38D27642.1395A6A7@redcreek.com> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > If the working group so feels, we could radify several > heartbeat/keepalive mechanisms. In that case Andrew's/Tero's and my > proposals are not competative. But if we think that is unweildy, or we > are just too lazy and we only want one recommended keepalive > mechanism, > then choose your side or make up a new one and say your piece. Hi Ricky, Even though Tero and I were both amenable to the concept of phase 2 heartbeats, we thought it was more important to encourage interoperability by keeping the number of standardized configuration options low. Your proposal is indeed simple, but it requires knowledge about the peer's configuration that you should not assume. (I notice that you made no mention of a negotiation phase.) The peer may not want you to send traffic on a hijacked SA, therefore it would be inappropriate to do so unless this was negotiated (along with the various session parameters). Unfortunately, for the reasons I mentioned previously, some implementations would be unable to use your method. This makes it unsuitable for use as an interoperability mode. I don't see how you could fix this problem without, for example, requiring that all IPsec SAs terminating at the public IP of the sgw be classified as management SAs (with implied policy holes, accounting rules, and exemption from inactivity timeouts). Unfortunately, I don't think the vendors already sending L2TP traffic on this channel would play along. There is a stipulation in the draft that new heartbeat types can be added, but only if there is a clear need for a feature that cannot be provided by the existing protocol. So if there is an essential need for a phase 2 heartbeat then we can add it to the draft later. What we are trying to avoid here is the case where implementers feel compelled to support each of the bajillion different heartbeat formats that we had to add to the draft because we were trying to cater to every individual. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: rcharlet@newbridge.com > [mailto:rcharlet@newbridge.com]On Behalf Of > Ricky Charlet > Sent: Friday, March 17, 2000 1:16 PM > To: akrywani@newbridge.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Heartbeats draft available > > > Andrew Krywaniuk wrote: > > > > > While I > > > readily agree > > > that a simple tallying of the posts shows a majority arguing > > > in favor of > > > doing heartbeats in ISAKMP, could you please spend a little > > > time anyway > > > going over your justifications for this approach above the others. > > > > Hi Ricky, > > > > Let me first state that the draft specifies two things: > > > > a) A framework for negotiating and implementing heartbeats. > > b) A default mode of operation that has been chosen for > interoperability. > > > > If you want to define some other mode of operation for use > with your own > > products (e.g. phase 2 heartbeats), the framework lets you > do this. Just > > define a new heartbeat type from the private range, > exchange vendor ids, and > > you're set. Consenting parties can replace any of the 3 > layers we describe > > in the draft. > > > > But as for part b, let's face it... When you're defining a standard > > interoperability mode, vendor support DOES matter, and the > majority of > > support was for a phase 1 approach. > > > > Even when I talked to some of the vendors who do "dangle" > phase 1 SAs, many > > of them were still in favour of using phase 1 heartbeats. > Most vendors who > > dangle SAs say they do so only when they are low on memory, > so they will > > still be able to use heartbeats most of the time. > > > > We also wanted the default mode to be easy to understand and easy to > > implement. With the heartbeat protocol, you can implement > the bare minimum > > set of requirements and still be guaranteed of > interoperability with the > > peer. > > > > Phase 2 heartbeats do have a number of advantages over > phase 1 heartbeats, > > but there are also a lot of added complications, which would make it > > difficult to define a simple phase 2 heartbeat mode that is > suitable for > > interoperability. > > > > Some of the complications: using hijacked SAs (mixing > customer traffic with > > management traffic -- our customers don't like this), > interactions with the > > accounting service (requires two traffic counters), need > for a policy hole > > to allow the heartbeat traffic, negotiation of which exact > SA parameters to > > use, flexibility of packet format, potential of defeating the peer's > > inactivity timeout mechanism. > > > > Allowing all of the common scenarios that various vendors > want to support > > would require a much more elaborate negotiation scheme. And > it doesn't seem > > fair to legislate all or most of the above behaviours. > Which is why you are > > free to define your own protocol for private use, at which > point you can > > make whatever assumptions you want about the peer's configuration. > > > > It's impossible to please everybody. But all things > considered, I would > > rather have a heartbeat protocol that has to be turned off > under low memory > > conditions than a protocol that causes interoperability > nightmares because > > it is too difficult to negotiate. > > > > Andrew > > _______________________________________________ > > Beauty without truth is insubstantial. > > Truth without beauty is unbearable. > > > Howdy Andrew, > You make some decent points and there well said. But > I've pondered it a > bit and I would like to advocate for using a much simpler mechanism, > in-band in each phase 2 SA. > > PHASE 2 IN_BAND KEEPALIVE PROPOSAL: > The mechanism is ping. The configuration requirements > are that you > allow one IP address each from your tunnel endpoint security > gateways in > among your endpoint lists so that the ping is protected by your phase2 > SA. You will have to suffer the keepalive traffic in your > statistics be > they used for monitoring and/or accounting. As long as your SA is not > otherwise receiving traffic, ping the peer gateway address once per > configurable period X. After Y successive non-responses, mark > the state > of your SA as 'down'. Keep trying the pings and after Y > successive good > responses, mark the state as 'up'. Done. ( This idea is so > simple that I > do not claim authorship, I'm sure it came up on the list before. ) > > If the working group so feels, we could radify several > heartbeat/keepalive mechanisms. In that case Andrew's/Tero's and my > proposals are not competative. But if we think that is unweildy, or we > are just too lazy and we only want one recommended keepalive > mechanism, > then choose your side or make up a new one and say your piece. > > > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > From owner-ipsec@lists.tislabs.com Fri Mar 17 21:14:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA14090; Fri, 17 Mar 2000 21:14:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA09307 Fri, 17 Mar 2000 22:08:33 -0500 (EST) Message-Id: <4.3.2.20000317190722.00c2e410@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 17 Mar 2000 19:14:43 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: RE: AES draft query In-Reply-To: <852568A5.0083390E.00@smtpmail.certicom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:54 PM 3/17/00 -0800, John Harleman wrote: >absolutely correct. but there is also 2 key 3des. as schneier and whiting >recently pointed out: > >http://www.counterpane.com/aes-comparison.html > >key size is increased at the cost of performance with all AES canidates. >So why >would one use larger strength AES algorithms without using the corresponding >strength with public-key? cheers - john There could be many reasons. Some might include: - due to your hardware accelerator, 128->256 AES might only cost you 50% more time but the corresponding increase in public key might cost you 200% - the other party only offered you one AES length but many acceptable choices for public key lengths There are probably others. The baseline decision is "are both the symmetric and asymmetric keys strong enough for what I want?" If the answer is yes, it does not matter if there is a mismatch in strength. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Mar 17 22:20:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA15265; Fri, 17 Mar 2000 22:20:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA09362 Fri, 17 Mar 2000 23:12:16 -0500 (EST) Message-ID: <38D301E3.88E69FD8@isi.edu> Date: Fri, 17 Mar 2000 20:11:15 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Announcing X-Bone VPN/overlay software release References: <200003172220.OAA07373@boreas.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk FWIW - This is the system that implements the IPsec transport/IPIP tunnels for overlay networks. (draft-touch-ipsec-vpn-00.txt) It may also be of interest for network experiments and testbeds.... Joe Touch wrote: > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > x x > x XX XX X-BONE Overlay System x > x X X x > x XX Software Release x > x X X x > x XX XX March 2000 x > x x > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx From owner-ipsec@lists.tislabs.com Fri Mar 17 23:43:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA20132; Fri, 17 Mar 2000 23:43:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA09593 Sat, 18 Mar 2000 00:58:12 -0500 (EST) To: Paul Hoffman Cc: ipsec@lists.tislabs.com Subject: Re: AES draft query References: <4.3.2.20000317190722.00c2e410@mail.vpnc.org> From: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 17 Mar 2000 22:05:57 -0800 In-Reply-To: Paul Hoffman's message of "Fri, 17 Mar 2000 19:14:43 -0800" Message-ID: Lines: 32 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman writes: > At 03:54 PM 3/17/00 -0800, John Harleman wrote: > >absolutely correct. but there is also 2 key 3des. as schneier and whiting > >recently pointed out: > > > >http://www.counterpane.com/aes-comparison.html > > > >key size is increased at the cost of performance with all AES canidates. > >So why > >would one use larger strength AES algorithms without using the corresponding > >strength with public-key? cheers - john > > There could be many reasons. Some might include: > - due to your hardware accelerator, 128->256 AES might only cost you 50% > more time but the corresponding increase in public key might cost you 200% > - the other party only offered you one AES length but many acceptable > choices for public key lengths > There are probably others. The baseline decision is "are both the symmetric > and asymmetric keys strong enough for what I want?" If the answer is yes, > it does not matter if there is a mismatch in strength. I disagree with this position, for two reasons: 1. It's inefficient from a design perspective. Why incur additional performance costs if they don't add any security value? Even if the cost is only 50%, why pay it if it's not adding anything. 2. It's very confusing to users, who expect security to increase with increasing key size. -Ekr From owner-ipsec@lists.tislabs.com Sat Mar 18 09:00:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16497; Sat, 18 Mar 2000 09:00:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10510 Sat, 18 Mar 2000 10:44:33 -0500 (EST) Message-Id: <4.3.2.20000318073338.04ed99f0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sat, 18 Mar 2000 07:50:38 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: AES draft query In-Reply-To: References: <4.3.2.20000317190722.00c2e410@mail.vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:05 PM 3/17/00 -0800, EKR wrote: >I disagree with this position, for two reasons: It's not a "position", it's an explanation about why the situation might happen. >1. It's inefficient from a design perspective. Why incur additional >performance costs if they don't add any security value? Even >if the cost is only 50%, why pay it if it's not adding anything. This is technically correct, but irrelevant. Unless we mandate that "if you use AES-128, you MUST only use public keys of exactly 2056 bits and nothing else", the mismatch will continue to happen. This is particularly true between two parties who have looked at different numbers for the equivalent strengths of symmetric and asymmetric keys and come to different conclusions. The numbers that Hilarie and I came up with differ from other numbers being proposed because we used different assumptions about the future. >2. It's very confusing to users, who expect security to increase >with increasing key size. Disagree. The statement I made was: > The baseline decision is "are both the symmetric > and asymmetric keys strong enough for what I want?" A user who is smart enough to answer that question correctly is smart enough to know that increasing the size of one key at a different rate than the other key is not going to get a balanced increase in security. Of course, it is the rare IPsec user who understands this concept, and most go by "I hear 128 is enough" and, unfortunately, "I hear 256 is better than 128 and my security gateway still seems to run fast so I'll use 256". This can be countered with education, to the somewhat limited extent that education about security has been successful. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sat Mar 18 09:03:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16555; Sat, 18 Mar 2000 09:03:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10468 Sat, 18 Mar 2000 10:18:20 -0500 (EST) Message-ID: <38D3A042.4BF41C2F@ix.netcom.com> Date: Sat, 18 Mar 2000 07:26:58 -0800 From: "Scott G. Kelly" Organization: poor, but improving X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.5-15 i586) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: AES draft query References: <392A357CE6FFD111AC3E00A0C99848B002FE9448@hdsmsx31.hd.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (posting from home) While I agree that doing DH using {3240,7945,15340}-bit moduli is a bit intimidating, and also that some users' security requirements might permit the use of significantly smaller exponents/moduli, something rubs me wrong about *recommending* the use of smaller values. After all, we're guessing about what sort of breakthroughs will be made in PK attacks over the next n years. While I recognize that a breakthrough could likewise occur with respect to a brute force attack, there is not much we can do about this, except to further increase key sizes. Perhaps a better approach would be to expand the discussion a bit. We could point out that these are the minimum numbers of bits required to ensure that a brute force attack on the DH exchange is as difficult as a brute force attack on an m-random-bit session key, and then briefly discuss reductions in these values, pointing to Hilarie's and Paul's draft on the subject. In any event, I think it is appropriate to be as clear as is practical regarding the bit strength, short of replicating the above-mentioned key-strength draft's considerations inside of every new cipher draft. As an aside, this seems to make a pretty good case for the use of EC's. Scott From owner-ipsec@lists.tislabs.com Sun Mar 19 09:42:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27783; Sun, 19 Mar 2000 09:42:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13059 Sun, 19 Mar 2000 10:47:00 -0500 (EST) To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@cs.berkeley.edu (David A. Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: MAC speeds Date: 19 Mar 2000 07:13:46 -0800 Organization: A poorly-installed InterNetNews site Lines: 16 Distribution: isaac Message-ID: <8b2qra$qeg$1@blowfish.isaac.cs.berkeley.edu> References: <20000314223229.26334.qmail@cr.yp.to> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In article , Henry Spencer wrote: > On 14 Mar 2000, D. J. Bernstein wrote: > > Asking how much scrutiny a Wegman-Carter-type authentication system has > > received is like asking how much scrutiny counter mode has received: > > you're missing the point. The security is _provably_ as good as the > > encryption function you plug in. > > That just shifts the problem one step: how much scrutiny has that proof had? Lots. This particular proof is taught in (some/many) graduate theory classes, and is an especially simple one as well. For some proofs (especially lengthy, complex, recent, or obscure proofs), there are very good reasons to start asking questions like this, but the proof of security for Wegman-Carter-like authentication is not one of them. From owner-ipsec@lists.tislabs.com Sun Mar 19 11:32:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28700; Sun, 19 Mar 2000 11:32:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13353 Sun, 19 Mar 2000 13:09:50 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: Paul Hoffman cc: ipsec@lists.tislabs.com, "Scott G. Kelly" , EKR Message-ID: <852568A7.0063FFCA.00@smtpmail.certicom.com> Date: Sun, 19 Mar 2000 10:18:02 -0800 Subject: Re: AES draft query Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree that this is a marketing and education problem. I've used a lot of IPSec clients and browsers. In most all cases, the advertised strength has been based on the symmetric cipher. When setting a symmetric strength, the appropriate corresponding PK strength should be highlighted so that the users can at least make an informed decision and not unnecessarily burden their equipment as EKR points out. It is not easy for users to understand that something symmetric = double that value when using ecc = something completely different when using DH or RSA. This doesn't change the fact, however, that it does not make sense to deploy a stronger symmetric algorithm than a public-key one and that if one is incorporating 256-bit symmetric into a protocol or product, one should incorporate that corresponding public-key strengths. cheers - john Paul Hoffman on 18.03.2000 07:50:38 To: ipsec@lists.tislabs.com cc: (bcc: John Harleman/Certicom) Subject: Re: AES draft query At 10:05 PM 3/17/00 -0800, EKR wrote: >I disagree with this position, for two reasons: It's not a "position", it's an explanation about why the situation might happen. >1. It's inefficient from a design perspective. Why incur additional >performance costs if they don't add any security value? Even >if the cost is only 50%, why pay it if it's not adding anything. This is technically correct, but irrelevant. Unless we mandate that "if you use AES-128, you MUST only use public keys of exactly 2056 bits and nothing else", the mismatch will continue to happen. This is particularly true between two parties who have looked at different numbers for the equivalent strengths of symmetric and asymmetric keys and come to different conclusions. The numbers that Hilarie and I came up with differ from other numbers being proposed because we used different assumptions about the future. >2. It's very confusing to users, who expect security to increase >with increasing key size. Disagree. The statement I made was: > The baseline decision is "are both the symmetric > and asymmetric keys strong enough for what I want?" A user who is smart enough to answer that question correctly is smart enough to know that increasing the size of one key at a different rate than the other key is not going to get a balanced increase in security. Of course, it is the rare IPsec user who understands this concept, and most go by "I hear 128 is enough" and, unfortunately, "I hear 256 is better than 128 and my security gateway still seems to run fast so I'll use 256". This can be countered with education, to the somewhat limited extent that education about security has been successful. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Sun Mar 19 15:23:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01000; Sun, 19 Mar 2000 15:23:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13834 Sun, 19 Mar 2000 17:01:16 -0500 (EST) Date: Mon, 20 Mar 2000 00:06:25 +0200 (IST) From: Hugo Krawczyk To: "David A. Wagner" cc: ipsec@lists.tislabs.com Subject: Re: MAC speeds In-Reply-To: <8b2qra$qeg$1@blowfish.isaac.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 19 Mar 2000, David A. Wagner wrote: > In article , > Henry Spencer wrote: > > On 14 Mar 2000, D. J. Bernstein wrote: > > > Asking how much scrutiny a Wegman-Carter-type authentication system has > > > received is like asking how much scrutiny counter mode has received: > > > you're missing the point. The security is _provably_ as good as the > > > encryption function you plug in. > > > > That just shifts the problem one step: how much scrutiny has that proof had? > > Lots. This particular proof is taught in (some/many) graduate theory > classes, and is an especially simple one as well. > > For some proofs (especially lengthy, complex, recent, or obscure proofs), > there are very good reasons to start asking questions like this, but the > proof of security for Wegman-Carter-like authentication is not one of them. > Not only that; when using the Wegman-Carter approach you do not need to speculate on the future strength of the hash function and derive complicated estimates that measure the development of the human "cryptanalytical brain" (as we are seeing now for deriving key sizes). With CW hashes you give an EXACT mathematical *proven* bound on the collision probablility and from there you derive your MAC strength (still, of course, you have to apply a one-block encryption per-mesage and that part does require some cryptanalytical speculation -- but in a much more restricted sense than other MAC solutions). Hugo From owner-ipsec@lists.tislabs.com Sun Mar 19 15:27:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01034; Sun, 19 Mar 2000 15:27:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13788 Sun, 19 Mar 2000 16:48:02 -0500 (EST) Date: Sun, 19 Mar 2000 23:52:51 +0200 (IST) From: Hugo Krawczyk To: ipsec list Subject: Re: AES draft query In-Reply-To: <38D3A042.4BF41C2F@ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Judging from the estimates in Lenstra-Verheul's [LV, http://www.cryptosavvy.com/cryptosizes.pdf] paper for modp groups, DH modulus lengths in the range of 1500-2000 bits should be suitable today for securing information that requires 20-30 years range protection. Barring major (possibly disastrous) cryptnalytical advances, I find their analysis to be quite reasonable (at least in what concerns DH modp sizes). They assume future DH cryptanalysis to progress at a rate similar to the cryptanalytical advances seen in the last 10-20 years; same for computing costs. The desired security level is modelled through an attacker that in 2000's costs is able to spend 16 Million PC-years in the attack. This seems to be a quite powerful attacker, certainly in terms of commercial security. Thus, it seems to me that for MOST commercial applications the above range of DH prime size is convincingly sufficient. This is in strong contrast with draft-ietf-ipsec-ciph-aes-cbc-00.txt that specifies 3240-bit DH primes to be used before the end of 2000 (when 128-bit AES will be adopted), not to speak of 8000 and 15000 bits recommended in that draft for longer AES keys. Actually, the [LV] estimates consider a 3400-bit modulus to be a safe choice even for 50-year security. In my opinion overkill sizes can kill security all together. The performance penalty may drive people to abandon security or to weak it by skipping some mechanisms (after all who is using DH in SSL today?) I also doubt that anyone REALLY requiring 50-year range secrecy should be using public key algorithms to establish keys. Such specialized applications do not usually happen between "spontaneous partners". In these cases, strong physically protected shared keys may well do the job. (You can use a CD-ROM full of one-time random bits or use a shorter manually installed key and "triple-encrypt" data with three of your favorite block ciphers.) Of course I am taking a chance by questioning draft-ietf-ipsec-ciph-aes-cbc-00.txt recommendations. After all they may prove to be correct in 10 (or less) years from now. But then it is not clear that even their recommended sizes will suffice. Except, of course, if the guys from NIST know something we do not know... :) Finally, a word about recommendations regarding Elliptic-Curve algorithms (in particular in draft-ietf-ipsec-ciph-aes-cbc-00.txt). To me the recommendations regarding these groups are in sharp contrast with the conservative numbers used for the modp groups. They basically assume that NO significant cryptanalytical advance will happen in this area in the next 20-50 years. That's HARD to believe. Note that cryptanalytical advances against EC systems are happening all the time. So far they only concerned special-type groups, but we are quite in the infancy of this research (if we compare the amount of research and resources spent on EC cryptosystems relative to those spent so far on factoring and Dlog). A significant cryptanalytical advance regarding the proposed EC systems will easily render these groups totally insecure since no safety margin was planned ahead. [One can use the following analogy regarding modp vs EC groups: consider a city like San Francisco, where buildings are built to withstand some significant level of seismic activity, and another city that never suffered an earthquake. While it may seem safer to live in the later city, let's imagine that one day you are told that an earthquake of unknown strength is going to happen at both places, and you must be in one of them. Which city would you choose?] This is not to say that one should abandon EC groups; I only recommend care. For example, I would feel comfortable with current-size groups for short-term secrecy, I would go for a much larger safety margin for mid-term security, and would go with my CD-ROM for long-term security... Hugo From owner-ipsec@lists.tislabs.com Mon Mar 20 03:28:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25682; Mon, 20 Mar 2000 03:28:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA15461 Mon, 20 Mar 2000 04:54:56 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: daw@cs.berkeley.edu (David A. Wagner) Cc: ipsec@lists.tislabs.com Subject: Re: MAC speeds Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Mar 2000 21:00:51 +1100 Message-Id: <20000320100058.77062ACAA9@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <8b2qra$qeg$1@blowfish.isaac.cs.berkeley.edu>, David A. Wagner write s: >In article , >Henry Spencer wrote: >> On 14 Mar 2000, D. J. Bernstein wrote: >> > Asking how much scrutiny a Wegman-Carter-type authentication system has >> > received is like asking how much scrutiny counter mode has received: >> > you're missing the point. The security is _provably_ as good as the >> > encryption function you plug in. >> >> That just shifts the problem one step: how much scrutiny has that proof had >? > >Lots. This particular proof is taught in (some/many) graduate theory >classes, and is an especially simple one as well. > >For some proofs (especially lengthy, complex, recent, or obscure proofs), >there are very good reasons to start asking questions like this, but the >proof of security for Wegman-Carter-like authentication is not one of them. > Thanks -- I don't particularly trust Bernstein's judgment on some things... Btw -- we're going to hold the interiews to two days -- anything more is too rough on the candidates. --Steve Bellovin From owner-ipsec@lists.tislabs.com Mon Mar 20 03:31:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25770; Mon, 20 Mar 2000 03:31:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA15506 Mon, 20 Mar 2000 05:08:05 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A02E@baltimore.com> From: Chris Trobridge To: daw@cs.berkeley.edu, ipsec@lists.tislabs.com Subject: RE: MAC speeds Date: Mon, 20 Mar 2000 10:14:09 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What is the mathematical problem and proof that this MAC relies on? Thanks Chris -----Original Message----- From: daw@cs.berkeley.edu [mailto:daw@cs.berkeley.edu] Sent: 19 March 2000 15:14 To: ipsec@lists.tislabs.com Subject: Re: MAC speeds In article , Henry Spencer wrote: > On 14 Mar 2000, D. J. Bernstein wrote: > > Asking how much scrutiny a Wegman-Carter-type authentication system has > > received is like asking how much scrutiny counter mode has received: > > you're missing the point. The security is _provably_ as good as the > > encryption function you plug in. > > That just shifts the problem one step: how much scrutiny has that proof had? Lots. This particular proof is taught in (some/many) graduate theory classes, and is an especially simple one as well. For some proofs (especially lengthy, complex, recent, or obscure proofs), there are very good reasons to start asking questions like this, but the proof of security for Wegman-Carter-like authentication is not one of them. From owner-ipsec@lists.tislabs.com Mon Mar 20 04:31:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26683; Mon, 20 Mar 2000 04:31:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15667 Mon, 20 Mar 2000 06:13:09 -0500 (EST) Message-ID: <9306F7F390AED11195DF400689242999E4AD93@smtp.vie.travi.com> From: Strohmayer Peter Hans -BTT To: "'ipsec@lists.tislabs.com'" Subject: ipsec and masquerading Date: Mon, 20 Mar 2000 12:19:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, first, i'm new in this list. I've the following configuration: I want to make a connection from windows with ipsec client made by Cisco over my Linuxmachine, which makes IP-Masquerading to the internet. On the other end there is a Cisco PIX Firewall, which should be the other end of the tunnel (1st is windows). I've compiled by Kernel (2.2.10 Suse 6.2) new with the PPTP-Patch from John Hardin, but i won't work right. What must i do? The IPsec runs with ESP..... Greetings Peter Ing. Peter Hans Strohmayer TraviAustria Dep: BTT / Access Products Phone: +43 - 1 / 1766 - 2958 Fax: +43 - 1 / 688 18 91 - 2958 (+43 - 1 / 1766 - 2929) Mail: mailto:peter.strohmayer@travi.com Web: http://www.travi.com PGP: 8BF9 9810 ECA8 2650 8114 511A 2D5E 422C 273A 71C7 From owner-ipsec@lists.tislabs.com Mon Mar 20 08:22:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA02167; Mon, 20 Mar 2000 08:22:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16370 Mon, 20 Mar 2000 09:51:24 -0500 (EST) Date: Fri, 17 Mar 2000 11:10:50 -0800 From: Rene Tio To: Raymond Hsu Cc: Gopal Dommety , tsgp@3gpp2.org, udlr@sophia.inria.fr, msdp@antc.uoregon.edu, ipsec@lists.tislabs.com, MOBILE-IP@standards.nortelnetworks.com, l2tp@ipsec.org, tsga@3gpp2.org Subject: Re: GRE Extensions (Modified) Message-ID: <20000317111050.B1078@redback.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200003171611.IAA17317@jittlov.qualcomm.com>; from rhsu@qualcomm.com on Fri, Mar 17, 2000 at 08:12:08AM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Mar 17, 2000 at 08:12:08AM -0800, Raymond Hsu wrote: > Hi Gopal: > > In TR-45.6's R-P interface (aka A10 interface), we may use the first option > in the direction > from the PDSN to the PCF. In this direction, we've identified scenarios > where some mobiles > require in-sequence delivery and some don't. Since each mobile is > identified by the Key field > over the R-P interface, we need option 1. However, in the direction from > the PCF to the PDSN, > we don't have a strong requirement per mobile basis; thus, option 2 is > adequate. Therefore, > my recommendation is that both options should be allowed in the GRE draft. I think if we plan the most limiting case (option 1, which we have at least a few opinions is necessary) and allow for the not-so-limiting, both cases will be covered. IMHO the C, K, and S fields are a request for the other end to check, not a requirement that the other end should send, i.e., if you configure a tunnel to have checksums, you send checksums but don't require the other end to send checksums (it's part of the "be liberal in what you receive" paradigm). Thus in the PCF to PDSN direction you just don't configure sequence numbers and everything Should Just Work. Cheers, Rene ps/ Funny how the PPTP draft is vague on this as well, or at least my quick glance did not find any statement on this matter. I don't think it would work if you didn't have a sequence number per key though, as one missed packet may cause you to turf packets across many PPP sessions. > Regards, > > Raymond Hsu > > At 01:06 AM 3/17/00 -0800, Gopal Dommety wrote: > >Hello: > > > >I have changed the sequence no to be 4 bytes. The changes request by > >most have been made. > > > >A remining issue is regarding the behaviour when both sequence no and > >the Key are present. There are two options: > > > >1. Have sequence no per Key. This will give better granularity with > > added complexity of implementation. > > > >2. Sequence no for the tunnel irrespective of the Key. > > > >Let me know your opinion. > > > >Thanks > >Gopal > > > > > >Network Working Group Gopal Dommety > >INTERNET DRAFT cisco Systems > >Category: Standards Track March 2000 > >Title: draft-dommety-gre-ext-01.txt > > > >Expires October 2000 > > > > Key and Sequence Number Extensions to GRE > > draft-dommety-gre-ext-01.txt > > > >Status of this Memo > > > > This document is a submission by the Network Working Group of the > > Internet Engineering Task Force (IETF). Comments should be submitted > > to the gre@ops.ietf.org mailing list. > > > > Distribution of this memo is unlimited. > > > > This document is an Internet Draft and is in full conformance with > > all provisions of Section 10 of RFC2026. Internet Drafts are working > > documents of the Internet Engineering Task Force (IETF), its areas, > > and working groups. Note that other groups may also distribute > > working documents as Internet Drafts. > > > > Internet Drafts are draft documents valid for a maximum of six months > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet Drafts as reference > > material or to cite them other than as "work in progress." > > > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt. > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > > > >Abstract > > > > This document describes extensions by which two fields, Key and > >Sequence Number, can be optionally carried in the GRE (Generic Routing > >Encapsulation) Header [1]. GRE specifies a protocol for encapsulation > >of an arbitrary network layer protocol over another arbitrary network > >layer protocol. > > > >Dommety [Page 1] > > > >Internet Draft Key and Sequence Number Extensions to GRE February 2000 > > > >1. Introduction > > > > Current specification of Generic Routing Encapsulation [1] specifies > >a protocol for encapsulation of an arbitrary network layer protocol > >over another arbitrary network layer protocol. This document describes > >enhancements by which two fields, Key and Sequence Number, can be > >optionally carried in the GRE Header [1]. The Key field is used to > >create separate sub-tunnels within a GRE Tunnel. Sequence Number field > >is used to maintain sequence of packets within a GRE Tunnel. > > > >1.1. Specification Language > > > > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > > this document are to be interpreted as described in RFC 2119 [3]. > > > > In addition, the following words are used to signify the > > requirements of the specification. > > > > Silently discard > > The implementation discards the datagram without > > further processing, and without indicating an error > > to the sender. The implementation SHOULD provide the > > capability of logging the error, including the contents > > of the discarded datagram, and SHOULD record the event > > in a statistics counter. > > > >2. Extensions to GRE Header > > > > The GRE packet header[1] has the following format: > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |C| Reserved0 | Ver | Protocol Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Checksum (optional) | Reserved1 (Optional) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > The proposed GRE header will have the following format: > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |C| |K|S| Reserved0 | Ver | Protocol Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Checksum (optional) | Reserved1 (Optional) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Key (optional) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Sequence Number (Optional) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Key Present (bit 2) > > > > If the Key Present bit is set to 1, then it indicates that the Key > > field is present in the GRE header. Otherwise, the Key field is > > not present in the GRE header. > > > > Sequence Number Present (bit 3) > > > > If the Sequence Number Present bit is set to 1, then it indicates > > that the Sequence Number field is present. Otherwise, the > > Sequence Number field is not present in the GRE header. > > > > The Key and Sequence Present bits are chosen to be compatible > > with RFC 1701 [2]. > > > >2.1. Key Field (4 octets) > > > > The Key field contains a four octet number which was inserted by > > the encapsulator. The actual method by which this Key is obtained > > is beyond the scope of this document. Key field is intended to be > > used for creating separate sub-tunnels within a GRE Tunnel and the > > Key field identifies the sub-tunnel. > > > >2.2. Sequence Number (4 octets) > > > > The Sequence Number field is a four byte feild and is inserted by > > the encapsulator when Sequence Number Present Bit is set. The > > Sequence Number MUST be used by the receiver to establish the > > order in which packets have been transmitted from the encapsulator > > to the receiver. The intended use of the Sequence Field is to > > provide unreliable and in-order delivery. If the Key present bit > > (bit 2) is set, the sequence number is specific to the sub-tunnel > > identified by the Key field. Note that packets without the sequence > > bit set can be sent in between packets with the sequence bit set. > > > > The sequence number value ranges from 1 to 2**32-1. The first > > datagram is sent with a sequence number of 1. The sequence > > number is thus a free running counter represented modulo 2**32, > > with the exception that 1 is used when modulo 2**32 results in 0 > > (i.e., rollover to 1 instead of 0). > > > > When the decapsulator receives an out-of sequence packet it SHOULD > > be silently discarded. Additionally, reordering of out-of sequence > > packets MAY be performed by the decapsulator for improved > > performance and tolerance to reordering in the network (since the > > state of the stateful compression or encryption is reset by packet > > loss, it might help the performance to tolerate some amount of > > packet reordering in the network by buffering). Exact buffering > > schemes are outside the scope of this document. Note that the > > sequence number is used to detect > > lost packets and/or restore the original sequence of packets that > > may have been reordered during transport. > > > > A packet is considered an out-of-sequence packet if the sequence > > number of the received packet is lesser than or equal to the > > sequence number of last successfully decapsulated > > packet. The sequence number of a received message is considered > > less than or equal to the last successfully received sequence number > > if its value lies in the range of the last received sequence number > > and the preceding 65534 values, inclusive. > > > > > > If the received packet is an in-sequence packet, it is > > successfully decapsulated. Note that the sequence number is used > > to detect lost packets and/or restore the original sequence of > > packets (with buffering) that may have been reordered during > > transport. Use of the sequence number option should be used > > appropriately; in particular, it is a good idea a avoid using when > > tunneling protocols that have higher layer in-order delivery > > mechanisms or are tolerant to out-of-order delivery. If only at certain > > instances the protocol being carried in the GRE tunnel requires > > in-sequence delivery, only the corresponding packets encapsulated > > in a GRE header can be sent with the sequence bit set. Mechanisims > > to determine which packets need to be sent in-sequence and the > > signaling mechanisims are outside the scope of this document. > > > > > > > > > >3. IANA Considerations > > > >4. Acknowledgments > > > > > >5. References > > > > [1] Farinacci, D., Li, T., Hnaks, S., Meyer, D. and Traina, P., > > "Generic Routing Encapsulation (GRE)," > > draft-meyer-gre-update-03.txt, January 2000. > > > > [2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic > > Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems, > > October 1994. > > > > [3] Bradner S., "Key words for use in RFCs to Indicate Requirement > > Levels", RFC 2119, March 1997. > > > > > >Dommety [Page 4] > > > >Internet Draft Key and Sequence Number extensions to GRE February 2000 > > > >Author Information > > > > Gopal Dommety > > Cisco Systems, Inc. > > 170 West Tasman Drive > > San Jose, CA 95134 > > e-mail: gdommety@cisco.com > > > >Dommety > > > > > > > > > > > >Thank You. > >Regards, > >Gopal > >--------------------------------------------------------------------------- > ---------------------------------- > > > >Gopal Dommety > >408 525 1404 > >gdommety@cisco.com > >Cisco Systems, San Jose, CA, 95051 > > > >--- > >You are currently subscribed to tsgp as: rhsu@qualcomm.com > > > From owner-ipsec@lists.tislabs.com Mon Mar 20 08:24:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA02228; Mon, 20 Mar 2000 08:23:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16367 Mon, 20 Mar 2000 09:51:22 -0500 (EST) Date: Sat, 18 Mar 2000 13:40:14 -0500 From: Jim Tiller X-Mailer: The Bat! (v1.36) S/N 569FD297 Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <17569.000318@lucent.com> To: IPSec IETF WorkGroup Subject: IKE Public Key Encryption Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello All, I know this has been discussed, and I attempted to find the previous discussion in the list archives - needless to say, I was unsuccessful. --------------------------Question--------------------- In the third message of MM with Public key authentication (non-revised shown - but same issue for both): Initiator Responder ----------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, [ HASH(1), ] PubKey_r, PubKey_r --> HDR, KE, PubKey_i, <-- PubKey_i HDR*, HASH_I --> <-- HDR*, HASH_R My question is about the use of HASH(1): "Where HASH(1) is the optional hash of the certificate which contained Pubkey_r." Shouldn't the [ HASH(1), ] be required? The responder may need to know which certificate/public key the initiator is using in the event several certificates are assigned to the responder. In some cases, if not included, wouldn't it pose a similar issue we see with shared secret authentication? In shared secret the password must be looked up by the initiator's IP address. Doesn't the same "issue" apply for the responder to determine which public key to use? I'm not insinuating that a public key is being used for each individual initiator, for argument sake lets say different networks have their own certificates. Nonetheless, how does the responder determine which key to use if several are maintained? I could provide some examples, but prefer to remain brief and I'm assured that this is not a new question and has been answered in the past - and with that note I do apologize for any repetition - and please provide the subject of the elusive previous discussions. Best regards, Jim From owner-ipsec@lists.tislabs.com Mon Mar 20 08:25:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA02256; Mon, 20 Mar 2000 08:25:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16312 Mon, 20 Mar 2000 09:49:20 -0500 (EST) Message-ID: <38D631D8.12DC9251@nomea.fr> Date: Mon, 20 Mar 2000 15:12:40 +0100 From: Abdelkader ALLAM Reply-To: aallam@nomea.fr Organization: Comparex France X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 To: Strohmayer Peter Hans -BTT CC: "'ipsec@lists.tislabs.com'" Subject: Re: ipsec and masquerading References: <9306F7F390AED11195DF400689242999E4AD93@smtp.vie.travi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA16125 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk check out FreeSWAN: http://www.xs4all.nl/~freeswan/ It should work better... Strohmayer Peter Hans -BTT a écrit : > Hi, > > first, i'm new in this list. > > I've the following configuration: > I want to make a connection from windows with ipsec client made by Cisco > over my Linuxmachine, which makes IP-Masquerading to the internet. > On the other end there is a Cisco PIX Firewall, which should be the other > end of the tunnel (1st is windows). > > I've compiled by Kernel (2.2.10 Suse 6.2) new with the PPTP-Patch from > John Hardin, but i won't work right. > > What must i do? > The IPsec runs with ESP..... > > Greetings > Peter > > Ing. Peter Hans Strohmayer > > TraviAustria > Dep: BTT / Access Products > Phone: +43 - 1 / 1766 - 2958 > Fax: +43 - 1 / 688 18 91 - 2958 > (+43 - 1 / 1766 - 2929) > Mail: mailto:peter.strohmayer@travi.com > Web: http://www.travi.com > PGP: 8BF9 9810 ECA8 2650 8114 511A 2D5E 422C 273A 71C7 From owner-ipsec@lists.tislabs.com Mon Mar 20 08:25:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA02283; Mon, 20 Mar 2000 08:25:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16297 Mon, 20 Mar 2000 09:48:49 -0500 (EST) Message-ID: <71984F8FB76AD211AC3E00A0C9C578C702158099@hasmsx32.iil.intel.com> From: "Elzur, Uri" To: ipsec@lists.tislabs.com Subject: Adelaide Agenda? Date: Sat, 18 Mar 2000 13:21:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry if this has been discussed before, but I've not seen any proposed agenda. What is the agenda for the Thu meeting? Thx Uri Elzur uri.elzur@intel.com From owner-ipsec@lists.tislabs.com Mon Mar 20 08:27:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA02374; Mon, 20 Mar 2000 08:27:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16420 Mon, 20 Mar 2000 09:53:02 -0500 (EST) Date: Mon, 20 Mar 2000 09:59:17 -0500 Message-Id: <200003201459.JAA22769@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipsec@lists.tislabs.com Subject: RE: AES draft query References: <852568A5.0083390E.00@smtpmail.certicom.com> <4.3.2.20000317190722.00c2e410@mail.vpnc.org> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Hoffman writes: Paul> At 03:54 PM 3/17/00 -0800, John Harleman wrote: >> absolutely correct. but there is also 2 key 3des. Not in IPSEC, there isn't. I'm not sure what 2key 3des has to do with the aes discussion... >> as schneier and >> whiting recently pointed out: >> >> http://www.counterpane.com/aes-comparison.html >> >> key size is increased at the cost of performance with all AES >> canidates. So why would one use larger strength AES algorithms >> without using the corresponding strength with public-key? cheers - >> john Paul> There could be many reasons. Some might include: - due to your Paul> hardware accelerator, 128->256 AES might only cost you 50% more Paul> time but the corresponding increase in public key might cost Paul> you 200% - the other party only offered you one AES length but Paul> many acceptable choices for public key lengths There are Paul> probably others. The baseline decision is "are both the Paul> symmetric and asymmetric keys strong enough for what I want?" Paul> If the answer is yes, it does not matter if there is a mismatch Paul> in strength. I think that's a very good way to look at things. AES has the nice property that it is (believed to be) much more secure than the previous state of the art, at similar performance. And in particular, it is both more secure *and faster* than 3DES, the predominant high security cipher deployed right now. While from a theoretical point of view it is best to match the security of the public/DH and symmetric algorithms, that's only barely affordable for 128 bit keys and really problematic with longer keys. (Then again, it isn't clear why someone would choose symmetric keys longer than 128 at this time. A few years from now, possibly yes.) I would answer John's question with "because we can't afford to take 10 seconds or so to do a single D-H key agreement!" Deployable systems must have acceptable performance as well as acceptable security. paul From owner-ipsec@lists.tislabs.com Mon Mar 20 09:56:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03805; Mon, 20 Mar 2000 09:56:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16858 Mon, 20 Mar 2000 11:17:54 -0500 (EST) From: pau@watson.ibm.com Date: Mon, 20 Mar 2000 11:25:12 -0500 Message-Id: <0003201625.AA24910@secpwr.watson.ibm.com> To: ipsec@lists.tislabs.com, jtiller@lucent.com Subject: Re: IKE Public Key Encryption Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: lblmsZA8p+ZLr9iRXwl2NA== Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > Hello All, > > I know this has been discussed, and I attempted to find the previous > discussion in the list archives - needless to say, I was unsuccessful. > --------------------------Question--------------------- > In the third message of MM with Public key authentication > (non-revised shown - but same issue for both): > > Initiator Responder > ----------- ----------- > HDR, SA --> > <-- HDR, SA > HDR, KE, [ HASH(1), ] > PubKey_r, > PubKey_r --> > HDR, KE, PubKey_i, > <-- PubKey_i > HDR*, HASH_I --> > <-- HDR*, HASH_R > > My question is about the use of HASH(1): > > "Where HASH(1) is the optional hash of the certificate which > contained Pubkey_r." > > Shouldn't the [ HASH(1), ] be required? I would agree. At least our own experience showed that this makes it much less ambiguous. Pau-Chen > > .......... > > Best regards, > Jim > > > > > From owner-ipsec@lists.tislabs.com Mon Mar 20 10:46:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05013; Mon, 20 Mar 2000 10:46:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17199 Mon, 20 Mar 2000 12:16:49 -0500 (EST) Date: Mon, 20 Mar 2000 12:22:29 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: IKE Public Key Encryption In-Reply-To: <0003201625.AA24910@secpwr.watson.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In the third message of MM with Public key authentication... > "Where HASH(1) is the optional hash of the certificate which > contained Pubkey_r." > Shouldn't the [ HASH(1), ] be required? Public keys aren't necessarily obtained from certificates. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 20 12:29:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07004; Mon, 20 Mar 2000 12:29:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17623 Mon, 20 Mar 2000 14:07:59 -0500 (EST) Message-ID: <38D6791A.7AD8F6A8@redcreek.com> Date: Mon, 20 Mar 2000 11:16:42 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: akrywani@newbridge.com CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available References: <001401bf9076$334984a0$1e0101c8@ANDREWK2.TIMESTEP> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy Andrew, In general, I am proposing a philosophy of "configure it if you want it, don't negotiate it". More comments interspersed. Andrew Krywaniuk wrote: > > > If the working group so feels, we could radify several > > heartbeat/keepalive mechanisms. In that case Andrew's/Tero's and my > > proposals are not competative. But if we think that is unweildy, or we > > are just too lazy and we only want one recommended keepalive > > mechanism, > > then choose your side or make up a new one and say your piece. > > Hi Ricky, > > Even though Tero and I were both amenable to the concept of phase 2 > heartbeats, we thought it was more important to encourage interoperability > by keeping the number of standardized configuration options low. You make a respectable point. The "just ping it" solution does require configuration to "do heartbeats". But the ping in band in phase 2 idea requires no extra implementation. Heartbeats could be specified in a "best current practice" draft. And this is the salient point of distinction between our proposals. Add a new option negotiating protocol which will could reduce configuration simplicity to "propose or don't propose heartbeats", or accept the confituration burden across mulitple vendors systems to allow in-band heartbeat pings and send the pings. > > Your proposal is indeed simple, but it requires knowledge about the peer's > configuration that you should not assume. (I notice that you made no mention > of a negotiation phase.) The peer may not want you to send traffic on a > hijacked SA, therefore it would be inappropriate to do so unless this was > negotiated (along with the various session parameters). That's correct. Doing pings inside of a Phase 2 SA requires both peers to be configured to allow the traffic. Personally, for keepalive traffic, I think that explicit manual configuration is preferable to an option negotiation protocol. > > Unfortunately, for the reasons I mentioned previously, some implementations > would be unable to use your method. This makes it unsuitable for use as an > interoperability mode. Not so. Previously you mentioned that a peer may not want to allow the management traffic. While this is always a viable choice for a secrurity gateway, it does not imply that some implementations would be unable to allow management traffic. My proposal specifically says if you want the keepalives, you need to configure appropriate selectors on the security gateways. Any complient implementation would have no trouble adding selectors. > > I don't see how you could fix this problem without, for example, requiring > that all IPsec SAs terminating at the public IP of the sgw be classified as > management SAs (with implied policy holes, accounting rules, and exemption > from inactivity timeouts). Unfortunately, I don't think the vendors already > sending L2TP traffic on this channel would play along. Configure it if you want it. Require nothing. > > There is a stipulation in the draft that new heartbeat types can be added, > but only if there is a clear need for a feature that cannot be provided by > the existing protocol. So if there is an essential need for a phase 2 > heartbeat then we can add it to the draft later. The arguments I am making are that adding a new option negotiating protocol is too complex for this problem and using phase 1 SAs to verify the integrity of phase 2 SAs is needlesly indirect and unreliable. I therefore will refrain from extenting your proposal. (But thanks for offering :-) > > What we are trying to avoid here is the case where implementers feel > compelled to support each of the bajillion different heartbeat formats that > we had to add to the draft because we were trying to cater to every > individual. I hear you. And I do respect and concure with this goal. And (let's be realistic here) this goal forces our proposals into competing with each other for the mind share of this WG. And maybe there are still yet other ideas out there which have yet to be voiced. I ardently hope that our WG can come away from this IETF with a unified intended direction toward a keepalive solution. But I expect that both you and I are in for a round of abuse for not having done a "requirements document" first. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Mon Mar 20 12:30:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07020; Mon, 20 Mar 2000 12:30:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17580 Mon, 20 Mar 2000 14:06:39 -0500 (EST) Date: 20 Mar 2000 16:23:56 -0000 Message-ID: <20000320162356.22230.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipsec@lists.tislabs.com Subject: Re: MAC speeds References: <1FD60AE4DB6CD2118C420008C74C27B854A02E@baltimore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chris Trobridge writes: > What is the mathematical problem and proof that this MAC relies on? The security proof for Wegman-Carter MACs is absolute. It doesn't assume that some problem is hard to solve. It merely assumes that the sender and receiver share a long enough secret uniform random string. Here's a simple example. Say messages are strings over a field F of size 2^128. For any element r of F, define h_r(m_0,m_1,...,m_{l-1}) as r^{l+1} + m_0 r^l + m_1 r^{l-1} + ... + m_{l-1} r. The sender and receiver share secret independent uniform random elements r,k_1,k_2,...,k_N of F, where N is the number of messages. The sender transmits the nth message m_n as (n,m_n,h_r(m_n)+k_n). The receiver discards (n',m',s') unless s' = h_r(m') + k_{n'}. It's easy to prove that an adaptive chosen-plaintext attack on this system that tries D forgeries has probability at most D(L+1)/2^128 of fooling the receiver, if the maximum message length is L. The point is that, for any distinct messages m and m', and for any c in F, there are at most L+1 choices of r such that h_r(m) - h_r(m') = c. Variants: * You can use any hash function in place of h_r. The security of the system depends on the collision probability of the hash function. See section 10 of http://cr.yp.to/papers.html#hash127 for a survey. * You can hide the output of the hash function with an encryption function other than a one-time pad. The security of the system depends on the security of the encryption. For example, NMAC-MD5 and HMAC-MD5 can be viewed as systems of this type, with MD5(r,...) as the hash function, MD5(k,...) as the encryption function, and various methods of generating r and k. There's no proof that MD5(r,...) has low collision probability, but we think it does. On the other hand, MD5(r,...) is slower than the state of the art in 128-bit hash functions, and the lack of a nonce in MD5(k,...) means that the forgery probability grows quadratically with the number of messages. ---Dan From owner-ipsec@lists.tislabs.com Mon Mar 20 12:32:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07077; Mon, 20 Mar 2000 12:32:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17579 Mon, 20 Mar 2000 14:06:38 -0500 (EST) Message-Id: <38D642DC.8DD9ABF2@lucent.com> Date: Mon, 20 Mar 2000 10:25:16 -0500 From: Eric Bomarsi Organization: lucent.com X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: ipsec@lists.tislabs.com Subject: INTERNAL_SUBNET in draft-ietf-ipsec-isakmp-mode-cfg-05 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Why is the INTERNAL_IP4_SUBNET attribute in draft-ietf-ipsec-isakmp-mode-cfg-05 limited to a length of 4 octets? INTERNAL_IP4_SUBNET 13 Variable 0 or 4 octets The example implies 8 octets which makes sense. ATTR2(REPLY) = INTERNAL_ADDRESS(192.168.219.202) INTERNAL_NETMASK(255.255.255.0) INTERNAL_SUBNET(291.168.219.0/255.255.255.0) I don't want to apply the INTERNAL_NETMASK to all the INTERNAL_SUBNETs because that would assume all subnets to be the same size. Thanks /eb From owner-ipsec@lists.tislabs.com Mon Mar 20 12:35:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07139; Mon, 20 Mar 2000 12:35:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17581 Mon, 20 Mar 2000 14:06:39 -0500 (EST) Date: Mon, 20 Mar 2000 14:01:20 -0500 From: Jim Tiller X-Mailer: The Bat! (v1.36) S/N 569FD297 Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <8584.000320@lucent.com> To: pau@watson.ibm.com CC: ipsec@lists.tislabs.com Subject: Re: IKE Public Key Encryption In-reply-To: <0003201625.AA24910@secpwr.watson.ibm.com> References: <0003201625.AA24910@secpwr.watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thankx for answering... Is this becoming common practise for most vendors? Although optional, are most including it to avoid complexity and ambiguity? I'm certain this has come up in the VPNC and interpretability seminars. Also, one more question, if it is a certificate, why hash it? I'm assuming to reduce the size of the payload, but this comes at a cost of processing when the responder is responsible for many certificates. I might add that I'm assuming alot here and just expressing my curiosity to the group. thankx -jim Monday, March 20, 2000, 11:25:12 AM, you wrote: pwic> I would agree. At least our own experience showed that this makes pwic> it much less ambiguous. pwic> Pau-Chen From owner-ipsec@lists.tislabs.com Mon Mar 20 13:20:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07706; Mon, 20 Mar 2000 13:20:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17906 Mon, 20 Mar 2000 15:00:58 -0500 (EST) Date: Mon, 20 Mar 2000 14:44:18 -0500 From: Jim Tiller X-Mailer: The Bat! (v1.36) S/N 569FD297 Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <12614.000320@lucent.com> To: Henry Spencer CC: IP Security List Subject: Re: IKE Public Key Encryption In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Henry, Yes - very true, and I eluded to that in a response I sent Pau-Chen, in that I was assuming certificates - but the RFC does say "certificates", so I stuck with that. Although, I completely agree with your statement, however, the same issue does apply - how does the responder know which private key to use? Thankx for responding! -jim Monday, March 20, 2000, 12:22:29 PM, you wrote: >> In the third message of MM with Public key authentication... >> "Where HASH(1) is the optional hash of the certificate which >> contained Pubkey_r." >> Shouldn't the [ HASH(1), ] be required? HS> Public keys aren't necessarily obtained from certificates. HS> Henry Spencer HS> henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Mar 20 13:57:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08426; Mon, 20 Mar 2000 13:57:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18137 Mon, 20 Mar 2000 15:39:29 -0500 (EST) Message-Id: <200003202042.MAA02747@potassium.network-alchemy.com> To: Jim Tiller cc: pau@watson.ibm.com, ipsec@lists.tislabs.com Subject: Re: IKE Public Key Encryption In-reply-to: Your message of "Mon, 20 Mar 2000 14:01:20 EST." <8584.000320@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2744.953584967.1@network-alchemy.com> Date: Mon, 20 Mar 2000 12:42:47 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is only ambiguity when the responder has more than one public key. If that's the case then the hash will indicate which one to use and get rid of the ambiguity. I've done interoperability testing with this authentication method before but each time the peer only had one public key. It's hashed to retain identity protection which is a feature of Main Mode. Dan. On Mon, 20 Mar 2000 14:01:20 EST you wrote > Thankx for answering... > > Is this becoming common practise for most vendors? Although optional, > are most including it to avoid complexity and ambiguity? I'm certain > this has come up in the VPNC and interpretability seminars. > > Also, one more question, if it is a certificate, why hash it? I'm > assuming to reduce the size of the payload, but this comes at a cost > of processing when the responder is responsible for many certificates. > I might add that I'm assuming alot here and just expressing my > curiosity to the group. > > thankx > -jim > > Monday, March 20, 2000, 11:25:12 AM, you wrote: > > pwic> I would agree. At least our own experience showed that this makes > pwic> it much less ambiguous. > > pwic> Pau-Chen > > > > From owner-ipsec@lists.tislabs.com Mon Mar 20 14:56:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09275; Mon, 20 Mar 2000 14:56:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA18258 Mon, 20 Mar 2000 16:05:47 -0500 (EST) From: pau@watson.ibm.com Date: Mon, 20 Mar 2000 16:13:16 -0500 Message-Id: <0003202113.AA25672@secpwr.watson.ibm.com> To: jtiller@lucent.com Subject: Re: IKE Public Key Encryption Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: ecZoIfSudblh/MI4t5zbCQ== Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From jtiller@lucent.com Mon Mar 20 14:03:39 2000 > Date: Mon, 20 Mar 2000 14:01:20 -0500 > From: Jim Tiller > X-Mailer: The Bat! (v1.36) S/N 569FD297 > Reply-To: Jim Tiller > Organization: Lucent > X-Priority: 3 (Normal) > Message-Id: <8584.000320@lucent.com> > To: pau@watson.ibm.com > Cc: ipsec@lists.tislabs.com > Subject: Re: IKE Public Key Encryption > In-Reply-To: <0003201625.AA24910@secpwr.watson.ibm.com> > References: <0003201625.AA24910@secpwr.watson.ibm.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Content-Length: 702 > Status: RO > > Thankx for answering... > > Is this becoming common practise for most vendors? Although optional, I am not sure if this has become common practice. > are most including it to avoid complexity and ambiguity? I'm certain It is meant to avoid ambiguity. Dan pointed out that ambiguity only exists if the responder has more than one public key. I would submit that in general the initiator cannot be sure about that the responder has only one public key suitable for this usage (key encryption). > this has come up in the VPNC and interpretability seminars. > > Also, one more question, if it is a certificate, why hash it? I'm > assuming to reduce the size of the payload, but this comes at a cost > of processing when the responder is responsible for many certificates. > I might add that I'm assuming alot here and just expressing my > curiosity to the group. It is meant to preserve anonymity. Pau-Chen > > thankx > -jim > > Monday, March 20, 2000, 11:25:12 AM, you wrote: > > pwic> I would agree. At least our own experience showed that this makes > pwic> it much less ambiguous. > > pwic> Pau-Chen > > > From owner-ipsec@lists.tislabs.com Mon Mar 20 19:04:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA20953; Mon, 20 Mar 2000 19:04:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19284 Mon, 20 Mar 2000 19:43:03 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Hoffman'" , Subject: RE: AES draft query Date: Mon, 20 Mar 2000 19:56:21 -0500 Message-Id: <001d01bf92d0$46cf3220$1e0101c8@ANDREWK2.TIMESTEP> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <4.3.2.20000318073338.04ed99f0@mail.vpnc.org> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > A user who is smart enough to answer that question correctly is smart > enough to know that increasing the size of one key at a > different rate than > the other key is not going to get a balanced increase in security. > > Of course, it is the rare IPsec user who understands this > concept, and most > go by "I hear 128 is enough" and, unfortunately, "I hear 256 > is better than > 128 and my security gateway still seems to run fast so I'll > use 256". This > can be countered with education, to the somewhat limited extent that > education about security has been successful. Hi Paul, There seems to be an implicit assumption here that users will be tweaking the format of the SA proposals themselves and that they will decide between 128 bit AES and 256 bit AES. I don't think this is realistic. In 90% of the cases, the users will use whatever set of transforms we include as a pre-configured part of the product (caveat emptor). In the other 10% of the cases, the users had better understand what they are doing before they frig with the crypto setup. In other words, they should get outside advice from a knowledgeable security consultant. Of course, there will be users who base their decisions on magazine reviews, which can be misleading. Maybe the VPNC can help out here, by educating the reviewers and ensuring that they do their performance comparisons using an appropriate set of transforms. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman > Sent: Saturday, March 18, 2000 10:51 AM > To: ipsec@lists.tislabs.com > Subject: Re: AES draft query > > > At 10:05 PM 3/17/00 -0800, EKR wrote: > >I disagree with this position, for two reasons: > > It's not a "position", it's an explanation about why the > situation might > happen. > > >1. It's inefficient from a design perspective. Why incur additional > >performance costs if they don't add any security value? Even > >if the cost is only 50%, why pay it if it's not adding anything. > > This is technically correct, but irrelevant. Unless we > mandate that "if you > use AES-128, you MUST only use public keys of exactly 2056 > bits and nothing > else", the mismatch will continue to happen. This is > particularly true > between two parties who have looked at different numbers for > the equivalent > strengths of symmetric and asymmetric keys and come to different > conclusions. The numbers that Hilarie and I came up with > differ from other > numbers being proposed because we used different assumptions > about the future. > > >2. It's very confusing to users, who expect security to increase > >with increasing key size. > > Disagree. The statement I made was: > > > The baseline decision is "are both the symmetric > > and asymmetric keys strong enough for what I want?" > > A user who is smart enough to answer that question correctly is smart > enough to know that increasing the size of one key at a > different rate than > the other key is not going to get a balanced increase in security. > > Of course, it is the rare IPsec user who understands this > concept, and most > go by "I hear 128 is enough" and, unfortunately, "I hear 256 > is better than > 128 and my security gateway still seems to run fast so I'll > use 256". This > can be countered with education, to the somewhat limited extent that > education about security has been successful. > > --Paul Hoffman, Director > --VPN Consortium > > From owner-ipsec@lists.tislabs.com Mon Mar 20 19:10:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA21221; Mon, 20 Mar 2000 19:10:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19345 Mon, 20 Mar 2000 19:51:30 -0500 (EST) Message-Id: <4.3.2.20000320165332.00a99a00@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 20 Mar 2000 16:57:42 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: RE: AES draft query In-Reply-To: <001d01bf92d0$46cf3220$1e0101c8@ANDREWK2.TIMESTEP> References: <4.3.2.20000318073338.04ed99f0@mail.vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 07:56 PM 3/20/00 -0500, Andrew Krywaniuk wrote: >There seems to be an implicit assumption here that users will be tweaking >the format of the SA proposals themselves and that they will decide between >128 bit AES and 256 bit AES. Correct. The products I have seen all allow this. Some allow it more easily than others, and some use terms like "medium" and "high" instead of "80" and "128". >I don't think this is realistic. In 90% of the cases, the users will use >whatever set of transforms we include as a pre-configured part of the >product (caveat emptor). That would be wonderful if it is true. If you're correct about the 90% number, it would be interesting to see how many/few users tweak beyond the defaults. Of course, it would be interesting to see what each product's defaults are. At that point, it would be easy to tell during interop testing if a product had reasonable settings by looking at the offers. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Mar 21 05:58:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA27621; Tue, 21 Mar 2000 05:58:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA21316 Tue, 21 Mar 2000 06:42:01 -0500 (EST) Date: Tue, 21 Mar 2000 06:52:09 -0500 Message-Id: <200003211152.GAA06935@trampoline.thunk.org> To: uri.elzur@intel.com CC: ipsec@lists.tislabs.com In-reply-to: <71984F8FB76AD211AC3E00A0C9C578C702158099@hasmsx32.iil.intel.com> (uri.elzur@intel.com) Subject: Re: Adelaide Agenda? From: tytso@mit.edu Phone: (781) 391-3464 References: <71984F8FB76AD211AC3E00A0C9C578C702158099@hasmsx32.iil.intel.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: "Elzur, Uri" Date: Sat, 18 Mar 2000 13:21:07 -0800 Sorry if this has been discussed before, but I've not seen any proposed agenda. What is the agenda for the Thu meeting? Here's the agenda that I've collected to date. If someone else has something that they would like to present, please let me know. I note that we don't have yet have a presentation from the MIB work. Are any of the MIB I-D authors planning to be at Adelaide? - Ted title="Agenda Bashing" presentor="Ts'o" time=5 do_event title="RFC and ID status" presentor="Ts'o" time=5 do_event title="SCTP and IPSEC" presentor="Steven M. Bellovin" time=10 do_event title="Public key sizes" presentor="Hilarie Orman" time=10 do_event title="AES Encryption Draft" presentor="Scott G. Kelly" time=10 do_event title="IPSEC Heartbeats" presentor="Andrew Krywaniuk" time=10 do_event title="Revised Authentication Hash" presentor="Tero Kivinen" time=10 do_event title="Alternate Use of IPSEC for Virtual Networks" presentor="Joe Touch" time=10 do_event title="TAHI IPsec conformance test suites" presentor="Hiroshi Hoshino" time=10 do_event From owner-ipsec@lists.tislabs.com Tue Mar 21 09:10:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01252; Tue, 21 Mar 2000 09:10:56 -0800 (PST) From: owner-ipsec@lists.tislabs.com Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21659 Tue, 21 Mar 2000 08:55:17 -0500 (EST) Date: Tue, 21 Mar 2000 08:55:17 -0500 (EST) Message-Id: <200003211355.IAA21659@lists.tislabs.com> with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H1FW48L1; Mon, 20 Mar 2000 15:28:57 -0600 Date: Mon, 20 Mar 2000 16:28:15 -0500 From: Jim Tiller X-Mailer: The Bat! (v1.36) S/N 569FD297 Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <18686.000320@lucent.com> To: Dan Harkins CC: pau@watson.ibm.com, ipsec@lists.tislabs.com Subject: Re[2]: IKE Public Key Encryption In-reply-To: <200003202042.MAA02747@potassium.network-alchemy.com> References: <200003202042.MAA02747@potassium.network-alchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk DH> There is only ambiguity when the responder has more than one public DH> key. If that's the case then the hash will indicate which one to use and DH> get rid of the ambiguity. Completely understood, however, how does the initiator know to send the HASH to accommodate the responder? Hence - should it be included by default? DH> I've done interoperability testing with this DH> authentication method before but each time the peer only had one public DH> key. Yep - you nailed it:)... I should add that I have only tested with a single key pair. But once I began to apply multiple certificates the point came quite clear. If the initiator does not send the HASH, the responder is out of luck in decrypting the messages unless all keys are tried - but success is only known until the ID payload is parsed and is deemed unintelligible. Given this conversation...should it be mandatory? (as much as I would hate to reduce options) DH> It's hashed to retain identity protection which is a feature of Main DH> Mode. Pau-Chen reminded me too... I feel a bit silly. As soon as I hit the 'send' button I realized what a stupid question. Thanks or reminding me and not bashing me :) Which I deserved, I knew better - - very obvious. -jim DH> Dan. DH> On Mon, 20 Mar 2000 14:01:20 EST you wrote >> Thankx for answering... >> >> Is this becoming common practise for most vendors? Although optional, >> are most including it to avoid complexity and ambiguity? I'm certain >> this has come up in the VPNC and interpretability seminars. >> >> Also, one more question, if it is a certificate, why hash it? I'm >> assuming to reduce the size of the payload, but this comes at a cost >> of processing when the responder is responsible for many certificates. >> I might add that I'm assuming alot here and just expressing my >> curiosity to the group. >> >> thankx >> -jim >> >> Monday, March 20, 2000, 11:25:12 AM, you wrote: >> >> pwic> I would agree. At least our own experience showed that this makes >> pwic> it much less ambiguous. >> >> pwic> Pau-Chen >> >> >> >> From owner-ipsec@lists.tislabs.com Tue Mar 21 09:23:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01519; Tue, 21 Mar 2000 09:23:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21785 Tue, 21 Mar 2000 09:06:20 -0500 (EST) Message-ID: <38D782C8.69367052@cisco.com> Date: Tue, 21 Mar 2000 09:10:17 -0500 From: Stephane Beaulieu Reply-To: @cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Bomarsi CC: ipsec@lists.tislabs.com, royp@cisco.com Subject: Re: INTERNAL_SUBNET in draft-ietf-ipsec-isakmp-mode-cfg-05 References: <38D642DC.8DD9ABF2@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Eric, It's an error. Roy was suppose to fix this... Eric Bomarsi wrote: > Why is the INTERNAL_IP4_SUBNET attribute in draft-ietf-ipsec-isakmp-mode-cfg-05 > limited to a length of 4 octets? > > INTERNAL_IP4_SUBNET 13 Variable 0 or 4 octets > > The example implies 8 octets which makes sense. > > ATTR2(REPLY) = > INTERNAL_ADDRESS(192.168.219.202) > INTERNAL_NETMASK(255.255.255.0) > INTERNAL_SUBNET(291.168.219.0/255.255.255.0) > > I don't want to apply the INTERNAL_NETMASK to all the INTERNAL_SUBNETs because > that would assume all subnets to be the same size. > > Thanks > /eb From owner-ipsec@lists.tislabs.com Tue Mar 21 14:53:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07208; Tue, 21 Mar 2000 14:53:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22413 Tue, 21 Mar 2000 12:06:11 -0500 (EST) Message-ID: <310508EDF557D31188FA0050DA0A37522CC0FC@CAT01S2> From: Tim Jenkins To: "'tytso@mit.edu'" Cc: ipsec@lists.tislabs.com Subject: RE: Adelaide Agenda? Date: Tue, 21 Mar 2000 11:51:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: tytso@mit.edu [mailto:tytso@mit.edu] > Sent: Tuesday, March 21, 2000 6:52 AM > To: uri.elzur@intel.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Adelaide Agenda? > ... > I note that we don't have yet have a presentation from the MIB work. > Are any of the MIB I-D authors planning to be at Adelaide? No, I'm not and I believe John will not be there either. > > - Ted Tim From owner-ipsec@lists.tislabs.com Tue Mar 21 15:22:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07592; Tue, 21 Mar 2000 15:22:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22646 Tue, 21 Mar 2000 13:02:14 -0500 (EST) Date: Tue, 21 Mar 2000 13:07:47 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: IKE Public Key Encryption In-Reply-To: <200003211355.IAA21659@lists.tislabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > But once I began to apply multiple certificates the point came quite > clear. If the initiator does not send the HASH, the responder is out > of luck in decrypting the messages unless all keys are tried... [and > it's hard to decide whether a try is successful] > Given this conversation...should it be mandatory? Only if there is a well-defined convention for what it means in the case where no certificates are involved, or if the mandatory-ness is only in the certificate case. One major reason for making things optional is so they can be omitted when they do not make sense. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Mar 21 15:47:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07885; Tue, 21 Mar 2000 15:47:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23307 Tue, 21 Mar 2000 16:32:10 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Ricky Charlet'" Cc: Subject: RE: Heartbeats draft available Date: Tue, 21 Mar 2000 16:45:15 -0500 Message-Id: <003601bf937e$bf080740$1e0101c8@ANDREWK2.TIMESTEP> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <38D6791A.7AD8F6A8@redcreek.com> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Ricky, Yet again, the complexity argument rears its ugly head. If you've been following the previous discussion on this topic, I hope you understand why I do not believe that measuring complexity is as simple as merely counting the number of bits (or payloads or messages) on the wire. Sending more messages can often help to eliminate uncertainty. In fact, one of the best ways to reduce complexity is to tell the peer exactly what you are going to do before you do it. I can give you lots of examples where the lack of negotiation has made interoperability difficult. Take rekeying for example. Other examples are available upon request. Anyway, I really don't think it matters whether we do heartbeats in phase 1 or phase 2. That wasn't a requirement of my protocol. On the other hand, providing a negotiation protocol was a definite requirement. The negotiation protocol was specifically designed to be simple. Currently, the negotiation protocol defines two options and one parameter. The syntax of the negotiation is clear and there is no interaction between the fields. The draft also explicitly spells out which peer has the final decision regarding each field. The information is agreed on with minimal complexity because there is no ambiguity. BTW, I do not believe this feature is large enough to warrant a separate requirements draft. However, if you want a list of requirements, read sections 3 and 4 of the draft. Also, if you want to see a list of features/services which may not interoperate with your non-negotiated heartbeats proposal, I will prepare one in time for Adelaide. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: rcharlet@newbridge.com > [mailto:rcharlet@newbridge.com]On Behalf Of > Ricky Charlet > Sent: Monday, March 20, 2000 2:17 PM > To: akrywani@newbridge.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Heartbeats draft available > > > Howdy Andrew, > > In general, I am proposing a philosophy of "configure > it if you want > it, don't negotiate it". More comments interspersed. > > > Andrew Krywaniuk wrote: > > > > > If the working group so feels, we could radify several > > > heartbeat/keepalive mechanisms. In that case > Andrew's/Tero's and my > > > proposals are not competative. But if we think that is > unweildy, or we > > > are just too lazy and we only want one recommended keepalive > > > mechanism, > > > then choose your side or make up a new one and say your piece. > > > > Hi Ricky, > > > > Even though Tero and I were both amenable to the concept of phase 2 > > heartbeats, we thought it was more important to encourage > interoperability > > by keeping the number of standardized configuration options low. > > > You make a respectable point. The "just ping it" > solution does require > configuration to "do heartbeats". But the ping in band in phase 2 idea > requires no extra implementation. Heartbeats could be specified in a > "best current practice" draft. And this is the salient point of > distinction between our proposals. Add a new option > negotiating protocol > which will could reduce configuration simplicity to "propose or don't > propose heartbeats", or accept the confituration burden > across mulitple > vendors systems to allow in-band heartbeat pings and send the pings. > > > > > Your proposal is indeed simple, but it requires knowledge > about the peer's > > configuration that you should not assume. (I notice that > you made no mention > > of a negotiation phase.) The peer may not want you to send > traffic on a > > hijacked SA, therefore it would be inappropriate to do so > unless this was > > negotiated (along with the various session parameters). > > > That's correct. Doing pings inside of a Phase 2 SA > requires both peers > to be configured to allow the traffic. Personally, for keepalive > traffic, I think that explicit manual configuration is > preferable to an > option negotiation protocol. > > > > > Unfortunately, for the reasons I mentioned previously, some > implementations > > would be unable to use your method. This makes it > unsuitable for use as an > > interoperability mode. > > Not so. Previously you mentioned that a peer may not > want to allow the > management traffic. While this is always a viable choice for > a secrurity > gateway, it does not imply that some implementations would be > unable to > allow management traffic. My proposal specifically says if > you want the > keepalives, you need to configure appropriate selectors on > the security > gateways. Any complient implementation would have no trouble adding > selectors. > > > > > I don't see how you could fix this problem without, for > example, requiring > > that all IPsec SAs terminating at the public IP of the sgw > be classified as > > management SAs (with implied policy holes, accounting > rules, and exemption > > from inactivity timeouts). Unfortunately, I don't think the > vendors already > > sending L2TP traffic on this channel would play along. > > > Configure it if you want it. Require nothing. > > > > > There is a stipulation in the draft that new heartbeat > types can be added, > > but only if there is a clear need for a feature that cannot > be provided by > > the existing protocol. So if there is an essential need for > a phase 2 > > heartbeat then we can add it to the draft later. > > > The arguments I am making are that adding a new option > negotiating > protocol is too complex for this problem and using phase 1 > SAs to verify > the integrity of phase 2 SAs is needlesly indirect and unreliable. I > therefore will refrain from extenting your proposal. (But thanks for > offering :-) > > > > > > What we are trying to avoid here is the case where implementers feel > > compelled to support each of the bajillion different > heartbeat formats that > > we had to add to the draft because we were trying to cater to every > > individual. > > I hear you. And I do respect and concure with this > goal. And (let's be > realistic here) this goal forces our proposals into competing > with each > other for the mind share of this WG. And maybe there are > still yet other > ideas out there which have yet to be voiced. I ardently hope > that our WG > can come away from this IETF with a unified intended > direction toward a > keepalive solution. But I expect that both you and I are in > for a round > of abuse for not having done a "requirements document" first. > > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > From owner-ipsec@lists.tislabs.com Tue Mar 21 16:56:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08863; Tue, 21 Mar 2000 16:56:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23688 Tue, 21 Mar 2000 18:39:52 -0500 (EST) Message-ID: <38D80A43.A19B2F67@redcreek.com> Date: Tue, 21 Mar 2000 15:48:19 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: akrywani@newbridge.com CC: "'Ricky Charlet'" , ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available References: <003601bf937e$bf080740$1e0101c8@ANDREWK2.TIMESTEP> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk wrote: > > Anyway, I really don't think it matters whether we do heartbeats in phase 1 > or phase 2. That wasn't a requirement of my protocol. On the other hand, > providing a negotiation protocol was a definite requirement. Whether "heartbeats" are sent in a phase 1 or phase 2 SA, they are essentially a feature of the SA. Features of SAs are currently configured (and negotiated) using SA attributes. Why would these be any different? Scott From owner-ipsec@lists.tislabs.com Tue Mar 21 18:22:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12624; Tue, 21 Mar 2000 18:22:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24062 Tue, 21 Mar 2000 20:08:05 -0500 (EST) Message-ID: <38D81ECE.6FE213B@storm.ca> Date: Tue, 21 Mar 2000 20:15:58 -0500 From: Sandy Harris X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Announcing X-Bone VPN/overlay software release References: <200003172220.OAA07373@boreas.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe Touch wrote: > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > x x > x XX XX X-BONE Overlay System x > x X X x > x XX Software Release x > x X X x > x XX XX March 2000 x > x x > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > The X-Bone system for automated deployment of VPN / overlay networks > is now publicly available. ... Great. > The X-Bone is available for the following operating systems: > > - FreeBSD > CAIRN 2.5, 3.*, 3.* + KAME IPsec patches > > - Linux RedHat > 6.0, 6.0 + NIST Cerberus IPsec patches, 6.1 Why did you use the export-restricted NIST stuff rather than the more widely deployable FreeS/WAN implementation of IPSEC for Linux? From owner-ipsec@lists.tislabs.com Tue Mar 21 21:28:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24776; Tue, 21 Mar 2000 21:28:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA24508 Tue, 21 Mar 2000 23:16:31 -0500 (EST) Date: Wed, 22 Mar 2000 06:16:02 +0200 (EET) Message-Id: <200003220416.GAA01124@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Scott G. Kelly" Cc: akrywani@newbridge.com, "'Ricky Charlet'" , ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available In-Reply-To: <38D80A43.A19B2F67@redcreek.com> References: <003601bf937e$bf080740$1e0101c8@ANDREWK2.TIMESTEP> <38D80A43.A19B2F67@redcreek.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott G. Kelly writes: > Whether "heartbeats" are sent in a phase 1 or phase 2 SA, they are > essentially a feature of the SA. Features of SAs are currently > configured (and negotiated) using SA attributes. Why would these be any > different? Because SA payloads does not allow responder to modify the proposal. In heartbeat protocol this is almost mandatory feature, because the responder is the one who is going to send the packets, thus he wants to control the parameters. Of course we could say that when using this special heartbeat negotiation protocol, the responder is allowed to modify the SA, but the SA payload is also little too complicated for very basic negotiation (all the things about transforms, protocols and proposals). -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Mar 21 23:36:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA00683; Tue, 21 Mar 2000 23:36:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA25103 Wed, 22 Mar 2000 01:27:47 -0500 (EST) Message-ID: <38D867E4.234AE311@isi.edu> Date: Tue, 21 Mar 2000 22:27:48 -0800 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sandy Harris CC: ipsec@lists.tislabs.com, touch@ISI.EDU Subject: Re: Announcing X-Bone VPN/overlay software release References: <200003172220.OAA07373@boreas.isi.edu> <38D81ECE.6FE213B@storm.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sandy Harris wrote: > > Joe Touch wrote: ... > > The X-Bone system for automated deployment of VPN / overlay networks > > is now publicly available. ... > > Great. > > > The X-Bone is available for the following operating systems: > > > > - FreeBSD > > CAIRN 2.5, 3.*, 3.* + KAME IPsec patches > > > > - Linux RedHat > > 6.0, 6.0 + NIST Cerberus IPsec patches, 6.1 > > Why did you use the export-restricted NIST stuff rather than the > more widely deployable FreeS/WAN implementation of IPSEC for Linux? The X-Bone uses transport-mode IPSEC on IPIP tunnel headers, as further described in draft-touch-ipsec-vpn-00.txt. This requires that the SA be bound to a virtual interface (that of the tunnel). The FreeS/WAN IPSEC requires that SA's be bound to real, physical interfaces: >From the current FreeS/WAN man pages: ipsec tncfg - associate IPSEC virtual interface with real interface ... Tncfg attaches/detaches IPSEC virtual interfaces to/from real interfaces, through which packets will be forwarded once processed by IPSEC. ... Virtual interfaces typically have names like ipsec0, while real interfaces typically have names like eth0 or ppp0. The NIST implementation supports SAs binding to virtual interfaces, and also provides key management interfaces very similar to that of our primary platform, FreeBSD/KAME. It was a much more expedient choice for our proof-of-concept Linux port. Joe From owner-ipsec@lists.tislabs.com Wed Mar 22 09:16:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22289; Wed, 22 Mar 2000 09:16:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27250 Wed, 22 Mar 2000 10:22:41 -0500 (EST) Date: Wed, 22 Mar 2000 08:48:16 -0500 From: Jim Tiller X-Mailer: The Bat! (v1.36) S/N 569FD297 Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <2366.000322@lucent.com> To: Henry Spencer CC: IP Security List Subject: Re: IKE Public Key Encryption In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Henry, First of all, thanks for brining me back on-line - your right, not all public keys are based on certificates. HS> Only if there is a well-defined convention for what it means in the case HS> where no certificates are involved, or if the mandatory-ness is only in HS> the certificate case. One major reason for making things optional is so HS> they can be omitted when they do not make sense. I think making it mandatory for certs and not other methods would be odd and overly complicated. I'm beginning to see a pattern: Should the public key (cert or key its self, preferably), that is used for the encryption by the initiator, be hashed and included in the third message? This would allow the responder to know exactly which was used by the initiator, protect the identity, and pose no threat to security. Whatta ya think? -jim From owner-ipsec@lists.tislabs.com Wed Mar 22 10:25:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23657; Wed, 22 Mar 2000 10:25:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27767 Wed, 22 Mar 2000 12:06:48 -0500 (EST) Date: Wed, 22 Mar 2000 12:12:34 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: IKE Public Key Encryption In-Reply-To: <2366.000322@lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 22 Mar 2000, Jim Tiller wrote: > Should the public key (cert or key its self, preferably), that is used > for the encryption by the initiator, be hashed and included in the third > message? That is, extend the wording slightly so that if there is no cert, the hash is on the key itself, and make it mandatory? Makes sense to me. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Mar 22 16:23:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA29923; Wed, 22 Mar 2000 16:23:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28948 Wed, 22 Mar 2000 17:59:36 -0500 (EST) From: akrywani@newbridge.com Reply-To: To: "'IP Security List'" Subject: RE: IKE Public Key Encryption Date: Wed, 22 Mar 2000 18:04:54 -0500 Message-Id: <319A1C5F94C8D11192DE00805FBBADDF010D13FB@exchange> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF01021E05@exchange> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk DH> It's hashed to retain identity protection which is a feature of Main DH> Mode. As a general comment on including the hash of the certificate/public key in the message, this doesn't really provide true identity protection, since an attacker could generate the same hash. Wouldn't it be better to use a hash of the certificate plus some session info (e.g. the cookies), which would at least protect against identity tracking attacks. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Mar 22 17:06:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA00668; Wed, 22 Mar 2000 17:06:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29101 Wed, 22 Mar 2000 18:57:13 -0500 (EST) Message-Id: <4.3.2.20000322160153.00d79360@not-real.proper.com> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 22 Mar 2000 16:04:12 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Deleted Internet Drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. The IETF Secretariat has deleted the following drafts and replaced them with stub drafts that say "this draft was deleted because it was over six months old". If you are the author of one of these drafts and you want it alive, you should turn in a new copy next week or soon thereafter. draft-ietf-ipsec-ike-main draft-ietf-ipsec-isakmp-mode-cfg draft-ietf-ipsec-policy-framework draft-ietf-ipsec-policy-schema draft-ietf-ipsec-skipjack-cbc draft-ietf-ipsec-spp draft-ietf-ipsec-sps draft-ietf-ipsec-spsl draft-moskowitz-auth-dss draft-moskowitz-hip-dns draft-moskowitz-hip-enc draft-shima-ipsec-isakmp-cke-type --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Mar 22 17:42:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA01167; Wed, 22 Mar 2000 17:42:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29342 Wed, 22 Mar 2000 19:30:57 -0500 (EST) From: akrywani@newbridge.com Reply-To: To: "'Tero Kivinen'" , "'Scott G. Kelly'" Cc: "'Ricky Charlet'" , Subject: RE: Heartbeats draft available Date: Wed, 22 Mar 2000 19:37:05 -0500 Message-Id: <319A1C5F94C8D11192DE00805FBBADDF010D13FC@exchange> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF01021E0A@exchange> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, What Tero said is correct. Using the SA payload as a negotiation protocol for other features is undesirable for many reasons. First, there is the fact that the payload uses a flat proposal syntax. This means that the number of proposals in the list is the permutation of all the options. Adding even a boolean parameter to the negotiation (heartbeats=yes/no) would double the number of proposals required. As Tero mentioned, we could remove this problem by removing the requirement that the SA proposal cannot be modified (thus moving away from the flat model), but this has a number of undesirable properties as well. First, it makes IKE even less stateless than it is right now. Also, there is the issue of vendor ids. [EXT-METH] states that implementations MUST NOT send payloads of a private type unless both parties have both sent and received a familiar vendor ID. Since the SA proposals are sent in the first message of the phase 1 exchange, it seems inappropriate to negotiate heartbeats (an experimental protocol) before the vendor id has been received. Admittedly, this is not true if you are suggesting that we negotiate heartbeats as part of the QM proposal, but that would bind the heartbeat negotiation to the IPsec SA instead of to the connection, which is not what we want. That would violate the rule I mentioned in my previous message of reducing complexity by stating what you want to do and then doing it. (Is this rationale clear? I can go into more detail if it isn't.) Finally, one of the requirements of the draft is to provide a flexible negotiation scheme for the heartbeats. I think many people in this WG would agree that the absence of a standardized configuration protocol is hurting IPsec. Right now, ISAKMP-Config is the leading contender for that position, which is why I am proposing to use it. I don't see a problem with using ISAKMP-Config; it is simple and secure. But if, for whatever reason, the WG is unhappy with ISAKMP-Config, then let someone write a draft describing their own configuration protocol. If the WG chooses to ratify a different configuration protocol instead ISAKMP-Config then we will certainly change the draft to reflect this. Trying to avoid the issue of negotiation by way of a kludge like you are suggesting is a false economy. It may seem like a simple solution right now, but the sum of many simple, kludgy solutions equals one horrendous mess. BTW, I would consider heartbeats to be a feature of the connection, and not a feature of the SA. That is why I said that I didn't think it was important whether they were sent in phase 1 or phase 2. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@ssh.fi] > Sent: Tuesday, March 21, 2000 11:16 PM > To: Scott G. Kelly > Cc: Andrew Krywaniuk; 'Ricky Charlet'; ipsec@lists.tislabs.com > Subject: Re: Heartbeats draft available > > > Scott G. Kelly writes: > > Whether "heartbeats" are sent in a phase 1 or phase 2 SA, they are > > essentially a feature of the SA. Features of SAs are currently > > configured (and negotiated) using SA attributes. Why would > these be any > > different? > > Because SA payloads does not allow responder to modify the proposal. > In heartbeat protocol this is almost mandatory feature, because the > responder is the one who is going to send the packets, thus he wants > to control the parameters. > > Of course we could say that when using this special heartbeat > negotiation protocol, the responder is allowed to modify the SA, but > the SA payload is also little too complicated for very basic > negotiation (all the things about transforms, protocols and > proposals). > -- > kivinen@iki.fi Work : +358-9-4354 3218 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Wed Mar 22 18:07:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA02489; Wed, 22 Mar 2000 18:07:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29422 Wed, 22 Mar 2000 19:58:46 -0500 (EST) Message-ID: <38D96D9B.51F2BC7A@redcreek.com> Date: Wed, 22 Mar 2000 17:04:27 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: akrywani@newbridge.com CC: "'Tero Kivinen'" , "'Ricky Charlet'" , ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available References: <319A1C5F94C8D11192DE00805FBBADDF010D13FC@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't know about you, but I'm very busy preparing for Adelaide - my reply is abbreviated. akrywani@newbridge.com wrote: > Finally, one of the requirements of the draft is to provide a flexible > negotiation scheme for the heartbeats. The draft never explicitly lists requirements, which makes this discussion a bit strained. The points you refer to in an earlier post are listed as goals, which normally come after an elucidation of requirements. The draft should have an explicit requirements discussion, so that we are certain that we are all talking about the same things. > I think many people in this WG would agree that the absence of a > standardized configuration protocol is hurting IPsec. Right now, > ISAKMP-Config is the leading contender for that position, which is why I am > proposing to use it. This is a matter of opinion. It has been demonstrated that isa-cfg attempts to duplicate functionality already provided by another standardized configuration protocol. isa-cfg was originally proposed to provide host configuration for remote access clients. It is not a contender in ipsra for this function, so I would say it is largely an artifact at this point. I think it's more likely that you are using it simply because your product already supports it and because you wish to see it proliferate regardless of its usefulness, and I think this is wrong. I am not sure whether heartbeats belong in phase 1 or phase 2, and am open to discussion on that point. However, I am sure that requiring everyone to implement an artifact which would not likely become a standard under any other circumstances is inappropriate. It is not at all clear at this point that a negotiation facility is required for a keep-alive or heartbeat mechanism - that is, I have yet to see any requirements which bear this out. However, if it turns out that one is, then I think that it should either be handled along with existing SA attributes (perhaps in the same manner that lifetime is), or it should be a new exchange. SA configuration in no way relates to IP host configuration (a la BOOTP and DHCP), which is what isacfg attempts to provide, and there is no compelling argument for mixing the two. > Trying to avoid the issue of negotiation by way of a kludge like you are > suggesting is a false economy. It may seem like a simple solution right now, > but the sum of many simple, kludgy solutions equals one horrendous mess. I didn't suggest anything, except that this is an SA feature or attribute. Your comment is a bit misleading. > BTW, I would consider heartbeats to be a feature of the connection, and not > a feature of the SA. That is why I said that I didn't think it was important > whether they were sent in phase 1 or phase 2. The SA *is* the connection. Scott From owner-ipsec@lists.tislabs.com Wed Mar 22 18:32:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04935; Wed, 22 Mar 2000 18:32:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29544 Wed, 22 Mar 2000 20:18:54 -0500 (EST) Message-ID: <38D971B7.FD020093@cyphers.net> Date: Wed, 22 Mar 2000 17:21:59 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Paul Hoffman CC: ipsec@lists.tislabs.com Subject: Re: Deleted Internet Drafts References: <4.3.2.20000322160153.00d79360@not-real.proper.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That's a very silly thing to do. Draft deletion should be done by the WG chair at least. In this case, critical drafts such as mode-cfg were deleted which are referenced and required by other drafts which were not deleted. Paul Hoffman wrote: > > Greetings again. The IETF Secretariat has deleted the following drafts and > replaced them with stub drafts that say "this draft was deleted because it > was over six months old". If you are the author of one of these drafts and > you want it alive, you should turn in a new copy next week or soon thereafter. > > draft-ietf-ipsec-ike-main > draft-ietf-ipsec-isakmp-mode-cfg > draft-ietf-ipsec-policy-framework > draft-ietf-ipsec-policy-schema > draft-ietf-ipsec-skipjack-cbc > draft-ietf-ipsec-spp > draft-ietf-ipsec-sps > draft-ietf-ipsec-spsl > draft-moskowitz-auth-dss > draft-moskowitz-hip-dns > draft-moskowitz-hip-enc > draft-shima-ipsec-isakmp-cke-type -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Wed Mar 22 18:51:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA07067; Wed, 22 Mar 2000 18:51:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29624 Wed, 22 Mar 2000 20:38:33 -0500 (EST) Message-Id: <4.3.2.20000322174402.00baeac0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 22 Mar 2000 17:45:30 -0800 To: wprice@cyphers.net From: Paul Hoffman Subject: Re: Deleted Internet Drafts Cc: ipsec@lists.tislabs.com In-Reply-To: <38D971B7.FD020093@cyphers.net> References: <4.3.2.20000322160153.00d79360@not-real.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:21 PM 3/22/00 -0800, Will Price wrote: >That's a very silly thing to do. Draft deletion should be done by the WG >chair at least. Take it up with the IESG. The rules are pretty clear: drafts are good for only six months. >In this case, critical drafts such as mode-cfg were deleted which are >referenced and required by other drafts which were not deleted. Me, I put a reminder on my calendar for five months after I turn in a draft to update it or let it die. I only screwed up on one of them on this round. :-( --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Mar 22 18:53:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA07368; Wed, 22 Mar 2000 18:53:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA29630 Wed, 22 Mar 2000 20:40:06 -0500 (EST) Message-Id: <200003230142.RAA13268@potassium.network-alchemy.com> To: akrywani@newbridge.com cc: "'Tero Kivinen'" , "'Scott G. Kelly'" , "'Ricky Charlet'" , ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available In-reply-to: Your message of "Wed, 22 Mar 2000 19:37:05 EST." <319A1C5F94C8D11192DE00805FBBADDF010D13FC@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13265.953775758.1@network-alchemy.com> Date: Wed, 22 Mar 2000 17:42:38 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The "flat" proposal syntax is not an issue because you can negotiate the keepalive in phase 2 by just defining a place to hold that attribute in your already newly defined payload. Just chain it into the phase 2 offer: hash, SA, KE, newpayload, IDi2, IDr2 where newpayload has a field to hold a standard ISAKMP attribute which could be the keepalive interval for the SA(s) created in this exchange. This is not a kludge, as you suggest, anymore than... well, a lot of other proposals for extending IKE. I have no religion on whether the term is keepalive or heartbeat or whether they belong in phase 1 or phase 2, I'm just pointing out that there are lots of ways to do this. And also let me note that, just perhaps, a protocol that requires 30 pages to describe something as simple as "I'm still here!" might be a tad heavy. How did other people implement their proprietary protocols? And how do they perform in the field. I know there is deployed code that does this function. I'd, for one, would like to hear about some real world experience before we go designing a new protocol. Dan. On Wed, 22 Mar 2000 19:37:05 EST you wrote > Hi Scott, > > What Tero said is correct. Using the SA payload as a negotiation protocol > for other features is undesirable for many reasons. > > First, there is the fact that the payload uses a flat proposal syntax. This > means that the number of proposals in the list is the permutation of all the > options. Adding even a boolean parameter to the negotiation > (heartbeats=yes/no) would double the number of proposals required. > > As Tero mentioned, we could remove this problem by removing the requirement > that the SA proposal cannot be modified (thus moving away from the flat > model), but this has a number of undesirable properties as well. > > First, it makes IKE even less stateless than it is right now. > > Also, there is the issue of vendor ids. [EXT-METH] states that > implementations MUST NOT send payloads of a private type unless both parties > have both sent and received a familiar vendor ID. Since the SA proposals are > sent in the first message of the phase 1 exchange, it seems inappropriate to > negotiate heartbeats (an experimental protocol) before the vendor id has > been received. > > Admittedly, this is not true if you are suggesting that we negotiate > heartbeats as part of the QM proposal, but that would bind the heartbeat > negotiation to the IPsec SA instead of to the connection, which is not what > we want. That would violate the rule I mentioned in my previous message of > reducing complexity by stating what you want to do and then doing it. (Is > this rationale clear? I can go into more detail if it isn't.) > > Finally, one of the requirements of the draft is to provide a flexible > negotiation scheme for the heartbeats. > > I think many people in this WG would agree that the absence of a > standardized configuration protocol is hurting IPsec. Right now, > ISAKMP-Config is the leading contender for that position, which is why I am > proposing to use it. > > I don't see a problem with using ISAKMP-Config; it is simple and secure. But > if, for whatever reason, the WG is unhappy with ISAKMP-Config, then let > someone write a draft describing their own configuration protocol. If the WG > chooses to ratify a different configuration protocol instead ISAKMP-Config > then we will certainly change the draft to reflect this. > > Trying to avoid the issue of negotiation by way of a kludge like you are > suggesting is a false economy. It may seem like a simple solution right now, > but the sum of many simple, kludgy solutions equals one horrendous mess. > > BTW, I would consider heartbeats to be a feature of the connection, and not > a feature of the SA. That is why I said that I didn't think it was important > whether they were sent in phase 1 or phase 2. > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > > > -----Original Message----- > > From: Tero Kivinen [mailto:kivinen@ssh.fi] > > Sent: Tuesday, March 21, 2000 11:16 PM > > To: Scott G. Kelly > > Cc: Andrew Krywaniuk; 'Ricky Charlet'; ipsec@lists.tislabs.com > > Subject: Re: Heartbeats draft available > > > > > > Scott G. Kelly writes: > > > Whether "heartbeats" are sent in a phase 1 or phase 2 SA, they are > > > essentially a feature of the SA. Features of SAs are currently > > > configured (and negotiated) using SA attributes. Why would > > these be any > > > different? > > > > Because SA payloads does not allow responder to modify the proposal. > > In heartbeat protocol this is almost mandatory feature, because the > > responder is the one who is going to send the packets, thus he wants > > to control the parameters. > > > > Of course we could say that when using this special heartbeat > > negotiation protocol, the responder is allowed to modify the SA, but > > the SA payload is also little too complicated for very basic > > negotiation (all the things about transforms, protocols and > > proposals). > > -- > > kivinen@iki.fi Work : +358-9-4354 3218 > > SSH Communications Security http://www.ssh.fi/ > > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > > > From owner-ipsec@lists.tislabs.com Wed Mar 22 22:22:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA19685; Wed, 22 Mar 2000 22:22:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA00258 Thu, 23 Mar 2000 00:09:47 -0500 (EST) Message-ID: <000501bf9487$ba877ac0$2dcd09c0@nig95> From: "rupesh" To: "IPSEC" Subject: Q: What is advantage of tunnel mode between host to host scenrio? Date: Thu, 23 Mar 2000 10:52:04 +0530 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 5.00.0518.4 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk With Ref to RFC2401 tunnel mode between host to host MUST be supported without any Gateway in picture.In such a condition my Outer IP header will be same as Inner IP header.I am unable to visualise advantage of such a Mode. Can anyone give me the answer or scenrio where this will have advantage ? Regards Rupesh From owner-ipsec@lists.tislabs.com Thu Mar 23 07:23:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11674; Thu, 23 Mar 2000 07:23:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA01949 Thu, 23 Mar 2000 08:49:09 -0500 (EST) Date: Wed, 22 Mar 2000 15:15:23 -0500 From: Jim Tiller X-Mailer: The Bat! (v1.41) Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <7635.000322@lucent.com> To: Henry Spencer CC: IP Security List Subject: Re[2]: IKE Public Key Encryption In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So, there is merit? I'm glad you agree. I guess Dan and Dave would have to consider this to be included in the latest draft of IKE. (?) Does anyone else have comments to share? This subject has not seen as much action as I thought it would:) -jim HS> On Wed, 22 Mar 2000, Jim Tiller wrote: >> Should the public key (cert or key its self, preferably), that is used >> for the encryption by the initiator, be hashed and included in the third >> message? HS> That is, extend the wording slightly so that if there is no cert, the hash HS> is on the key itself, and make it mandatory? Makes sense to me. HS> Henry Spencer HS> henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 23 08:01:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12519; Thu, 23 Mar 2000 08:01:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02165 Thu, 23 Mar 2000 09:35:09 -0500 (EST) From: "Glen Zorn" To: , "Paul Hoffman" Cc: Subject: RE: Deleted Internet Drafts Date: Thu, 23 Mar 2000 06:40:04 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38D971B7.FD020093@cyphers.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > That's a very silly thing to do. Draft deletion should be done by the WG > chair at least. The policy is _extremely_ clear, and not in the least silly. If a draft is not updated within six months, I think that it's perfectly reasonable to assume that either a) it's dead or b) the author or authors have lost interest. > > In this case, critical drafts such as mode-cfg were deleted which are > referenced and required by other drafts which were not deleted. The concept to understand is "deadline". If these drafts were "critical", perhaps the authors thereof should have paid just a bit more attention. > > > Paul Hoffman wrote: > > > > Greetings again. The IETF Secretariat has deleted the following > drafts and > > replaced them with stub drafts that say "this draft was deleted > because it > > was over six months old". If you are the author of one of these > drafts and > > you want it alive, you should turn in a new copy next week or > soon thereafter. > > > > draft-ietf-ipsec-ike-main > > draft-ietf-ipsec-isakmp-mode-cfg > > draft-ietf-ipsec-policy-framework > > draft-ietf-ipsec-policy-schema > > draft-ietf-ipsec-skipjack-cbc > > draft-ietf-ipsec-spp > > draft-ietf-ipsec-sps > > draft-ietf-ipsec-spsl > > draft-moskowitz-auth-dss > > draft-moskowitz-hip-dns > > draft-moskowitz-hip-enc > > draft-shima-ipsec-isakmp-cke-type > > > -- > > Will Price, Director of Engineering > PGP Security, Inc. > a division of Network Associates, Inc. > > From owner-ipsec@lists.tislabs.com Thu Mar 23 09:02:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13414; Thu, 23 Mar 2000 09:01:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02630 Thu, 23 Mar 2000 10:35:08 -0500 (EST) Date: Thu, 23 Mar 2000 10:40:39 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Q: What is advantage of tunnel mode between host to host scenrio? In-Reply-To: <000501bf9487$ba877ac0$2dcd09c0@nig95> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 23 Mar 2000, rupesh wrote: > With Ref to RFC2401 tunnel mode between host to host MUST be supported > without any Gateway in picture.In such a condition my Outer IP header will > be same as Inner IP header.I am unable to visualise advantage of such a > Mode... The outer IP header won't be *exactly* the same as the inner one. In particular, the higher-level protocol identifier will be hidden. Also, the fact that the outer and inner IP headers are similar is not obvious to an eavesdropper. If the gateways are (or could be) also carrying IPSec traffic on behalf of other sites, there is considerable added security in this. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 23 09:02:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13468; Thu, 23 Mar 2000 09:02:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02549 Thu, 23 Mar 2000 10:22:32 -0500 (EST) Message-ID: <38DA4547.A7F3AABF@certicom.com> Date: Thu, 23 Mar 2000 10:24:39 -0600 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: IPSEC Subject: Re: Q: What is advantage of tunnel mode between host to host scenrio? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, In some cases the host might have two addresses, one private that is hidden by ESP in tunnel mode, and one public that is visible and used as an address in regular IP packets and as an outer address in encrypted by ESP IP packets. So, inner and outer addresses can be different and the advantage is obvious. Regards, Yuri rupesh wrote: > With Ref to RFC2401 tunnel mode between host to host MUST be supported > without any Gateway in picture.In such a condition my Outer IP header will > be same as Inner IP header.I am unable to visualise advantage of such a > Mode. > Can anyone give me the answer or scenrio where this will have advantage ? > > Regards > Rupesh From owner-ipsec@lists.tislabs.com Thu Mar 23 09:40:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14042; Thu, 23 Mar 2000 09:40:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02764 Thu, 23 Mar 2000 11:14:50 -0500 (EST) From: akrywani@newbridge.com Reply-To: To: "'Jim Tiller'" Cc: "'IP Security List'" Subject: RE: Re[2]: IKE Public Key Encryption Date: Thu, 23 Mar 2000 11:19:46 -0500 Message-Id: <319A1C5F94C8D11192DE00805FBBADDF010D13FD@exchange> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF01021E37@exchange> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Obviously, there is no perfect solution to this problem. What I suggested was merely a way to make the task more difficult for the adversary. In this case, the responder would actually have to test the hash for each connection, rather than doing a simple memcmp. Information theory basically prevents identity protection and authentication from co-existing in a stateless protocol. If you really wanted to have true identity protection, you would have to keep a per-connection state, such as a shared secret or a user token. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Jim Tiller [mailto:jtiller@lucent.com] > Sent: Thursday, March 23, 2000 9:05 AM > To: Andrew Krywaniuk > Cc: 'IP Security List' > Subject: Re[2]: IKE Public Key Encryption > > > Hello Andrew, > > Wednesday, March 22, 2000, 6:04:54 PM, you wrote: > anc> As a general comment on including the hash of the > certificate/public key in > anc> the message, this doesn't really provide true identity > protection, since an > anc> attacker could generate the same hash. > > To accomplish this the attacker would have to hash all possible > certificates and or public keys that he thinks are relative. BUT - you > have a good point, nonetheless. > > anc> Wouldn't it be better to use a hash of the certificate > plus some session > anc> info (e.g. the cookies), which would at least protect > against identity > anc> tracking attacks. > > I would actually like to see the verbiage modified slightly to hash > the public 'value' used (certificate or key) and always > provide that to the > responder. Therefore, if your going to hash it, you should include an > identifier. As far as using a cookie, wouldn't that be available to > the attacker as well? Unfortunately, I cannot think of a better idea > right now....it can't be Ne or ID in standard mode, or Ne, > ID, or KE in > revised mode. > So, the point of including an identifier to protect the hash to avoid > an attacker producing the same, may simply be moot. To fully protect > the identity, you have to use something only known by the peers, which > is usually encrypted for transit, or generated independently, such as > g^xy, (but that wouldn't work for revised mode). > > Basically, you have a good point, but I don't know a good direction. > Nonetheless, I do think the inclusion of the public value in the > initiators message should be included - for scalability. > > -jim > > anc> Andrew > anc> -------------------------------------- > anc> Beauty with out truth is insubstantial. > anc> Truth without beauty is unbearable. > > > From owner-ipsec@lists.tislabs.com Thu Mar 23 09:52:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14243; Thu, 23 Mar 2000 09:52:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02831 Thu, 23 Mar 2000 11:33:45 -0500 (EST) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Thu, 23 Mar 2000 18:40:06 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: Glen Zorn cc: wprice@cyphers.net, Paul Hoffman , ipsec@lists.tislabs.com Subject: RE: Deleted Internet Drafts 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, 23 Mar 2000, Glen Zorn wrote: > > > > That's a very silly thing to do. Draft deletion should be done by the WG > > chair at least. > > The policy is _extremely_ clear, and not in the least silly. If a draft is > not updated within six months, I think that it's perfectly reasonable to > assume that either a) it's dead or b) the author or authors have lost > interest. > Agreed. Even more, citing RFC2026: ******************************************************** * * * Under no circumstances should an Internet-Draft * * be referenced by any paper, report, or Request- * * for-Proposal, nor should a vendor claim compliance * * with an Internet-Draft. * * * ******************************************************** Helger Lipmaa http://home.cyber.ee/helger From owner-ipsec@lists.tislabs.com Thu Mar 23 10:19:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14685; Thu, 23 Mar 2000 10:19:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02950 Thu, 23 Mar 2000 11:56:13 -0500 (EST) From: akrywani@newbridge.com Reply-To: To: "'Dan Harkins'" Cc: "'Tero Kivinen'" , "'Scott G. Kelly'" , "'Ricky Charlet'" , Subject: RE: Heartbeats draft available Date: Thu, 23 Mar 2000 12:02:20 -0500 Message-Id: <319A1C5F94C8D11192DE00805FBBADDF010D13FE@exchange> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF01021E28@exchange> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I knew I would draw flack for putting out a 30 page draft and then claiming it is simple. If you want, I can also write a 5 page condensed version which does not include rationale, diagrams, implementation hints, and optional payloads. BTW, I didn't mean that putting a new payload inside QM was a kludge. I only meant that putting a new attribute inside the SA proposal payload was a kludge. What you are suggesting is a new configuration protocol (assuming that it can used for more than negotiating the heartbeat interval). The heartbeat configuration protocol we define is not tightly bound to ISAKMP-Config, and it can be ported to other protocols (with a few, generic properties) very easily. The reason for not doing this is that it binds the heartbeats to the QM exchange when they are really a property of the connection. I could attempt to explain the rationale for decisions such as these in great detail, but then the draft would be 60 pages instead of 30. BTW, I am using "connection" to mean the logical connection between two hosts when at least one SA (either phase 1 or phase 2) exists. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: Wednesday, March 22, 2000 8:43 PM > To: Andrew Krywaniuk > Cc: 'Tero Kivinen'; 'Scott G. Kelly'; 'Ricky Charlet'; > ipsec@lists.tislabs.com > Subject: Re: Heartbeats draft available > > > The "flat" proposal syntax is not an issue because you can > negotiate > the keepalive in phase 2 by just defining a place to hold > that attribute > in your already newly defined payload. Just chain it into the > phase 2 offer: > > hash, SA, KE, newpayload, IDi2, IDr2 > > where newpayload has a field to hold a standard ISAKMP attribute which > could be the keepalive interval for the SA(s) created in this > exchange. > > This is not a kludge, as you suggest, anymore than... well, a lot of > other proposals for extending IKE. > > I have no religion on whether the term is keepalive or heartbeat or > whether they belong in phase 1 or phase 2, I'm just pointing out that > there are lots of ways to do this. And also let me note that, > just perhaps, > a protocol that requires 30 pages to describe something as > simple as "I'm > still here!" might be a tad heavy. > > How did other people implement their proprietary protocols? > And how do > they perform in the field. I know there is deployed code that > does this > function. I'd, for one, would like to hear about some real > world experience > before we go designing a new protocol. > > Dan. > > On Wed, 22 Mar 2000 19:37:05 EST you wrote > > Hi Scott, > > > > What Tero said is correct. Using the SA payload as a > negotiation protocol > > for other features is undesirable for many reasons. > > > > First, there is the fact that the payload uses a flat > proposal syntax. This > > means that the number of proposals in the list is the > permutation of all the > > options. Adding even a boolean parameter to the negotiation > > (heartbeats=yes/no) would double the number of proposals required. > > > > As Tero mentioned, we could remove this problem by removing > the requirement > > that the SA proposal cannot be modified (thus moving away > from the flat > > model), but this has a number of undesirable properties as well. > > > > First, it makes IKE even less stateless than it is right now. > > > > Also, there is the issue of vendor ids. [EXT-METH] states that > > implementations MUST NOT send payloads of a private type > unless both parties > > have both sent and received a familiar vendor ID. Since the > SA proposals are > > sent in the first message of the phase 1 exchange, it seems > inappropriate to > > negotiate heartbeats (an experimental protocol) before the > vendor id has > > been received. > > > > Admittedly, this is not true if you are suggesting that we negotiate > > heartbeats as part of the QM proposal, but that would bind > the heartbeat > > negotiation to the IPsec SA instead of to the connection, > which is not what > > we want. That would violate the rule I mentioned in my > previous message of > > reducing complexity by stating what you want to do and then > doing it. (Is > > this rationale clear? I can go into more detail if it isn't.) > > > > Finally, one of the requirements of the draft is to provide > a flexible > > negotiation scheme for the heartbeats. > > > > I think many people in this WG would agree that the absence of a > > standardized configuration protocol is hurting IPsec. Right now, > > ISAKMP-Config is the leading contender for that position, > which is why I am > > proposing to use it. > > > > I don't see a problem with using ISAKMP-Config; it is > simple and secure. But > > if, for whatever reason, the WG is unhappy with > ISAKMP-Config, then let > > someone write a draft describing their own configuration > protocol. If the WG > > chooses to ratify a different configuration protocol > instead ISAKMP-Config > > then we will certainly change the draft to reflect this. > > > > Trying to avoid the issue of negotiation by way of a kludge > like you are > > suggesting is a false economy. It may seem like a simple > solution right now, > > but the sum of many simple, kludgy solutions equals one > horrendous mess. > > > > BTW, I would consider heartbeats to be a feature of the > connection, and not > > a feature of the SA. That is why I said that I didn't think > it was important > > whether they were sent in phase 1 or phase 2. > > > > Andrew > > -------------------------------------- > > Beauty with out truth is insubstantial. > > Truth without beauty is unbearable. > > > > > > > -----Original Message----- > > > From: Tero Kivinen [mailto:kivinen@ssh.fi] > > > Sent: Tuesday, March 21, 2000 11:16 PM > > > To: Scott G. Kelly > > > Cc: Andrew Krywaniuk; 'Ricky Charlet'; ipsec@lists.tislabs.com > > > Subject: Re: Heartbeats draft available > > > > > > > > > Scott G. Kelly writes: > > > > Whether "heartbeats" are sent in a phase 1 or phase 2 > SA, they are > > > > essentially a feature of the SA. Features of SAs are currently > > > > configured (and negotiated) using SA attributes. Why would > > > these be any > > > > different? > > > > > > Because SA payloads does not allow responder to modify > the proposal. > > > In heartbeat protocol this is almost mandatory feature, > because the > > > responder is the one who is going to send the packets, > thus he wants > > > to control the parameters. > > > > > > Of course we could say that when using this special heartbeat > > > negotiation protocol, the responder is allowed to modify > the SA, but > > > the SA payload is also little too complicated for very basic > > > negotiation (all the things about transforms, protocols and > > > proposals). > > > -- > > > kivinen@iki.fi Work : > +358-9-4354 3218 > > > SSH Communications Security http://www.ssh.fi/ > > > SSH IPSEC Toolkit > http://www.ssh.fi/ipsec/ > > > > > > From owner-ipsec@lists.tislabs.com Thu Mar 23 10:19:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14699; Thu, 23 Mar 2000 10:19:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02966 Thu, 23 Mar 2000 11:58:43 -0500 (EST) Date: Thu, 23 Mar 2000 12:04:53 -0500 Message-Id: <200003231704.MAA28050@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rupesh.jain@cdac.ernet.in Cc: ipsec@lists.tislabs.com Subject: Re: Q: What is advantage of tunnel mode between host to host scenrio? References: <000501bf9487$ba877ac0$2dcd09c0@nig95> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "rupesh" == rupesh writes: rupesh> With Ref to RFC2401 tunnel mode between host to host MUST be rupesh> supported without any Gateway in picture.In such a condition rupesh> my Outer IP header will be same as Inner IP header.I am rupesh> unable to visualise advantage of such a Mode. Can anyone rupesh> give me the answer or scenrio where this will have advantage? 1. Fewer mechanisms to implement. 2. It hides the fact that you're doing host to host communication rather than communication for someone else. paul From owner-ipsec@lists.tislabs.com Thu Mar 23 10:22:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14743; Thu, 23 Mar 2000 10:22:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02983 Thu, 23 Mar 2000 11:59:25 -0500 (EST) From: akrywani@newbridge.com Reply-To: To: "'Scott G. Kelly'" Cc: "'Tero Kivinen'" , "'Ricky Charlet'" , Subject: RE: Heartbeats draft available Date: Thu, 23 Mar 2000 12:05:26 -0500 Message-Id: <319A1C5F94C8D11192DE00805FBBADDF010D13FF@exchange> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF01021E26@exchange> Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't have time to write a full reply to this message either, as my flight leaves in a few hours. Let me just say that you are wrong about my intentions. We didn't set out to use ISAKMP-Config as the negotiation protocol in some half-assed attempt to subvert DHCP. I told you ages ago (in private e-mail) that I believe Config Mode address assignment to be a short term solution only and that a method of tunnelling pre-built DHCP packets (such as the one you have proposed) does eventually need to be standardized. In fact, I investigated using other negotiation protocols for heartbeat configuration for the simple reason that I knew that using ISAKMP-Config as transport would result in a silly, straw-man (or rather straw-protocol) political argument such as this one. The real reason I didn't use one of the other configuration protocols is that there aren't any others. Oh, sure, we could have kludged this information onto another protocol, such as acknowledged info mode or quick mode, but why? And why is anything that uses Isakmp-Config for purposes other than address assignment guilty by association? I don't have time right now to expand on my rationale for when (at which stage) and why negotiation is necessary in general. The reasons are derived form ideology and experience (and they are stored in my mind in a non-verbal format). Trying to explain them in a short e-mail would be impossible. I will think about how best to communicate this at some point in the future. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Wednesday, March 22, 2000 8:04 PM > To: Andrew Krywaniuk > Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com > Subject: Re: Heartbeats draft available > > > I don't know about you, but I'm very busy preparing for Adelaide - my > reply is abbreviated. > > akrywani@newbridge.com wrote: > > > > > Finally, one of the requirements of the draft is to provide > a flexible > > negotiation scheme for the heartbeats. > > The draft never explicitly lists requirements, which makes this > discussion a bit strained. The points you refer to in an earlier post > are listed as goals, which normally come after an elucidation of > requirements. The draft should have an explicit requirements > discussion, > so that we are certain that we are all talking about the same things. > > > I think many people in this WG would agree that the absence of a > > standardized configuration protocol is hurting IPsec. Right now, > > ISAKMP-Config is the leading contender for that position, > which is why I am > > proposing to use it. > > This is a matter of opinion. It has been demonstrated that isa-cfg > attempts to duplicate functionality already provided by another > standardized configuration protocol. isa-cfg was originally > proposed to > provide host configuration for remote access clients. It is not a > contender in ipsra for this function, so I would say it is largely an > artifact at this point. I think it's more likely that you are using it > simply because your product already supports it and because > you wish to > see it proliferate regardless of its usefulness, and I think this is > wrong. > > I am not sure whether heartbeats belong in phase 1 or phase 2, and am > open to discussion on that point. However, I am sure that requiring > everyone to implement an artifact which would not likely become a > standard under any other circumstances is inappropriate. It is not at > all clear at this point that a negotiation facility is required for a > keep-alive or heartbeat mechanism - that is, I have yet to see any > requirements which bear this out. However, if it turns out > that one is, > then I think that it should either be handled along with existing SA > attributes (perhaps in the same manner that lifetime is), or it should > be a new exchange. > SA configuration in no way relates to IP host configuration > (a la BOOTP > and DHCP), which is what isacfg attempts to provide, and there is no > compelling argument for mixing the two. > > > Trying to avoid the issue of negotiation by way of a kludge > like you are > > suggesting is a false economy. It may seem like a simple > solution right now, > > but the sum of many simple, kludgy solutions equals one > horrendous mess. > > I didn't suggest anything, except that this is an SA feature or > attribute. Your comment is a bit misleading. > > > BTW, I would consider heartbeats to be a feature of the > connection, and not > > a feature of the SA. That is why I said that I didn't think > it was important > > whether they were sent in phase 1 or phase 2. > > The SA *is* the connection. > > Scott > From owner-ipsec@lists.tislabs.com Thu Mar 23 10:37:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14892; Thu, 23 Mar 2000 10:37:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03067 Thu, 23 Mar 2000 12:16:05 -0500 (EST) Message-ID: <38DA52AD.FC017594@redcreek.com> Date: Thu, 23 Mar 2000 09:21:49 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: akrywani@newbridge.com CC: "'Tero Kivinen'" , "'Ricky Charlet'" , ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available References: <319A1C5F94C8D11192DE00805FBBADDF010D13FF@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk akrywani@newbridge.com wrote: > > In fact, I investigated using other negotiation protocols for heartbeat > configuration for the simple reason that I knew that using ISAKMP-Config as > transport would result in a silly, straw-man (or rather straw-protocol) > political argument such as this one. Again, this misses the point: you have to explicitly specify the requirements, because otherwise it is not clear that negotiation is required. Only when we understand *why* negotiation is required can we intelligently discuss protocol requirements. Scott From owner-ipsec@lists.tislabs.com Thu Mar 23 14:41:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18443; Thu, 23 Mar 2000 14:41:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00766 Thu, 23 Mar 2000 16:13:52 -0500 (EST) Message-ID: <24881EF3F745D311AC6B0090276D21C209ADB7FE@FMSMSX105> From: "Baker, Matt W" To: ipsec@lists.tislabs.com Subject: Macintosh IPSec Clients - Progress-to-date Date: Thu, 23 Mar 2000 13:19:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All, I hate to ask a somewhat off-topic/non-technical question, but does anyone know what the state of IPSec clients for Macintosh platforms is today. I saw that their had been some activity at HUT, but doesn't look like it has grown past Alpha. I believe that this question whizzed by previously...links/redirects appreciated Matthew W. Baker From owner-ipsec@lists.tislabs.com Thu Mar 23 19:06:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA27572; Thu, 23 Mar 2000 19:06:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01641 Thu, 23 Mar 2000 20:44:23 -0500 (EST) Message-ID: From: "Stoler, David J" To: "'Baker, Matt W'" , ipsec@lists.tislabs.com Subject: RE: Macintosh IPSec Clients - Progress-to-date Date: Thu, 23 Mar 2000 17:50:05 -0800 X-Mailer: Internet Mail Service (5.0.1460.8) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Matt, NetLOCK has had a fully functional IPSec (and pre-IPSec) Macintosh client for many years. NetLOCK is also available for different flavors of Windows and UNIX, plus NetWare. See http://www.netlock.com Regards, David Stoler -----Original Message----- From: Baker, Matt W [mailto:matt.w.baker@intel.com] Sent: Thursday, March 23, 2000 1:20 PM To: ipsec@lists.tislabs.com Subject: Macintosh IPSec Clients - Progress-to-date All, I hate to ask a somewhat off-topic/non-technical question, but does anyone know what the state of IPSec clients for Macintosh platforms is today. I saw that their had been some activity at HUT, but doesn't look like it has grown past Alpha. I believe that this question whizzed by previously...links/redirects appreciated Matthew W. Baker From owner-ipsec@lists.tislabs.com Thu Mar 23 20:13:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA02194; Thu, 23 Mar 2000 20:13:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01873 Thu, 23 Mar 2000 22:00:31 -0500 (EST) Mime-Version: 1.0 X-Sender: rah@shell3.shore.net Message-Id: Date: Thu, 23 Mar 2000 22:03:07 -0500 To: ipsec@lists.tislabs.com From: "R. A. Hettinga" Subject: Re: Macintosh IPSec Clients - Progress-to-date Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- begin forwarded text Date: Thu, 23 Mar 2000 21:06:40 -0500 To: "R. A. Hettinga" , mac-crypto@vmeng.com From: Leonard Rosenthol Subject: Re: Macintosh IPSec Clients - Progress-to-date Cc: matt.w.baker@intel.com At 5:06 PM -0500 3/23/00, R. A. Hettinga wrote: >I hate to ask a somewhat off-topic/non-technical question, but does anyone >know what the state of IPSec clients for Macintosh platforms is today. There are at least two of them... 1) PGPNet, part of PGP 6.x. () 2) V-One SmartGate () LDR -- ---------------------------------------------------------------------------- You've got a SmartFriend in Pennsylvania ---------------------------------------------------------------------------- Leonard Rosenthol Internet: leonardr@lazerware.com America Online: MACgician Web Site: FTP Site: PGP Fingerprint: C76E 0497 C459 182D 0C6B AB6B CA10 B4DF 8067 5E65 --- end forwarded text -- ----------------- R. A. Hettinga The Internet Bearer Underwriting Corporation 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From owner-ipsec@lists.tislabs.com Thu Mar 23 21:38:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA07588; Thu, 23 Mar 2000 21:38:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02084 Thu, 23 Mar 2000 23:28:34 -0500 (EST) Message-ID: <010e01bf954b$26f772a0$2dcd09c0@nig95> From: "rupesh" To: "Paul Koning" Cc: "IPSEC" Subject: Re: Q: What is advantage of tunnel mode between host to host scenrio? Date: Fri, 24 Mar 2000 10:10:57 +0530 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 5.00.0518.4 X-Mimeole: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Please elobrate the points you are making 1. Fewer mechanisms to implement. Pl. explain what do you mean by fewer mechnaisms. Instead , i think there is need to do more processing at both ends ( like adding extra headers). 2. It hides the fact that you're doing host to host communication >rather than communication for someone else. How it hides the fact that the communication is host to host because the inner and outer IP header may be same. Only in case of host having multiple NICs then this point is vaild. -----Original Message----- From: Paul Koning To: Cc: Date: Thursday, March 23, 2000 10:37 PM Subject: Re: Q: What is advantage of tunnel mode between host to host scenrio? >>>>>> "rupesh" == rupesh writes: > > rupesh> With Ref to RFC2401 tunnel mode between host to host MUST be > rupesh> supported without any Gateway in picture.In such a condition > rupesh> my Outer IP header will be same as Inner IP header.I am > rupesh> unable to visualise advantage of such a Mode. Can anyone > rupesh> give me the answer or scenrio where this will have advantage? > >1. Fewer mechanisms to implement. > >2. It hides the fact that you're doing host to host communication >rather than communication for someone else. > > paul From owner-ipsec@lists.tislabs.com Thu Mar 23 21:42:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA07777; Thu, 23 Mar 2000 21:42:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02126 Thu, 23 Mar 2000 23:32:35 -0500 (EST) Message-ID: <011e01bf954b$b7dd9060$2dcd09c0@nig95> From: "rupesh" To: "IPSEC" Subject: Fw: Q: What is advantage of tunnel mode between host to host scenrio? Date: Fri, 24 Mar 2000 10:15:01 +0530 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 5.00.0518.4 X-Mimeole: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Hi >The fact you are making the higher-level protocol identifier will be >hidden.I think higher protocols will be hidden in ESP - Trasport Mode also & >there is no need for Tunnel mode for that.Tunnel mode is meant specifically >for hiding inner IP address.So, please elobrate your point. >Reg >Rupesh > >-----Original Message----- >From: Henry Spencer >To: IP Security List >Date: Thursday, March 23, 2000 11:22 PM >Subject: Re: Q: What is advantage of tunnel mode between host to host >scenrio? > > >>On Thu, 23 Mar 2000, rupesh wrote: >>> With Ref to RFC2401 tunnel mode between host to host MUST be supported >>> without any Gateway in picture.In such a condition my Outer IP header >will >>> be same as Inner IP header.I am unable to visualise advantage of such a >>> Mode... >> >>The outer IP header won't be *exactly* the same as the inner one. In >>particular, the higher-level protocol identifier will be hidden. >> >>Also, the fact that the outer and inner IP headers are similar is not >>obvious to an eavesdropper. If the gateways are (or could be) also >>carrying IPSec traffic on behalf of other sites, there is considerable >>added security in this. >> >> Henry Spencer >> henry@spsystems.net > From owner-ipsec@lists.tislabs.com Fri Mar 24 03:26:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA00108; Fri, 24 Mar 2000 03:26:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA03116 Fri, 24 Mar 2000 04:55:17 -0500 (EST) Message-ID: <38DB3D17.3DE26F92@F-Secure.com> Date: Fri, 24 Mar 2000 12:01:59 +0200 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Glen Zorn CC: wprice@cyphers.net, Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Deleted Internet Drafts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Why is there no repository for obsoleted IDs? I frequently would like to run "diff -c" between the current draft version and the one I happened to read a while back. In most cases this would provide useful information. Ari Glen Zorn wrote: > > > > > That's a very silly thing to do. Draft deletion should be done by the WG > > chair at least. > > The policy is _extremely_ clear, and not in the least silly. If a draft is > not updated within six months, I think that it's perfectly reasonable to > assume that either a) it's dead or b) the author or authors have lost > interest. > > > > > In this case, critical drafts such as mode-cfg were deleted which are > > referenced and required by other drafts which were not deleted. > > The concept to understand is "deadline". If these drafts were "critical", > perhaps the authors thereof should have paid just a bit more attention. > > > > > > > Paul Hoffman wrote: > > > > > > Greetings again. The IETF Secretariat has deleted the following > > drafts and > > > replaced them with stub drafts that say "this draft was deleted > > because it > > > was over six months old". If you are the author of one of these > > drafts and > > > you want it alive, you should turn in a new copy next week or > > soon thereafter. > > > > > > draft-ietf-ipsec-ike-main > > > draft-ietf-ipsec-isakmp-mode-cfg > > > draft-ietf-ipsec-policy-framework > > > draft-ietf-ipsec-policy-schema > > > draft-ietf-ipsec-skipjack-cbc > > > draft-ietf-ipsec-spp > > > draft-ietf-ipsec-sps > > > draft-ietf-ipsec-spsl > > > draft-moskowitz-auth-dss > > > draft-moskowitz-hip-dns > > > draft-moskowitz-hip-enc > > > draft-shima-ipsec-isakmp-cke-type > > > > > > -- > > > > Will Price, Director of Engineering > > PGP Security, Inc. > > a division of Network Associates, Inc. > > > > -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Fri Mar 24 04:22:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01314; Fri, 24 Mar 2000 04:22:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA03250 Fri, 24 Mar 2000 05:40:21 -0500 (EST) Message-ID: <004b01bf957e$04ff4780$9c35fccb@slowf> From: "=?ks_c_5601-1987?B?wLHB1rTnLi4=?=" To: Subject: How to call from kernel to user program Date: Fri, 24 Mar 2000 19:45:05 +0900 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0047_01BF95C9.7441FCF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0047_01BF95C9.7441FCF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0048_01BF95C9.744690D0" ------=_NextPart_001_0048_01BF95C9.744690D0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 tNzHs8DZDQoNClRPIElQU0VDIGRldmVsb3BlcnMuLg0KDQpJIGFtIHByb2dyYW1taW5nIGlwc2Vj IG9uIExJTlVYLiBOb3cgSSBoYXZlIGZpbmlzaGVkIG1vZGlmeWluZyBrZXJuZWwuIEJ1dCBJIGhh dmUgIGRpZmZpY3VsdGllcyBpbiBhdHRhY2hpbmcga2V5IG1hbmFnZW1lbnQgZW50aXR5Li4NCg0K SW4gUkZDIDI0MDcsIA0KICAgIDQuMy4xIEtleSBNYW5hZ2VtZW50IElzc3Vlcw0KICAgIA0KICAg ICAgIEl0IGlzIGV4cGVjdGVkIHRoYXQgbWFueSBzeXN0ZW1zIGNob29zaW5nIHRvIGltcGxlbWVu dCBJU0FLTVAgd2lsbA0KICAgICAgIHN0cml2ZSB0byBwcm92aWRlIGEgcHJvdGVjdGVkIGRvbWFp biBvZiBleGVjdXRpb24gZm9yIGEgY29tYmluZWQgSUtFDQogICAgICAga2V5IG1hbmFnZW1lbnQg ZGFlbW9uLiAgT24gcHJvdGVjdGVkLW1vZGUgbXVsdGl1c2VyIG9wZXJhdGluZw0KICAgICAgIHN5 c3RlbXMsIHRoaXMga2V5IG1hbmFnZW1lbnQgZGFlbW9uIHdpbGwgbGlrZWx5IGV4aXN0IGFzIGEg c2VwYXJhdGUNCiAgICAgICBwcml2aWxlZ2VkIHByb2Nlc3MuDQoNCiAgICAgICBJbiBzdWNoIGFu IGVudmlyb25tZW50LCBhIGZvcm1hbGl6ZWQgQVBJIHRvIGludHJvZHVjZSBrZXlpbmcgbWF0ZXJp YWwNCiAgICAgICBpbnRvIHRoZSBUQ1AvSVAga2VybmVsIG1heSBiZSBkZXNpcmFibGUuICBUaGUg SVAgU2VjdXJpdHkNCiAgICAgICBhcmNoaXRlY3R1cmUgZG9lcyBub3QgcGxhY2UgYW55IHJlcXVp cmVtZW50cyBmb3Igc3RydWN0dXJlIG9yIGZsb3cNCiAgICAgICBiZXR3ZWVuIGEgaG9zdCBUQ1Av SVAga2VybmVsIGFuZCBpdHMga2V5IG1hbmFnZW1lbnQgcHJvdmlkZXIuDQoNCg0KDQoNCmFib3Zl IHRoaXMsIGtleSBtYW5hZ2VtZW50IHByb2dyYW0gc2hvdWxkIGJlIGEgc2VwYXJhdGUgcHJvY2Vz cyBhbmQgYSBmb3JtIG9mIGRhZW1vbiBhbmQgSVBTRUMgcHJvZ3JhbSBzaG91bGQgaW5jbHVkZSBr ZXJuZWwgcHJvZ3JhbS4gDQoNCmtleSBtYW5hZ2VtZW50IHByb2dyYW0gY29uc2lzdHMgb2YgY2xp ZW50IGFuZCBzZXJ2ZXIuIEFuZCB3aGVuIG5lZWRlZCwgaXBzZWMgcHJvZ3JhbSBtdXN0IGJlIGFi bGUgdG8gY2FsbCBrZXkgbWFuYWdlbWVudCBjbGllbnQgaW4gb3JkZXIgdG8gbmVnb3RpYXRlIGtl eSBhbmQgc28gb24uDQoNClNvIGluIG9yZGVyIHRoYXQga2VybmVsIHByb2dyYW0gY2FsbHMgdXNl ciBwcm9ncmFtLCBpdCBzZWVtcyB0byBiZSBuZWVkZWQgYSBmb3JtYWxpemVkIEFQSS4NCg0KYnV0 IEkgZG9uJ3Qga25vdyBob3cgYSBwYXJ0IG9mIGtlcm5lbCBjYW4gY2FsbCB1c2VyIHByb2dyYW0g YW5kIGhvdyB0byBkZXNpZ24gYSBmb3JtYWxpemVkIEFQSS4NCg0KSSBuZWVkIHlvdXIgYWR2aWNl cyBhYm91dCByZWZlcmVuY2UgYm9va3MgYW5kIHlvdXIgaWRlYS4uDQoNCkhlbHAgbWUhIQ0KDQoN Cg0KVGhhbmsgeW91ISENCg0KDQoNCg0KDQo= ------=_NextPart_001_0048_01BF95C9.744690D0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT603MezwNk8L1RJVExFPg0KPE1FVEEgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZT48QkFTRSANCmhyZWY9ImZpbGU6Ly9DOlxQcm9ncmFtIEZpbGVzXENvbW1vbiBGaWxlc1xNaWNy b3NvZnQgU2hhcmVkXFN0YXRpb25lcnlcIj4NCjxTVFlMRT5CT0RZIHsNCglDT0xPUjogIzk5MzMw MDsgRk9OVC1GQU1JTFk6ICKxvLiyIiwgIkd1bGltIjsgRk9OVC1TSVpFOiAxMHB0OyBNQVJHSU4t TEVGVDogMTVweDsgTUFSR0lOLVRPUDogMjVweA0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEgY29udGVu dD0iTVNIVE1MIDUuMDAuMjkyMC4wIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBiYWNr Z3JvdW5kPWNpZDowMDQ2MDFiZjk1N2UkMDQ1MTJkMzAkOWMzNWZjY2JAc2xvd2YgYmdDb2xvcj0j ZmZmZmZmPg0KPENFTlRFUj48SU1HIGFsaWduPWJvdHRvbSANCnNyYz0iY2lkOjAwNDUwMWJmOTU3 ZSQwNDQzNzE5MCQ5YzM1ZmNjYkBzbG93ZiI+PC9DRU5URVI+DQo8UD48L1A+DQo8RElWPlRPIElQ U0VDIGRldmVsb3BlcnMuLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SSBhbSBwcm9n cmFtbWluZyBpcHNlYyBvbiBMSU5VWC4gTm93Jm5ic3A7SSBoYXZlIGZpbmlzaGVkIG1vZGlmeWlu ZyBrZXJuZWwuIA0KQnV0IEkgaGF2ZSZuYnNwOyBkaWZmaWN1bHRpZXMgaW4gYXR0YWNoaW5nIGtl eSBtYW5hZ2VtZW50IGVudGl0eS4uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5JbiBS RkMgMjQwNywgPC9ESVY+DQo8UD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs0LjMuMSBLZXkgTWFu YWdlbWVudCBJc3N1ZXM8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KPEJSPiZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsgSXQgaXMgZXhwZWN0ZWQgdGhhdCBtYW55IHN5c3RlbXMgY2hvb3Np bmcgdG8gDQppbXBsZW1lbnQgSVNBS01QIHdpbGw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOyBzdHJpdmUgdG8gcHJvdmlkZSBhIA0KcHJvdGVjdGVkIGRvbWFpbiBvZiBleGVjdXRp b24gZm9yIGEgY29tYmluZWQgSUtFPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNw OyBrZXkgbWFuYWdlbWVudCBkYWVtb24uJm5ic3A7IE9uIHByb3RlY3RlZC1tb2RlIG11bHRpdXNl ciANCm9wZXJhdGluZzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHN5c3RlbXMs IHRoaXMga2V5IG1hbmFnZW1lbnQgZGFlbW9uIA0Kd2lsbCBsaWtlbHkgZXhpc3QgYXMgYSBzZXBh cmF0ZTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHByaXZpbGVnZWQgDQpwcm9j ZXNzLjxCUj48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyBJbiBzdWNoIGFuIGVu dmlyb25tZW50LCBhIDxGT05UIA0KY29sb3I9IzAwMDBmZiBmYWNlPSJBcmlhbCBHcmVlayI+PFNU Uk9ORz48RU0+Zm9ybWFsaXplZCBBUEkgDQo8L0VNPjwvU1RST05HPjwvRk9OVD50byBpbnRyb2R1 Y2Uga2V5aW5nIG1hdGVyaWFsPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyBp bnRvIHRoZSBUQ1AvSVAga2VybmVsIG1heSBiZSBkZXNpcmFibGUuJm5ic3A7IFRoZSBJUCANClNl Y3VyaXR5PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgYXJjaGl0ZWN0dXJlIGRv ZXMgbm90IHBsYWNlIGFueSANCnJlcXVpcmVtZW50cyBmb3Igc3RydWN0dXJlIG9yIGZsb3c8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyBiZXR3ZWVuIGEgDQpob3N0IFRDUC9JUCBr ZXJuZWwgYW5kIGl0cyBrZXkgbWFuYWdlbWVudCBwcm92aWRlci48QlI+PC9QPg0KPFA+Jm5ic3A7 PC9QPg0KPFA+YWJvdmUgdGhpcywga2V5IG1hbmFnZW1lbnQgcHJvZ3JhbSBzaG91bGQgYmUgYSBz ZXBhcmF0ZSBwcm9jZXNzIGFuZCBhIGZvcm0gb2YgDQpkYWVtb24gYW5kIElQU0VDIHByb2dyYW0g c2hvdWxkIGluY2x1ZGUga2VybmVsIHByb2dyYW0uIDwvUD4NCjxQPmtleSBtYW5hZ2VtZW50IHBy b2dyYW0gY29uc2lzdHMgb2YgY2xpZW50IGFuZCBzZXJ2ZXIuIEFuZCB3aGVuIG5lZWRlZCwgaXBz ZWMgDQpwcm9ncmFtIG11c3QgYmUgYWJsZSB0byBjYWxsIGtleSBtYW5hZ2VtZW50IGNsaWVudCBp biBvcmRlciB0byBuZWdvdGlhdGUga2V5IGFuZCANCnNvIG9uLjwvUD4NCjxQPlNvIGluIG9yZGVy IHRoYXQga2VybmVsIHByb2dyYW0gY2FsbHMgdXNlciBwcm9ncmFtLCBpdCBzZWVtcyB0byBiZSBu ZWVkZWQgYSANCmZvcm1hbGl6ZWQgQVBJLjwvUD4NCjxQPmJ1dCBJIGRvbid0IGtub3cgaG93IGEg cGFydCBvZiBrZXJuZWwgY2FuIGNhbGwgdXNlciBwcm9ncmFtIGFuZCBob3cgdG8gZGVzaWduIA0K YSBmb3JtYWxpemVkIEFQSS48L1A+DQo8UD5JIG5lZWQgeW91ciBhZHZpY2VzIGFib3V0IHJlZmVy ZW5jZSBib29rcyZuYnNwO2FuZCB5b3VyIGlkZWEuLjwvUD4NCjxQPkhlbHAgbWUhITwvUD4NCjxQ PiZuYnNwOzwvUD4NCjxQPlRoYW5rIHlvdSEhPC9QPg0KPFA+PEJSPjxCUj4mbmJzcDs8L1A+PC9C T0RZPjwvSFRNTD4NCg== ------=_NextPart_001_0048_01BF95C9.744690D0-- ------=_NextPart_000_0047_01BF95C9.7441FCF0 Content-Type: image/gif; name="=?ks_c_5601-1987?B?tNzHs8DZILnos8ouZ2lm?=" Content-Transfer-Encoding: base64 Content-ID: <004501bf957e$04437190$9c35fccb@slowf> R0lGODlhWAI8ANX/AP+ZM/9mAMzMM8yZZsyZM8yZAMxmZsxmM8xmAMwzM8wzAMDAwJmZZpmZM5mZ AJlmZplmM5lmAJkzZpkzM5kzAJkAAGZmZmZmM2ZmAGYzZmYzM2YzAGYAADNmMzMzMzMzADMAMzMA AAAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAAsALAAAAABYAjwAQAb/wIVw SCwaj0hh4PFIOp/QqHRKrVqv2Kx2y+16v+CweEwum0foywVigajfl8ca/pbT7+/DW3Ph3+V2eG5q gYN0g2yGcXN4go11i42Kaol/jHSBj5qElpKQlI5rbXByk5aZoIqAj26ti6aIo5ibd6azqHCGhaGV kLakl7OQuG+TvcC2xJq/xYeyyHjKrJurnpygtZTPx6+0zZrVF2jjIw8Wn3cWTBQIEe7vFPEUEfPv CBQAEQjt7+788PLcVVDjp8+bZ3AQYrLlhg8Ec4P8nNNwTtsyQhDcVGT08BefBxAy1HkoxyHITBuv FdTkh9tBZmrU6crER6TBiARF0QIEgY+F/5VxWrWRkxKkzaBMbkLMeWHiRjbeWiqMCbMpSIJXKTKt 46cgVG/m0NGRuSfo0ZMl1yw1WFFkRTZAr+Ihm9PoSJAtHxQ82XCiTlpSbU3dRDfoR7nA1PYMJo5c uY2Z3ClwV4+eP3sFDhAgMJlfhQIQIhygHGHAAQcQEDgoEKEzhAMcPHyQTduDBtt9ftZdHHN34j6Z ThpkqjuhK4N4m/4ZJPzt1uFyVeVs8zYrZEZAMVX8KD0dJb3I4QA9lwHu2ONebxpK2dRPoOJMo5N6 OHw4fKrYwW0P+juhNveNDHVTI6U8F8d10aAnHkbYYGSOT/YVtF9SFdmhkYJl8bfGSu4xl/8hNPVF M+Ev9zVF33BHqRXJSISAZ5xjI1CS0VjK8VOAappBQAACN+pDwGjzyMPPPhEQUEADBOhjmT4QFOAA Ag2086MCDdA2Wx/ZSbighLbw0VUkBe01H04zqnEUhMD1Nx9HIDXU2yF2hBPUIKMANYlEH/knTV2I EaWWmCMZciFKX3V0UHvs8YdIm9NB5Z6LK87ZjJ104BnpOajkxRsc5ZW0XqSMUtKShoeGdc1ybJYJ IHQPTJCol2pykmhSzMXVS0etihVqnYds+aaJXCIFU3NlbQRhIDCW6ZZyBO3jgJEOVHbZBh54sMGS Qv4zWQRO3hNBBQG1piQ7EWww220f3Jb/Iazh5SRRWYGwe868+dFohwYnUlXdJBUlSlVaOBl3r3LH 9YZKvqSE6R95Mu53mCmY7hGqnrmYyOhiGnWF8Fz0OWRgWngZai+c0Sh8KMNrfKUcvh/fOrEwxYh8 FMqXZGfxgCEuwp0Gwp0aIr0Z7ZdOx4zd7LFVEEeq4h9fvtviXoloxW5GA/8l8tJwwIhcxia2YQgf tllZ22yWxUOP2RQoEBAFss02Gwjnnlvt3LLd5kFZHQ7MhFZIobS1Lk9h8ihFIZlYJicimXT4QXyv aHOpAXMVk152eZ0TfcXh+iuzoGjJUL2Q+ER54Rb6xlZHiszbuMqEgc6J6DwXbrlS7X13/2JKKVU1 yjmDpPg6sJXjlBSsJAXsVDH+TpMzRnyf5Ffvyv2E4E3Sf7N86HGM7paqKj7FRMEmzndsNkcjRqBB 45hRBAPg0iPEAxE0oP789Ndv//3456///vz37///SUAABABIwAIa8IAITKACF8hALozjPG6omvfM ZzA6EIBDlTHbt8xWHwEZDhcebNwiKBhBVASHQBiyWPIsJ8FifM87JnxhrxQDOg96DYQnQhOYfhVB VIEjhUNpC3/ugymfCI+CyjFhrBgUORtSbWgDQ5DT5mDCTaEFajXE3NB6aB8XIjFi/VFGcB7ShvTQ yYtJ89PmfMbErThxYzdji1h2yDkufv+sPh1ihNbCpJCMZLAy2+IWAiYQpMmww48EGECQ0sZIdvyR HkOiAJbYJZ4S5cQmebpA4jp4tZdEkW9f8hsp5pU67v2GkjpkUfZ8IsJDubEsmIzEURRBya0B6l/T 4ZvQ8BXFQiWnN8aCGSWHArEcImouHwpmLO0wy0oxZTyx64OH2MK3WEaOcI+YXVzw5sliFoib7VqJ NoV5R3dVg5X+CuavalKXN1WNMV9KneC+M53GkMOUvGuJGyZgowP4UzSaeUcBWHO2doRmH6n5xwEQ MBooNVQzBPjAB0BQm7pV65nDyaRBbGYrQRjxfO3Sl+26SC+OAcwvDQqm0NSExEjJSzn/ZwFngBwn w04sJJUMQoomBHS0be6skyxNhq+ip8k5SvNj30QdSF2oLE7lInm47OksHNKTnrmUpPj6is2CeDSB 4aymMMspObOTHO7sLkMkOccELEJDetIBRifMhZLo4QBujaZbTdoMAipgSEdSgDWrAU079hGks4kr AqFhB4/cpoEO3I1zH/XPwypEVOSoMa7nWQ4rF+KgioXIiJ5KzKrUEloVRS4aC1krG/GzOEiNJ3od jRykcFmfEi6oUllRRdAyGpPYGiisQVGt0lg7HBIRjSHfjMv0OHvaPLLsLii11JseJpZRnNZMJ5ot QTr2NZJdl5wgUS2hxJdEV/LmYHHS/y5ItNYKVIDxApB0wAF6IlG4VYts8shvP/hRDwy4zQMhuEA8 MJDfe0i0WtTKDThaGomUwIqyTIVKJgwlwhA2IylGxYgslJqzlk4YMYvJHVh/gynICM0uDgIZpD4s qK08UU/XmdVxOAwgyKw4FyBOZfGWWuI6eK8v6HhtcHLMCQq+d7htVAxOqEMKvUDmF8RQ43w2HJek nuSWbd0Q50gLkzIeZHR7SkTPRAie98LozGhOM5pD0I55VOAeQopHBdRM5zrb+c54zrOe98znPvv5 z4AOtKAHTehCG/rQiE60ohddvx0xoIGQjrSkJ03pSlu6gYt2zAcmkOlOe/rToA61qP9HTepSm/rU qDY0Lr4nPK4Zprx40MNW+DAPV7RiceiAyqywQeMhPm5lTC4uVjJCouGy2jfFSc6RE9S8jugmdrg+ la47sSjuXcWSwWicc4BDbDzwjLcJY5a2mQfrmRJOaBFpk1AtsutUtbp2zpznytLd7aXWIVTcgbey kXyoczeqgpjAt6/JvWwa+VvY3I72iqYtjEW5G9krkQZC0r1ex/yOdf6BgH7nilhnQoADbyBXkOC8 Nmp9Kaci1CeNGlTUjZy43vN5Z+PC0a8RztSU2FspHp9xcgUjT1UOlpFx0pmyhdyLZjrdecUUTpEJ ROTpdAQGmjoU7THvIXfaDHrRX0L/9DJV6HOKydSWJ3HSm183LS+ver4yl83e4Px3v1WvMQmCdaDf dnHB7iqNvD6SZv8yhxXRGjFRu4YITMCwS+oH2qK1UAoMwB0JJVc/xjV5J9EdfBqme8w1HyYZRtze ssrKrHlupj+0tCEis1mfUCuTOCkcJNtBabm/Ec14Xa47iemZGHPopjWRL/VLNDbSXJ8Mrcq+4A05 9pZzU7pVO+grg7fpvT/Hy9OKcfMK1lKTwT7iziHM+a3HSPFj38EOZyN7n1WHIFChNZ3ppCWIJY2S CCqtAaSmHod8fDwyM4AdXQbx+TUP/8AjXxMnCRIHXeEXTFARa4UgTcQdurA02bEN/5fTJrOTKOp3 Aa6CQvciKBEoTxnIbQjIeQeicCVWVVXRW5LCCYUyB9vECBiGcBhIFBv4CQ+4gt1wMvFyFS4iNSUo GPyWGIAHc980Ve/nVqLAd2NBg0WBDRKSRz34PLyjDUqYEN80g1shEkQYDPOygxHUc9cTKx5zNB5U Hk7VbYIHVKSBf+PCGs6iGYc3D0kSDwJUJKkhLhRAAAelAO3gT/4kABM1G20jiBdQLWJCdii4CRyW WbuxLMGRPGPWe5UCiTLydpGQfIdzQrYXCHjBYMN2dA2yb8TAHY4IDLD3XXJhhky1fNewiMYBL7ID Ko6zIp0IE7EDinNQCbfUER0SU//DEIFIZHVyRG0vc0r8UYvggFH+8h4gFTWGAWFFBi99x2DJAyvE I27xwXt9VyF7NDnPQREY0FB8+COZAT/usCMEUFhmExr6sA9JMlh5aCRNglipsSPUcl93owH62FjM Qkq+915kBnjL0V1NWDSXCBy21yCrUh4PkRc5YwFOt13+0XdapiEdMj6PUBKjwINfuH7rsmXJISfY 91x3ACgMyRv0QROn8iVF0RPqkEfQEWJBqDMb2WKuRE0YKD4Z6BWjqJFadQ0n6ZAqOYvMcUZDqYBb 0YFyYZK8eFuplBznFTByAUa48xx24I8SKYQI2XsQ0n6BU1yW4SzxyI4IIAAI8CP/bWZY26IAdcUa f8WO6sgar9EaAnSPF8VHdrQmkOIXUJiAyGEBDJgL1RZtMKmKN+OKKlVLRpeVl4A6KzVGsxhhGUlF KcgUgjIxLtGK0oQL8pRLMuY6o2I7P+kzPPghSjaZ1UN4GBaaSrZrDiF7vYOYxdJKivIcNsGDNkMf qPcyKnUJQfdsaBVhj6mXWeI4DamMb7BWkgiRUBec9vRA0QcH/sAON9IAd8gjo+EACkAA1tJm+PcP ghQB2nk2a0MZddhm/9UHHdA1xYiMGZmIy8AXzLKDu9eBj4BTrTg71LaZYXQpbsKRLHFOEplvsweL zWOK3sZy3uFz1Kafh1I4tjR7/3LCKwB6nwKaCrxyDcR0kdA4QudFKp9IgstIhVAWSszjiXSEnwfZ jCEJobI4XvnWUjmZIbpRgJmojczDjRaHZW/wJKdhD3kVARVFYAAxnYNlnvFwX9eiQe5wAPUQAoa4 jxcpoevBif94VSjZRTZIeMlHDKPJTE1JQ8+mO74HMuZBoAUnWTX5We7HHiypk1OYlOeDTf9mOw5J SwBZT6pkpsA5lTPpFBFkCmM2Ea72lNNUXO/0O7j4dH9XhNBRFkUJcJUUTp8Qfbv4S8i5p1vTp0a5 RtMFovFCdp3zQm+aLKN4k30gNm5DUbPBpEyqePTgX20zNtUCpf/FWPmIR+I3ev9pQZwep34lEoLQ dFQT+amLmX15GT5JyIqR+XPxFpO75VXuRH1A9WWm2TW4dmIg2lm1FXUyQo0J6ay3Ba0YF0KEKny0 IKw41pnEUa3CSEXE8R0txSHq93nBKJARh6/J6o0G4hJNY5yhanvv8jwbxS/M8ADtBycKRxC28QEm Ry0doAEbgDZrE4BC+gG2imD6iAG4YYhhky4fYJmWg0XkM41VcTXyqZDKQDXWV07j2iJSqTLCgQgS 81vAl2HDZStVg2Lfk1TSqKXZ010SCFwdJno5GnYcUbPLc7Or1bQBF7NP5rMYpbBWCXodNiNQIzqn t5lWZLUv2AmYcjUFaLNLCTn/ukAi9JkRGVAgLueSYQcB6UM/DBAuFKBx9PBol5a3eru3fNu3fvu3 XTC3dQu4hFu4hnu4iJu4/zMZTaC4jvu4kBu5kju5C8AAEdC4lJu5mru5nNu5SABq8ZBqoju6pFu6 pnu6qJu6qru6ePYBCcC6sBu7sju7tFu7tiu7Cjaa/VYzylp9A4IAU1sc9EqRaBezB3qtBCt6jpkh 4cqgLRoRvKNzK8O7suC7ilNULJclT5YnkcWhPvNaHlO24dYbYDhzLplOG7MSulmn1tuazGua5su9 vXu0VyVZlPkzcNRDfLSNSxm9BkKw7Eth7hsfV4cd/vuQOHM626W8Fvi+37i9/21qvB0KFOB7v4qj MqPFIc+ZBjwxMp/gW2pRRumIjfolLfPgAQ6qY93nM+wRsGWLGGYloSBmH0B1ZIlam7wkvqoUVmCl wgzGjJhlWccSprAnwzbpbfBBS9d6Fbv5wt1VxDZsPj4MZaXSHzITZBM5ZIIiETUsi1frgju2NbDo e8gEki0Dxp5HKjEcxUosYj9cxZIKsJ70E3QSQfSCLI7BDACyOBP7Ds/ERRCwATnBAWkZJBUASZC1 DJLojWD4kiA1RStsFUtcjO8bbRYmWp5EglZ4rYewyJKswa+wHtF0ftXKr2GITUMZFFhJWy8IyeDK yYL5kL1KwIdDxyNIxtnUvP+ueFul4E3l5MpdYgkQYoaWPHeXYFXtsa+S/FuxPB6zrKV7/CnQo6Ce Sggw0iF+MRTmY8KT1w/C9XF9cMiJJy2GxSMUsFJ0cZtO5iA783XWMQc5aYlmqsad7EwuohGbczDM Sq/4PM92QSep+DTujJJgJXtfu1lSd4zg4SctbJRf+SH6HM9nJ8b/PDnTvDcDnRfmA1XCIV11cZF7 M79FDFobnc+9ItHPwRxl1jes2Y9qojpzNKIxWjgAfdHrLCwaTdLyZDI7fEd8kLDruhXy9y1rWDaJ ZyQGkCSGR3mt4UiWwYcRwAGHrI+5c5q8tq28Bq4S3Fk0W2F2lyKo46V7omH/PViBM6uyY4eZWd2y 34CFSDOf68u7LIKiSrY6Y/3WMel3SYsVaX04NNtWn7cJIpQx7rzX4BbUISLW6Sq+ypYIsGCnGQZH v7K1hf3XaSJifr3Wq5jY2TR3KdKFHaE1YlccFgAk8DB5Tj1YO5IAkkEBB5AA2aIk7TAZtG0P7lB+ 85vQ5sfMSqPNj/0zJck42Ya9x5pKeeqnEza1MDTRwdtJbhq2FvHbPVe9s6h9U5ivUeRK7hXGngWG esLc4BadDX3L0vddaoLQ0XkXejqf50HJZEWj7mpM9yGMVU17vA3du71Rs/kvohzckApv35As5+M1 RT3UCKA21yJASn1IBUAB/xUwX3No1IasAGpDLguFWPfgCyp4dWdkUx1OkpRKVskKe2VNO9GVyD6I z8M2yjvRQ2PqQowwovAMCVQm47q4PKUZRrhXDFKBNwC8B0o8MCK+CC9OTx3ecJxDFH+9LAS6zDjO RdFLxSe+TtkHT0HuLspac5XKlSj+4+4CwNJ7jLVDknG9a+kVCSimfiUNCGA4PJVyzZnnHpBXD+KM Le+AJAXweKetAPPlZj/iT+lo2/xVWJ1heIeteUZrHJadhGl0U0YVTMj90HoZTK9ZJgI7kcfLrUzc 2Ysun7+GFDWqWbpCRlReEFpYgZFqKvrt2DDk6KSZXZin6Czn6ZD6PTyDov940aFosRsoJYqTzk2s LiK6Xc8rYsN27OPHSOlYk+uv7noGmUSucDFBS8r3GlTLAtQwzo6JN3nbkkgBpXh5CFAN/g4EkAA/ Qo+iUVcNkLG0oY8dkGA8jQ7tJmYcIwvbJnSSDJl07djHzRvA6kOrFa3hwEu55KkW4qAIqsBc+zhe VwpC0y9sUOItsuG7IRHEQB0drggN/xcET00GT6Lng1lvSjMCH5nZ4WxzsYn+fvGYF4GsePD8ovJY tjPVFTOUFbAF//Lw4YPOPImeRQtlgu36mVj79X8E0ABO6objIoBKElD1cJaPh/QEdZYQpQEH1rDq Yo2ZnCAPYnMwBe1Gi4H/CqIL//om142otz4sKhks0O46K8n152rPz5pkpWxd941sp2KYnYiiPCXc Yu/2zRpzcb8gz9xkwUdc5TfkHQbSfE80QgRV3EqSGrX3yJX23oD4783MPXPqklqV9wxMw1R6r+iV 4tsLGoAB/bBQmwEa8sfabnYPA8UtouGW9LAZ57gPDkUAhfhft8GPWHI5E6/wNBSoj93xI1k7O/lq AT8qkQXcmqcve3lvoAghX+GT07sNDJytWT51tfPZ8k39z1ChrMBCpkkvzQT5FqYbcUqT+Nz8AuyK WqE6DvOKZmKuchTz0wz/b38yxA0EkIvlUhwai8SLppgRFh+P5+WBNFaL/0wk0TLVJo/fLlZDZBIh ympZaB5Opdni1KidwJFpOlaehJBHAgUflPyqhJgwECIQHCIKIggaBiIYIyAgIygqIxQYHSAWIw4I KEQpDg46QxFCMTE+NDxklzqWmLSqupas4p4etL6u6obEjCD+6MCsjNDypHR5o5D4mJWY4tTqkpWX odyohZ64eakQia3Y5qx2L5DjmIWB5YwtmJ5yq6uZpe6v/eYkY3bkCrgr4uZIOWcuHpQq85j9cbeE 3EAqhRIiC0ds2jCL5rChc2evF0J38Drmo8avWjeAJzVao2YQCsJ+atIUKwnlIjExU5zBFCQIGUae RTS5GlUgFScEBAioQv+waZOlSgUceELgidFWTQVYMWpQaYOHWLyE4UJyb9k/Je3ernTXpsnauGG6 WOAjb+8Wn2ByEuwHz1u6uF+wOHloJIM1Jo1X7urS2ChDPXUwlgEDeaI0CIjXTmRLD0y7C401dKum GTMY0Kcl8uHc7HGvN7fTMfRYrnWYOaZt92kW+gzu00v2UQnd+a7mMs8tqm1GR/rL3lkOe1SsvLCG fckNZQFP0ts0YUWGBpKmS0uXSqIiOHAAtQCBRqSaUq061ZGlAqa6osoSBP7jpBINPphFrfMak0C5 83gZZyErYsJnpGQo426Ju2oSbJuBpgHvJJT+8os1fSSyTLgNcUORDJr/DiKELXkgyNDFLQgbriUp iAgRwrmy8eu7eXoMBwtfVtSsnRtZjBCkKFy6AhhtYlyIx3KuLFJKDSkUiB0uQYpHMqC49DE3hqZk J0WQqKzpSJMgRGO7Ddc0Lpn2fAsSzCiKS2+Egbgx0JIDGhHFAaYKGIACDjShwNH9CDTFAVU00WQq R98jcJSqZulAA1yC4SdK3fioDItkkqvwyoN0+0gPXfrqZ5jMWtUrosAOKSRF1pzbSQ+XbK3GiSzu XIegmJSLVaLzbC2OIi6xASqaLRDS9Vg8AjsJu23P86ULYBdrM9S3viiKp2xFyugjZdubdrqJrD3K VHGAG0JZudzQsxpd/3Ed6ZgXt+WHGLq6paPOgIazKCY/b6XzgkdMIcWBRTKxJIQPOFgEU0c1toqR /wBsVFBOIAjBrFk8uEVUEaERz6KWZ7Rolyghqu6Ixs7J5TMoP0r2YI+4gDM0ul7etZuQekYSpoFm Fq4Q1oJ+YjYqtPjDu5+pJeNLNTtLC951jW5ojZdb6rlp3nTaCcSDrhYxvCYLA3FZ0XYbLMfpvLvb bKEHJkhurb3ozO8rzniCi+qUmHoXhqmAp+ouKK74k0zM+iCERvUb2cBLOalAgao6MZCCk2OxhTfT UtJy6ZTslNU1vXaVw1bP5JLjs3VySZcLuJkd+witebGnX3+QGBa5OP/uOWTr6YDf7Q3gizOpoDaq vluzvoJP4ozUBrcm9uBT04Z4xvDhOXnByzlc790sGIPbYtCFvQ9UBzdNGHLh7z44LYzP+3Ywj1KO 4qhuXL5xUx+2Nzx/vQth5cjJj7KRLSi9xmm78lP7KKSQJXBiYgQ6VAQwcLKLmaVSGwOQxuBzCct5 wAMYoIAnOGYgFibIU7YoGN02co4JdWgc60tNy6yhN9XBJDDYKFvSiAaNNQgPiMsDIA8zYqUd8mYf FsIN/Zj2jQxqRGccMdwT2Sa49vQQaxhhmUnI0cUz8QZpR0CjBl+mJjhGqw9ZAmNNxle1tLGKjA6p 4xGpoY84ZmQ8tdv/ySGm5Trv8cRtAQxKMhj3DO6UCxIHCGGCSJegD2yghI7iSuYw5QEQJMhkmjyZ WTYwOrPQYgN1AKKznic72yVMlrCRyznUoMHeoY17fPDS2sDAs4hQBEnOcp9yfnbM7QXwPEKoYiOP gsu3MScPzkzX0phWKuWg4R+3zF4skZkcZaYNe8fY0//MgTwt7dB9lZnLJFkSpdn97hjddN44CwGR f43qIfwUFTHekiJEek9r35FZ2D7SLIF1hnFVwNlyeJEyWcyQdCz0QAkxB7pNTAWEoxSlJjFpSlOe 7AKz8EvP0McTZiHNiuaBqLGoNZrdLcNxHBmOWs5mpG82c6HUBNQU/x9Em5qgy00G4akylkgdv8Tk CyFxVu70Bg2jUqinX/wp2qCApzLojYzNgyVSneRONFhRGjs9l2okkhPOGEx/TLWp35qqIZwQgo1U DY5PmYed2Dnjh7fb3V2ggQhlKsFPghRTFj6VoIla9FNMEJknMYe5D4T0lBYtyyZXGQsWfjOIGfxn 0WDSEnfKJE1ElVIaEIPOwBrCrdQzJ0bkuc0AsiMOqGGTvYrVOMOFhDwp9a1sDRvECd3ETX795W+O A1NzZjGRMqutZ5S02vNZyF3cg61zIyNccn5mrsaFR9B0EhRhYM0hLVXtL4kLO+QRC6VC8hBW+TqM bhnruMPs69eM4LMn/e6Xv/v9AFciG+D+DpjABTbwgRGcYAUvmMENdvCDIRxhCU+YwhW28IUxnGEN b1gEsNhYRquyYRGPmMQlNvGJUZxiFa+YxS1O8AJgHGMZz5jGNbZxjCvxKAYswFEQuPGPgRxkIQ+Z yEU28pGRnGQlL5nJTXbyk6EcZSlPmcpVtvKVq0yVCsSYAlj28pfBHGYxj5nMZTbzmdGcZjUDmQGO 2vGa4RxnOc+ZznW2853xnOQgAAA7 ------=_NextPart_000_0047_01BF95C9.7441FCF0 Content-Type: image/jpeg; name="=?ks_c_5601-1987?B?tNzHs8DZILnosOYuanBn?=" Content-Transfer-Encoding: base64 Content-ID: <004601bf957e$04512d30$9c35fccb@slowf> /9j/4AAQSkZJRgABAgEASABIAAD/7QZAUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////// //////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////////// /////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQIAAAAAAAQ AAAAAQAAAkAAAAJAAAAAADhCSU0ECQAAAAAEzwAAAAEAAACAAAAAgAAAAYAAAMAAAAAEswAYAAH/ 2P/gABBKRklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0 LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwM DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAgACAAwEiAAIRAQMR Af/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSl tcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOE w9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A 6/v5hJJLhPYlA/glwklMpKVolP3pp7p++iSldvNKR3+SRS8klK+SU+CRSSUrv5JSOEo7pT2SUpKN EpMeJSJSUr4pJdkvjykp/9Dr+QkJIShKQT8E9iUEvJJLVJStfmkPw8UvglOsH70lK+PCUd0hwl8U lK8kvhwEvNL4JKUSkEtOEklKjxS0S58vNIpKUlB+SUa6duUoSU//0evTd0/YjhL569k9iUUkktJ8 0lKSBKR5S5SUrRLVIeSY68d0lL9vimGif+KXkkpWiXhHzS4S1RUoifIJaBKdPJL4oKV5/elOmiXw SnXQpKf/0uv14SOqQ8PuSPMp7EpLulKRn5JKUkPvT88pu89+ySlJQAl/rCRjg/JJS3h+Cf8AIkkf E/gkpXKQ8kvuSmPJJStO6RSS/KkpXhPdJKfH5JJKf//T69LjQpf6yl+RPYlf6hLzSB/3JdklK8+3 glz/ABKSUapKVPilx/sSB8PklISUqNP70vxCRSSUrRJKI80vNJSu6RS5S0+SSlJcaH70pCUJKf/U 6/4JDwS+CXKexK+KRMJaz8Eo7JKV3SidTwkkQkpRPyS7pSEklK5SS8+6SSla8pJtDpx5J0lLaJz/ ALwl240SJhJSo1+HZL8qXmlqR8UlP//V67wP4JylH3pTrHfunsSkuPNL8vZLySUrlJNyU6SlJdpS Snx7d0lK158UvMfclyNO6XCSlHRIJfxSSUpIpJQkpQ1SS1kSkkp//9br5180pHZKUpjT8U9iVyUu 2iXxCWqSldvBJLTsUuP4pKV2SA/2Jo08E6SlTokEuNEklKmEkw5TwOUlK8kkvwKRSUqfx4TpkuNB 80lP/9kAOEJJTQQGAAAAAAAHAAMBAQABAQD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rv c2hvcKggNC4wAP/uACFBZG9iZQBkAAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAKBwcHCAcK CAgKDwoICg8SDQoKDRIUEBASEBAUEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM AQsMDBUTFSIYGCIUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAz/wgARCADIAMgDAREAAhEBAxEB/8QAfgABAQEBAAAAAAAAAAAAAAAAAAECBgEBAQEB AAAAAAAAAAAAAAAAAAECAxABAAICAwEBAQEAAAAAAAAAAQARECEgMDFBAkASEQACAgIDAAIDAQEB AQAAAAAAAREhMUEQUWFxgZGxwaEi0RISAQAAAAAAAAAAAAAAAAAAAJD/2gAMAwEBAhEDEQAAAO04 bikKQpAUCpAUgWyKigVIpAAi0iUJGqghQCpLRI1QkQpagiLUAtiWKZtsgBSAFJZcVpBbZIW1JAUk tsgKkUAVYlIKsRakBSLUliWkFtSSFKQUJFpKQQ1bItkgFlzVkWhDSySLQEUi2ySLbKQQKublLaRC iipAoJF0kUJGiAhVtSQi6QsQAFBEtsgUAlVGbLAaJUjVFkSyyLpIWWWRagWoIUiGrZIFIUEBSAAR aiFWWI1UgAW2SAsssKCUiipFJLbIWxLELbBJaKEhSQqxm2pVkNEEFIAqrIWJRKsikQ1UEC1JZZVi USrEKLEFhSBDVSBFWWFJZZYhS1IAW1IqRSQoEC1FJVJFJF0kqrJCwokCgKspIAWpIW1M22KkUhVS KlIIVFokW2CFiKKQFCS2xAAUgWpBVgKRFqRCikFIpEKC2wjNVEXVkEQq2ySLUW2SBRUS5soAgqgE isrtIW2QCLRcpYhVWSKCFAsSrZJSFBC0gpFIUEAWsy1FUzFAtSC25LCkiggi2S1FpIWFUhJdWQKC BAAUiKssKCWWJbYktslIUyUssspKQhq2TNagsSyxJpYWpKsSLUC25Z1LAUlJZZYUgssslosgKCFI hRZVkBf/2gAIAQIAAQUAIvB43Di8bhF6Hh84srh86Xh5wOZzewxVdD7wOm4YXsOIcXoHrM1Lx87L xeXFR5XHF4OFc71weB0OQzXI5PXUeV9dS49PvTeXIcnocXzqV03lOlw4Hk4vFYeF4ZXK++8Vyeyp XOudwjn501m8HH5kIPO8ByZXA4E+4cJ1+SuusXPnJ43yvJkzUqXfCs3moPVUeF8w7L4BisOK4h0P vQuXoWf/2gAIAQMAAQUAcMviS4RzeLyS4Rw8jqrorBmuFdd5DjWLw5cV1L0vReDvDFQxXKsuPMOa zfA51ip8hK76wOb43KzX8Liug51/EuayS+Rwrg9FcTsZceN8CXyqpfZXC+dxxfA7jFx7GEcGXB11 hyub4Xi+VcbxfKo8CVj5wDhWaycSLLwcXJkOgl8F5s8x8vi9t32LiulwcmGHi5vNcL5EOLxOFcDs qViv4nj/AP/aAAgBAQABBQB3KK1LQ9B1W2jF78XcQDTN17Bmr1CXvxdyitRN6nsps3EIaLl2hWKh GiVPJ+Xe0BlQExUPFZbELusUEFly9u4bKUZQMbpqqi1EE8w2zcQvSm4XGbt8giaxe/SmXEubC9XB uaJW2VcJ5DcLpLmiBu5VzUqEWNk1B2T6tRKgBNRqW3aSyNSyVPJphG5uqAra/wCf02Mrfsqi5Uqb H47hRPv6LN1shufKI3Wp4nhYlMZutT/NR8FuJA/UEZaT8q4tEblg6nylZRYjKouVLhcQs9+1Ladw dBSEux/WtRu0YVaNghY4ojsBuUXGfm5VwoKx7C4XL3Re58LiDA2rC6Ze/taKZQpo3PES/Z5HT+bp LGA0JPI7gVKqPjU3ZcQumWkvcqo6Ft+lrPmrqXoVjTEQuwhWKLUw3C61EH9O0d/arHsChuWQlaib u3CWWEYfkjUslVDzYlM+toanksSkbYT8iS9sWJZYRnsq5e/Y7n0bmgu1CCTxFtI7l7Z8hVexLnsq 5e7lkPPJWnR/ot3ELqaIm/I+/l3tAZThtKlXCowGts3gES7hNxahbAoqoeLqF2gwsX38ui2IkVq9 CsdzcJuVtdiP5GimDSgu7fal4qoeem4Lfj+q/RWoCYqXr40wuos/IxALt9gVKJtjcLpJRAl1Ny7H FXNxN6on27xtiteT6lyowtbh5RZdK4TdF1YXTU1VDNBdqEu4x9+XumJZu1pKW9Rj6TyAMaIaKKik fH8wd0T7dTUoi6LIeOzyXEZe7qaI1NRowWxodMNKtg0yy/Volq1csIOkYk8jcKnr+jXw1jTGKyiN 1qbsGUW0z75FpG0uErZH9UEaZdN3PIlxRh+ZqbcUWI4fV15LbTXgu9M3QrA38XXy0al0E+t2DVRQ dMfC1QzbZuOwNkbq2eRDNt//2gAIAQICBj8AHH//2gAIAQMCBj8AHH//2gAIAQEBBj8AgghaIm++ MV2SSTJ50KLfRBHRR72RtEQekkpnnQot9EEELQoO+M0j4zx5xmHonJ6Si8mInohueHV9jimS/sp/ BesnpKLIIxw+uJmOz9Mt4EnXF0U4fEiapHpD3xPHpZWeJIWuLJRk/hGOLvo9McTMwJf5x2UuJyie f0KL7P4XkvJ6hLb1x+idk9FZ0Xksqy983ronTJR/rI0ecOiiyrP0OWT+CGRvQuxlCT3sUX2eFuij 9HyOcOyPwVh5Ksh48P8A562y6XZCr1CTyubK5yfI4wfBR+xfoon/AAUWtkf6LtFYGlbREcJ9Hmyh w76KI2LTRP5Jgg+eK+yiUeo7PCinHFqCe+HBOiNEaPT50Mtyxfvj0rJKqMk6I+zwrGx9PBDJeRQf sgvHHR/Bel/klOUyfwf+jjOkTt6474slYZ6RsSX2JHheDw8If0Q8n9Ieez4ou+jMHnRCZ7zWGTsZ Z1xTzwl3sjmBp/SJxx0YJVsT70WRw5Vd8x3hkTZOyetmbRZGivxxiCMoTj5LVlkdEJiivSHxars9 I2eMnZ4uPMnjHcJHq4umXZSlH8JQp/wgcX4yH+Sl9kHpGzx8TscqCSVokh0fOSiUUdvUmBa4hokp Vxk9RD+nxOxyoFURxD/PMvAl2Qvsnok+T4IL2Or7HFMl/YiCETvjqD+kPPZaI09lE95RZGirIJeh PRZKeSxVMiQiMEZIMQxMzkuuOjJEkcQj1Ek5Jynoql4Rh8fI4/HGBw+LP6eHfhDtekdEJl6yekov JOxdmMcUy/s7POz9Dl4JOhrehVfRkjOy8E7RKsspfZZTh9nRK4/0fR1HDKV9FcRkrAv2OVSwyZ4n D4rPXGaIzGxXZDyhTkr74+clEorifwK/khZEiE4YkQSvtMkU/nifwLfZ/CcPZWNkTPpZGxLbIE5t E/k84Z/zsmP+iXo7TPT0iD+FOCBn/JLJMcOU0xtk/jh96PdlEL8EYKox9n7Q+lokrBB8kkZIwQqY qvZiyehzoS6O+ysc5Op4XWyNEFmIjfMqhmJ8I+hdbLxw7nwV42UZyekY7PETB8E6JWDw/pEEctYj RVwTEEjg8I/0hI92T3ji8HjIbvs9QlviFkTxGUdrYqzgsnKeD0vJi9lYITtlo8Z2tirOCycp4P/Z ------=_NextPart_000_0047_01BF95C9.7441FCF0-- From owner-ipsec@lists.tislabs.com Fri Mar 24 08:38:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06926; Fri, 24 Mar 2000 08:38:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03959 Fri, 24 Mar 2000 09:16:14 -0500 (EST) Date: Fri, 24 Mar 2000 09:21:58 -0500 Message-Id: <200003241421.JAA00488@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rupesh.jain@cdac.ernet.in Cc: ipsec@lists.tislabs.com Subject: Re: Q: What is advantage of tunnel mode between host to host scenrio? References: <010e01bf954b$26f772a0$2dcd09c0@nig95> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "rupesh" == rupesh writes: rupesh> Hi Please elobrate the points you are making rupesh> 1. Fewer mechanisms to implement. rupesh> Pl. explain what do you mean by fewer mechnaisms. rupesh> Instead , i think there is need to do more processing at both rupesh> ends ( like adding extra headers). What I meant is: if you're building a security gateway, you need tunnel mode. You can use tunnel mode for communication that terminates at that gateway. Transport mode would also work. But it is easier to implement only tunnel mode and use it for everything, rather than implement transport mode as well as tunnel mode. rupesh> 2. It hides the fact that you're doing host to host rupesh> communication >> rather than communication for someone else. rupesh> How it hides the fact that the communication is host to host rupesh> because the inner and outer IP header may be same. Only in rupesh> case of host having multiple NICs then this point is vaild. You cannot see the inner header (it is encrypted). So if you see tunnel mode communication, all you know is that the security gateway is sending secured traffic. You cannot tell whether that traffic comes from the security gateway (the tunnel endpoint) or from somewhere else (a node behind the security gateway). paul From owner-ipsec@lists.tislabs.com Fri Mar 24 08:38:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06927; Fri, 24 Mar 2000 08:38:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04210 Fri, 24 Mar 2000 10:12:43 -0500 (EST) Date: Thu, 23 Mar 2000 18:34:05 -0500 From: Jim Tiller X-Mailer: The Bat! (v1.41) Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <6773.000323@lucent.com> To: "Baker, Matt W" CC: ipsec@lists.tislabs.com Subject: Re: Macintosh IPSec Clients - Progress-to-date In-reply-To: <24881EF3F745D311AC6B0090276D21C209ADB7FE@FMSMSX105> References: <24881EF3F745D311AC6B0090276D21C209ADB7FE@FMSMSX105> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Matt, Compatible Systems and TimeStep have Macintosh (not positive on TimeStep, but sure about Compatible - now Cisco) -jim P.S. I'm gonna go out on a limb here, I think Altiga was working on a Mac client. Thursday, March 23, 2000, 4:19:57 PM, you wrote: BMW> All, BMW> I hate to ask a somewhat off-topic/non-technical question, but does anyone BMW> know what the state of IPSec clients for Macintosh platforms is today. I saw BMW> that their had been some activity at HUT, but doesn't look like it has grown BMW> past Alpha. I believe that this question whizzed by BMW> previously...links/redirects appreciated BMW> Matthew W. Baker From owner-ipsec@lists.tislabs.com Fri Mar 24 08:39:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA06983; Fri, 24 Mar 2000 08:39:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04191 Fri, 24 Mar 2000 10:11:43 -0500 (EST) Date: Thu, 23 Mar 2000 09:05:29 -0500 From: Jim Tiller X-Mailer: The Bat! (v1.41) Reply-To: Jim Tiller Organization: Lucent X-Priority: 3 (Normal) Message-ID: <14378.000323@lucent.com> To: akrywani@newbridge.com CC: "'IP Security List'" Subject: Re[2]: IKE Public Key Encryption In-reply-To: <319A1C5F94C8D11192DE00805FBBADDF010D13FB@exchange> References: <319A1C5F94C8D11192DE00805FBBADDF010D13FB@exchange> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Andrew, Wednesday, March 22, 2000, 6:04:54 PM, you wrote: anc> As a general comment on including the hash of the certificate/public key in anc> the message, this doesn't really provide true identity protection, since an anc> attacker could generate the same hash. To accomplish this the attacker would have to hash all possible certificates and or public keys that he thinks are relative. BUT - you have a good point, nonetheless. anc> Wouldn't it be better to use a hash of the certificate plus some session anc> info (e.g. the cookies), which would at least protect against identity anc> tracking attacks. I would actually like to see the verbiage modified slightly to hash the public 'value' used (certificate or key) and always provide that to the responder. Therefore, if your going to hash it, you should include an identifier. As far as using a cookie, wouldn't that be available to the attacker as well? Unfortunately, I cannot think of a better idea right now....it can't be Ne or ID in standard mode, or Ne, ID, or KE in revised mode. So, the point of including an identifier to protect the hash to avoid an attacker producing the same, may simply be moot. To fully protect the identity, you have to use something only known by the peers, which is usually encrypted for transit, or generated independently, such as g^xy, (but that wouldn't work for revised mode). Basically, you have a good point, but I don't know a good direction. Nonetheless, I do think the inclusion of the public value in the initiators message should be included - for scalability. -jim anc> Andrew anc> -------------------------------------- anc> Beauty with out truth is insubstantial. anc> Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Fri Mar 24 08:42:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07068; Fri, 24 Mar 2000 08:42:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04150 Fri, 24 Mar 2000 10:10:43 -0500 (EST) Date: 24 Mar 2000 06:39:34 -0000 Message-ID: <20000324063934.9497.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipsec@lists.tislabs.com Subject: Some hash timings References: <1FD60AE4DB6CD2118C420008C74C27B81D0518@baltimore.com> <006101bf830a$020c37d0$1e0101c8@ANDREWK2.TIMESTEP> <200003071655.SAA23058@torni.ssh.fi> <20000309001035.28083.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Clock cycles to hash messages of 64 bytes, 128 bytes, etc., with hash127 and the OpenSSL MD5: Library 64 128 256 512 1024 2048 Chip MHz Compiler ---------- ------------------------------- ---------------- ------------- 127 0.70 550 825 1340 2480 4667 9275 Pentium 166 gcc 2.8.1 MD5 0.9.5 1132 1523 2250 3727 6680 12583 Pentium 166 gcc 2.8.1 127 0.70 561 814 1313 2449 4583 8954 Pentium III 450 egcs 2.91.66 MD5 0.9.5 1133 1494 2267 3782 6767 12947 Pentium III 450 egcs 2.91.66 127 0.70 570 762 1148 2111 3818 7438 UltraSPARC I 167 egcs 2.91.66 MD5 0.9.5 1523 2127 3313 5703 10468 20008 UltraSPARC I 167 egcs 2.91.66 127 0.70 608 864 1375 2552 4818 9429 Alpha 21264 500 egcs 2.91.66 MD5 0.9.5 1623 2335 3795 6699 12465 23835 Alpha 21264 500 egcs 2.91.66 Timing overhead is included. Pentium and Pentium II timings are stable; UltraSPARC and Alpha timings wobble somewhat. hash127 includes a Wegman-Carter pad. The output can be used directly as an authenticator if you supply 128 new secret bits for each message. The output of MD5, even with a secret initial state, isn't usable as an authenticator. NMAC and HMAC feed the result through MD5 again, taking more time. ---Dan From owner-ipsec@lists.tislabs.com Fri Mar 24 11:15:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09981; Fri, 24 Mar 2000 11:15:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09176 Fri, 24 Mar 2000 12:44:31 -0500 (EST) Message-ID: <000f01bf95b9$9540bf00$b3323ac3@elvis.ru> From: "Valery Smyslov" To: "Paul Koning" , Cc: References: <010e01bf954b$26f772a0$2dcd09c0@nig95> <200003241421.JAA00488@tonga.xedia.com> Subject: Re: Q: What is advantage of tunnel mode between host to host scenrio? Date: Fri, 24 Mar 2000 20:51:25 +0300 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: Paul Koning To: Cc: Sent: Friday, March 24, 2000 5:21 PM Subject: Re: Q: What is advantage of tunnel mode between host to host scenrio? [...] > rupesh> How it hides the fact that the communication is host to host > rupesh> because the inner and outer IP header may be same. Only in > rupesh> case of host having multiple NICs then this point is vaild. > > You cannot see the inner header (it is encrypted). So if you see > tunnel mode communication, all you know is that the security gateway > is sending secured traffic. You cannot tell whether that traffic Actually, you cannot even tell whether it is tunnel or transport mode communication (if ESP is employed), because Next Header is also encrypted in ESP. You can only guess it using some indirect information (packet size, for example). > comes from the security gateway (the tunnel endpoint) or from > somewhere else (a node behind the security gateway). Regards, Valera. > > paul > From owner-ipsec@lists.tislabs.com Sat Mar 25 13:26:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23710; Sat, 25 Mar 2000 13:26:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12936 Sat, 25 Mar 2000 14:39:03 -0500 (EST) Message-ID: From: Claudio Lordello To: IETF-IPSec Subject: VPN identification for phase 2 exchange Date: Sat, 25 Mar 2000 14:44:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings, I am working on an IPSec implementation which is to be used in an environment that is not (at least clearly) addressed by the existing RFC's. Below I describe a) the problem itself with some background info, b) the constraints of my application, and finally c) a quick description of previous threads on issues similar to this one that I found in this mailing list. What I would like to hear from other implementors is: 1) How are other implementations out there dealing with this issue? (interoperable and/or proprietary approaches). 2) If it turns out that only proprietary solutions are being employed, is there enough interest from other implementors to define a common aproach for interoperability (I think there is an RFC which now defines a VPN identification scheme)? If work in progress already exists, pointers to it would be appreciated. I would also offer myself to write a summary of the discussions/suggestions and, if there is enough interest, even start a draft on this subject. A) The problem Background: My SG will be used in an environment where IP interfaces belong to a virtual router. In such an environment a VPN is simply a set of IP interfaces which are assigned to the same virtual router accross the ISP network. In addition, it must be possible (although not required) for all tunneled traffic to travel on common IP interfaces (these are the uplinks for the ISP network itself). The address domain for different VPN's can (and certainly will) overlap as indicated in the picture. The traffic for each VPN must be carried in distinct IPSec SA's between SG-A and SG-B although only one IKE SA will exist between them. 10.1.* 10.2.* -------+ +------+ +------+ +------- siteX | VR-1 | | | | VR-1 | siteY +--------+ | | +--------+ | | VR-0 | | | SG-A +---------------------+ SG-B | VR-2 | | (tunneled traffic) | | VR-2 +--------+ | | +--------+ siteW | | | | | | siteZ -------+ +------+ +------+ +------- 10.1.* 10.2.* Issue: Traffic from 10.1.* from siteX arrives at SG-A and triggers a phase 2 exchange (assuming one did not exist already). SG-B receives the phase 2 negotiation message with the phase 2 identity. Now SG-B has no means to tell if the intended IPSec SA is for the VR-1 or the VR-2 flows given that the VPN Identification is not included in the phase 2 exchange and the phase 2 identities are identical. B) Constraints It has been suggested in previous threads to use different SG identities for each VPN (VR) that a SG has to establish tunnels for. Unfortunately that is not a scalable solution (for the environment that my SG will be used on), so I would like to avoid that. C) Previous threads on this subject On a similar thread (November 99 - "Phase 2 ID's for different VPN's with different Address Space") it has been suggested to "use SIT_SECRECY with a defined secrecy category as the ID of the VPN". I can not understand how exactly this works as it is not completely covered in the RFC's (in fact, it is only briefly mentioned). I assume this would provide a proprietary solution to the problem. Am I right? More information on this approach would be helpful. Another thread (July 99 - "paralell vpns") does not seem to have the same definition of VPN as I have (i.e. overlapped address space does not seem to be an issue in that case) and, in addition, creating multiple IKE SA's do not seem to be an issue as well, which is not my case. Any suggestions and/or information would be greatly appreciated. Claudio Lordello. From owner-ipsec@lists.tislabs.com Sun Mar 26 02:10:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA21781; Sun, 26 Mar 2000 02:10:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA17834 Sun, 26 Mar 2000 03:42:15 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Scott G. Kelly'" Cc: "'Tero Kivinen'" , "'Ricky Charlet'" , Subject: RE: Heartbeats draft available Date: Sun, 26 Mar 2000 03:45:24 -0500 Message-Id: <000601bf96ff$a2f44e90$06dba8c0@andrewktest.timestep.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01BF96D5.BA1E4690" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <38DA52AD.FC017594@redcreek.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BF96D5.BA1E4690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Scott, For your sake, I'll present a list of requirements on Thursday. But don't be surprised if they are very similar to the goals of the draft. Negotiation is not a requirement of IPsec heartbeats; it is a requirement of good protocol design. If there are options, or if there is any possibility of needing options in the future, there should be negotiation. BTW, Tero and I discussed heartbeat usage scenarios on the IPSRA list back in November. Please see the attached message. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott G. Kelly > Sent: Thursday, March 23, 2000 12:22 PM > To: akrywani@newbridge.com > Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com > Subject: Re: Heartbeats draft available > > > akrywani@newbridge.com wrote: > > > > > > In fact, I investigated using other negotiation protocols > for heartbeat > > configuration for the simple reason that I knew that using > ISAKMP-Config as > > transport would result in a silly, straw-man (or rather > straw-protocol) > > political argument such as this one. > > Again, this misses the point: you have to explicitly specify the > requirements, because otherwise it is not clear that negotiation is > required. Only when we understand *why* negotiation is required can we > intelligently discuss protocol requirements. > > Scott > ------=_NextPart_000_0007_01BF96D5.BA1E4690 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment From: "Andrew Krywaniuk" To: "ipsra" Subject: RE: Ack-ed NOTIFY in "dangling" implementations Date: Wed, 24 Nov 1999 19:08:16 -0500 Message-ID: <319A1C5F94C8D11192DE00805FBBADDFFA89F1@exchange> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal List-Unsubscribe: > 1) Clean up the gateway SAs after the client disappears > because of the dialup-link broke down. > 2) Switch to next gateway in the gateway host list in case the > gateway is not respoding anymore. > 3) Check that other ends IKE daemon is still up and working. > 4) Detect network connection losses ASAP so they can be > reported to the user. > 5) Detect when the other end is crashed, and when we should > try to recreate our SAs to it Hi Tero, That's a pretty good requirements analysis. I say... we should support all of them. But basically this comes down to two categories: Detection: 1) Detect when the box is missing (it rebooted, the remote user hung up, the daemon is broken, the network is down). 2) Detect when the IPSec SA is missing (DELETE was lost, keymat out of synch, whatever). Resolution: 1) Cleanup memory. 2) Re-establish sa. 3) Notify user. 4) Re-route traffic. Note that most of these actions require that there be a logical distinction between clients and sgws. Currently, we do not have such a distinction. We would have to guess that the peer is a client: 1) because it uses an ipsra-specific protocol. 2) because it uses an id that is known to be a client id. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. ------=_NextPart_000_0007_01BF96D5.BA1E4690-- From owner-ipsec@lists.tislabs.com Sun Mar 26 02:25:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA22298; Sun, 26 Mar 2000 02:25:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA17856 Sun, 26 Mar 2000 04:11:08 -0500 (EST) From: Hiroshi_Hoshino@yokogawa.co.jp To: ipsec@lists.tislabs.com Subject: IPsec conformance test In-Reply-To: Your message of "Tue, 21 Mar 2000 06:52:09 -0500" <200003211152.GAA06935@trampoline.thunk.org> References: <200003211152.GAA06935@trampoline.thunk.org> X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000326181726E.Hiroshi_Hoshino@yokogawa.co.jp> Date: Sun, 26 Mar 2000 18:17:26 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 22 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk tytso> Here's the agenda that I've collected to date. If someone else has tytso> something that they would like to present, please let me know. tytso> title="TAHI IPsec conformance test suites" tytso> presentor="Hiroshi Hoshino" tytso> time=10 tytso> do_event I can run the subset of the TAHI IPsec conformance test suites in IETF47 terminal-room. You can see the detail at http://www.tahi.org/ipsec-demo/ If you are interested in the test, please send email to me. e-mail: Hiroshi_Hoshino@yokogawa.co.jp We have developed IPsec IPv6 conformance test and applied to some implementations in connectathon2000. Now we have some IPsec IPv4 conformance test (under developing). The test suites are open to the public for free. ----hoshino @ TAHI Pjt. ----http://www.tahi.org/ From owner-ipsec@lists.tislabs.com Sun Mar 26 21:44:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA21752; Sun, 26 Mar 2000 21:44:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA20377 Sun, 26 Mar 2000 22:52:42 -0500 (EST) Reply-To: From: "Sankar Ramamoorthi" To: , "'Scott G. Kelly'" Cc: "'Tero Kivinen'" , "'Ricky Charlet'" , Subject: RE: Heartbeats draft available Date: Sun, 26 Mar 2000 19:58:47 -0800 Message-ID: <000101bf97a0$c1b80f50$881410ac@NetScreen.com> 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.2910.0) Importance: Normal In-Reply-To: <000601bf96ff$a2f44e90$06dba8c0@andrewktest.timestep.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have some questions and comments. The heartbeat protocol as described does not take into account of data packets. If there is data traffic already flowing between the client and gateway, the heartbeat packets from the client-to-gateway seem reduntant - is there a way data packets can double as heartbeat packets? I also have concerns with the one-way heartbeat message. It forces negotiation of expected timeout-interval, lost-packet tolerance window and a number of other parameters between the communicating parties. This seems to add a lot of complexity to the protocol and additional administrative knobs. Heartbeat protocol is one way to detect failure of a session - but it seems to tie the failure of a transport with failure of a session. For example if the router in the transport path is down for 5 minutes should the SA's have to be renegotiated? Heartbeat protocol also seem to be a very proactive way of detecting failures. In addition it would be nice to a have an ping like mechanism which would allow a communicating party to detect failures when needed (For example if a gateway detects an SA has been inactive for a period of time, it can issue a ping to detect if the client is still active). Thanks, -- sankar -- -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Andrew Krywaniuk Sent: Sunday, March 26, 2000 12:45 AM To: 'Scott G. Kelly' Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com Subject: RE: Heartbeats draft available Hi Scott, For your sake, I'll present a list of requirements on Thursday. But don't be surprised if they are very similar to the goals of the draft. Negotiation is not a requirement of IPsec heartbeats; it is a requirement of good protocol design. If there are options, or if there is any possibility of needing options in the future, there should be negotiation. BTW, Tero and I discussed heartbeat usage scenarios on the IPSRA list back in November. Please see the attached message. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott G. Kelly > Sent: Thursday, March 23, 2000 12:22 PM > To: akrywani@newbridge.com > Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com > Subject: Re: Heartbeats draft available > > > akrywani@newbridge.com wrote: > > > > > > In fact, I investigated using other negotiation protocols > for heartbeat > > configuration for the simple reason that I knew that using > ISAKMP-Config as > > transport would result in a silly, straw-man (or rather > straw-protocol) > > political argument such as this one. > > Again, this misses the point: you have to explicitly specify the > requirements, because otherwise it is not clear that negotiation is > required. Only when we understand *why* negotiation is required can we > intelligently discuss protocol requirements. > > Scott > From owner-ipsec@lists.tislabs.com Sun Mar 26 22:04:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22048; Sun, 26 Mar 2000 22:04:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA20433 Sun, 26 Mar 2000 23:43:06 -0500 (EST) Message-ID: <38E039CA.E1085C25@redcreek.com> Date: Mon, 27 Mar 2000 20:49:14 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: SRamamoorthi@netscreen.com CC: akrywani@newbridge.com, "'Tero Kivinen'" , "'Ricky Charlet'" , ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available References: <000101bf97a0$c1b80f50$881410ac@NetScreen.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This touches on a point I've been trying to make. Depending upon what you think the requirements are, inactivity timeouts solve a large slice of this problem, yet this draft never mentions them. Also, as Sankar points out, the presence of traffic on an SA may be enough to prove that it is viable, but the draft does not seem to address this point either. An elucidation of the requirements driving this discussion is necessary, and not just for my benefit. We cannot be sure we are trying to solve the same problem unless we explicitly agree upon what the problem is. Sankar Ramamoorthi wrote: > > Hi, > > I have some questions and comments. > > The heartbeat protocol as described does not take into account of data > packets. If there is data traffic already flowing between the client > and gateway, the heartbeat packets from the client-to-gateway seem > reduntant - is there a way data packets can double as heartbeat packets? > > I also have concerns with the one-way heartbeat message. It forces > negotiation > of expected timeout-interval, lost-packet tolerance window and a number of > other parameters between the communicating parties. This seems to add a > lot of complexity to the protocol and additional administrative knobs. > > Heartbeat protocol is one way to detect failure of a session - but it seems > to tie the failure of a transport with failure of a session. > For example if the router in the transport path is down for 5 minutes > should the SA's have to be renegotiated? > > Heartbeat protocol also seem to be a very proactive way of detecting > failures. > In addition it would be nice to a have an ping like mechanism > which would allow a communicating party to detect failures when needed > (For example if a gateway detects an SA has been inactive for a period > of time, it can issue a ping to detect if the client is still > active). > > Thanks, > > -- sankar -- > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Andrew Krywaniuk > Sent: Sunday, March 26, 2000 12:45 AM > To: 'Scott G. Kelly' > Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com > Subject: RE: Heartbeats draft available > > Hi Scott, > > For your sake, I'll present a list of requirements on Thursday. But don't be > surprised if they are very similar to the goals of the draft. > > Negotiation is not a requirement of IPsec heartbeats; it is a requirement of > good protocol design. If there are options, or if there is any possibility > of needing options in the future, there should be negotiation. > > BTW, Tero and I discussed heartbeat usage scenarios on the IPSRA list back > in November. Please see the attached message. > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott G. Kelly > > Sent: Thursday, March 23, 2000 12:22 PM > > To: akrywani@newbridge.com > > Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com > > Subject: Re: Heartbeats draft available > > > > > > akrywani@newbridge.com wrote: > > > > > > > > > > In fact, I investigated using other negotiation protocols > > for heartbeat > > > configuration for the simple reason that I knew that using > > ISAKMP-Config as > > > transport would result in a silly, straw-man (or rather > > straw-protocol) > > > political argument such as this one. > > > > Again, this misses the point: you have to explicitly specify the > > requirements, because otherwise it is not clear that negotiation is > > required. Only when we understand *why* negotiation is required can we > > intelligently discuss protocol requirements. > > > > Scott > > From owner-ipsec@lists.tislabs.com Sun Mar 26 23:48:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA24115; Sun, 26 Mar 2000 23:48:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA20674 Mon, 27 Mar 2000 01:11:24 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Cc: Subject: RE: Heartbeats draft available Date: Mon, 27 Mar 2000 01:11:45 -0500 Message-Id: <000201bf97b3$bc9fc270$06dba8c0@andrewktest.timestep.com> 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 8.5, Build 4.71.2173.0 In-Reply-To: <000101bf97a0$c1b80f50$881410ac@NetScreen.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Sankar, > The heartbeat protocol as described does not take into account of data > packets. If there is data traffic already flowing between the client > and gateway, the heartbeat packets from the client-to-gateway seem > reduntant - is there a way data packets can double as > heartbeat packets? Yes, there is some redundancy, but the effect is small. The intent here is to keep the heartbeat scheduling simple, and not base it on subjective measures such as reception of traffic. (Reception of traffic can be used as a sanity check, though.) > I also have concerns with the one-way heartbeat message. It forces > negotiation > of expected timeout-interval, lost-packet tolerance window > and a number of > other parameters between the communicating parties. This > seems to add a > lot of complexity to the protocol and additional administrative knobs. Only the heartbeat interval is negotiated. The other parameters are not actually part of the protocol. The description of the other parameters is merely an implementation hint that suggests what seems to be the most logical way to decide when the connection is down "beyond a reasonable doubt". (This point applies to any heartbeat protocol, BTW, not just the one in the draft.) > Heartbeat protocol is one way to detect failure of a session > - but it seems > to tie the failure of a transport with failure of a session. > For example if the router in the transport path is down for 5 minutes > should the SA's have to be renegotiated? I can't think of any way to distinguish a failure of transport from a failure of the session. Probably yes, the SAs need to be renegotiated. However, there is a note at the end of the draft which suggests that in the case of dialup connections, we may want to preserve the SAs even though the link has gone down. This would need to be negotiated. > Heartbeat protocol also seem to be a very proactive way of detecting > failures. > In addition it would be nice to a have an ping like mechanism > which would allow a communicating party to detect failures when needed > (For example if a gateway detects an SA has been inactive for a period > of time, it can issue a ping to detect if the client is still > active). Yes, proactive was the intent. The structure of the protocol allows the sender to choose the maximum load it will accept from heartbeats and the approximate recovery time. This results in a fixed overhead for the sender and it prevents the receiver from issuing pings capriciously (e.g. every time it receives an unauthenticated invalid SPI message). Your second point is one of the exact reasons why a gateway should not issue pings without negotiation. What if the client has an inactivity timer that expires every 5 minutes, but the gateway issues a ping whenever it doesn't receive any traffic on the SA for 4 minutes. In this case, the SA will stay up forever, even though no user traffic is every being sent. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Mon Mar 27 01:19:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA26447; Mon, 27 Mar 2000 01:19:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA21025 Mon, 27 Mar 2000 02:57:08 -0500 (EST) Date: Mon, 27 Mar 2000 18:02:57 +1000 (EST) From: KokMing Subject: Availability of Public Domain/Freeware for Win32 To: ipsec@lists.tislabs.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Newsgroups: comp.dcom.vpn Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are there any opensource/freeware VPNs for Windows NT/2000? There are a number of Unix non-commercial ones around I know that Microsoft has their PPTP, but I need to know if there are any IPSEC ports to a Win32 platform. TIA, Kokming Ang FIT, Queensland University of Technology From owner-ipsec@lists.tislabs.com Mon Mar 27 02:38:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA28408; Mon, 27 Mar 2000 02:38:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA21386 Mon, 27 Mar 2000 04:08:54 -0500 (EST) Message-ID: <38DF26AC.31D12DA7@F-Secure.com> Date: Mon, 27 Mar 2000 12:15:24 +0300 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: SRamamoorthi@netscreen.com, akrywani@newbridge.com, "'Tero Kivinen'" , "'Ricky Charlet'" , ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available References: <000101bf97a0$c1b80f50$881410ac@NetScreen.com> <38E039CA.E1085C25@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The heartbeat draft seems unnecessarily complex. The easiest way the functionality could be achieved would be to do the following in phase 2 SAs: a) Monitor incoming traffic from the peer. If replay protection is enabled, any acceptable packet proves liveness. b) If no traffic is incoming (because the peer has nothing to send, or it's down, we don't know yet) we send something very much like an ICMP-EchoRequest, and expect an ICMP-EchoReply. This can also prove liveness without replay protection, provided proper usage of the sequence number field in a echo request/reply field is provided. (The actual messages sent could be real ICMP messages, or functional equivalents.) The reason this doesn't already work in all cases is that some SAs won't allow ICMP messages through. This could be fixed my updating the IKE minor version number, so that the higher version always allows echo requests/replys to be sent over any phase 2 SA, provided that the recipient is *exactly* the interface with which a connection has been negotiated. (Not another interface in the box.) Only if both peers have the minor version number that includes the capability to do this, will actual messages be sent. (Unless the SA can already handle ICMP messages, in which case no new functionality is needed.) This has some nice properties. First, there is no need to negotiate anything in addition to the minor version number. Both peers will simply hold their own timers for the peer's liveness. If the timer is about to expire, a ping will be sent. If replay protection is enabled, an echo request is enough the reset the timer on the peer that receives it. This should provide minimum traffic between the peers(?). An echo request/reply on a phase 2 SA has also another nice property. You could use it to measure the quality of service available on that particular connection. Measure the exact time when you send the echo request, then wait until you receive the corresponding reply. You can't use one-way heartbeats for this, because the clocks won't be in sync. And a phase 1 SA can't do it, because it can't take into consideration that some phase 2 SAs have more traffic than others. Besides, the problem about expired phase 1 SAs goes away. I don't see any requirement why a phase 1 SA would need a similar mechanism. If you try to use it to set up phase 2 SAs, and it's expired, you'll soon enough notice this anyway. Ari "Scott G. Kelly" wrote: > > This touches on a point I've been trying to make. Depending upon what > you think the requirements are, inactivity timeouts solve a large slice > of this problem, yet this draft never mentions them. Also, as Sankar > points out, the presence of traffic on an SA may be enough to prove that > it is viable, but the draft does not seem to address this point either. > > An elucidation of the requirements driving this discussion is necessary, > and not just for my benefit. We cannot be sure we are trying to solve > the same problem unless we explicitly agree upon what the problem is. > > Sankar Ramamoorthi wrote: > > > > Hi, > > > > I have some questions and comments. > > > > The heartbeat protocol as described does not take into account of data > > packets. If there is data traffic already flowing between the client > > and gateway, the heartbeat packets from the client-to-gateway seem > > reduntant - is there a way data packets can double as heartbeat packets? > > > > I also have concerns with the one-way heartbeat message. It forces > > negotiation > > of expected timeout-interval, lost-packet tolerance window and a number of > > other parameters between the communicating parties. This seems to add a > > lot of complexity to the protocol and additional administrative knobs. > > > > Heartbeat protocol is one way to detect failure of a session - but it seems > > to tie the failure of a transport with failure of a session. > > For example if the router in the transport path is down for 5 minutes > > should the SA's have to be renegotiated? > > > > Heartbeat protocol also seem to be a very proactive way of detecting > > failures. > > In addition it would be nice to a have an ping like mechanism > > which would allow a communicating party to detect failures when needed > > (For example if a gateway detects an SA has been inactive for a period > > of time, it can issue a ping to detect if the client is still > > active). > > > > Thanks, > > > > -- sankar -- > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Andrew Krywaniuk > > Sent: Sunday, March 26, 2000 12:45 AM > > To: 'Scott G. Kelly' > > Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com > > Subject: RE: Heartbeats draft available > > > > Hi Scott, > > > > For your sake, I'll present a list of requirements on Thursday. But don't be > > surprised if they are very similar to the goals of the draft. > > > > Negotiation is not a requirement of IPsec heartbeats; it is a requirement of > > good protocol design. If there are options, or if there is any possibility > > of needing options in the future, there should be negotiation. > > > > BTW, Tero and I discussed heartbeat usage scenarios on the IPSRA list back > > in November. Please see the attached message. > > > > Andrew > > -------------------------------------- > > Beauty with out truth is insubstantial. > > Truth without beauty is unbearable. > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott G. Kelly > > > Sent: Thursday, March 23, 2000 12:22 PM > > > To: akrywani@newbridge.com > > > Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com > > > Subject: Re: Heartbeats draft available > > > > > > > > > akrywani@newbridge.com wrote: > > > > > > > > > > > > > > In fact, I investigated using other negotiation protocols > > > for heartbeat > > > > configuration for the simple reason that I knew that using > > > ISAKMP-Config as > > > > transport would result in a silly, straw-man (or rather > > > straw-protocol) > > > > political argument such as this one. > > > > > > Again, this misses the point: you have to explicitly specify the > > > requirements, because otherwise it is not clear that negotiation is > > > required. Only when we understand *why* negotiation is required can we > > > intelligently discuss protocol requirements. > > > > > > Scott > > > -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon Mar 27 03:04:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA28734; Mon, 27 Mar 2000 03:04:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA21679 Mon, 27 Mar 2000 04:53:50 -0500 (EST) Message-ID: <38DF310D.AC47C831@redcreek.com> Date: Mon, 27 Mar 2000 19:29:41 +0930 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: akrywani@newbridge.com CC: "'Tero Kivinen'" , "'Ricky Charlet'" , ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available References: <000601bf96ff$a2f44e90$06dba8c0@andrewktest.timestep.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk wrote: > Negotiation is not a requirement of IPsec heartbeats; it is a requirement of > good protocol design. If there are options, or if there is any possibility > of needing options in the future, there should be negotiation. So, I guess you would say that tcp, udp, smtp, ftp, ip, and many other currently deployed non-negotiating protocols are poorly designed, right? I think many would argue that simplicity, as in "only that which is necessary and sufficient for meeting the intended purpose" is a truer measure of goodness with respect to protocol design. Scott From owner-ipsec@lists.tislabs.com Mon Mar 27 04:06:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA02254; Mon, 27 Mar 2000 04:06:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA21953 Mon, 27 Mar 2000 05:47:43 -0500 (EST) Message-ID: <9306F7F390AED11195DF400689242999E4ADC7@smtp.vie.travi.com> From: Strohmayer Peter Hans -BTT To: "'KokMing'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: Availability of Public Domain/Freeware for Win32 Date: Mon, 27 Mar 2000 12:54:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id FAA21950 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Cisco VPN (IPSEC) Client for Win95/98/NT4 LG, Peter Ing. Peter Hans Strohmayer TraviAustria Dep: BTT / Access Products Phone: +43 - 1 / 1766 - 2958 Fax: +43 - 1 / 688 18 91 - 2958 (+43 - 1 / 1766 - 2929) Mail: mailto:peter.strohmayer@travi.com Web: http://www.travi.com PGP: 8BF9 9810 ECA8 2650 8114 511A 2D5E 422C 273A 71C7 :-)-----Original Message----- :-)From: KokMing [mailto:km.ang@student.qut.edu.au] :-)Sent: Montag, 27. März 2000 10:03 :-)To: ipsec@lists.tislabs.com :-)Subject: Availability of Public Domain/Freeware for Win32 :-) :-) :-)Are there any opensource/freeware VPNs for Windows NT/2000? :-)There are a :-)number of Unix non-commercial ones around :-) :-)I know that Microsoft has their PPTP, but I need to know if :-)there are any :-)IPSEC ports to a Win32 platform. :-) :-)TIA, :-)Kokming Ang :-)FIT, Queensland University of Technology :-) From owner-ipsec@lists.tislabs.com Mon Mar 27 04:14:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA02441; Mon, 27 Mar 2000 04:14:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA22015 Mon, 27 Mar 2000 05:56:17 -0500 (EST) Message-ID: <38DF3FF0.963BDBC@F-Secure.com> Date: Mon, 27 Mar 2000 14:03:12 +0300 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-list Subject: CFG mode draft, please Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Could someone send me the text of the configuration mode draft, ASAP. Thanks! Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon Mar 27 05:46:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA04966; Mon, 27 Mar 2000 05:46:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA22273 Mon, 27 Mar 2000 07:23:49 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A07D@baltimore.com> From: Chris Trobridge To: SRamamoorthi@netscreen.com, ipsec@lists.tislabs.com Subject: RE: Heartbeats draft available Date: Mon, 27 Mar 2000 13:30:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Sankar Ramamoorthi [mailto:SRamamoorthi@netscreen.com] > Sent: 27 March 2000 04:59 > To: akrywani@newbridge.com; 'Scott G. Kelly' > Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com > Subject: RE: Heartbeats draft available > The heartbeat protocol as described does not take into account of data > packets. If there is data traffic already flowing between the client > and gateway, the heartbeat packets from the client-to-gateway seem > reduntant - is there a way data packets can double as > heartbeat packets? This depends on the requirements. In general there will be a phase 1 SA and some number of dependent phase 2 SAs. I think in a lot of cases that these SAs will go up/down (fail) as a group. This isn't going to be the only case though as some implementations drop phase 1s or drop individual phase 2 SAs if resource limited. In the latter case, forcing a SGW to renegotiate while resource limited isn't the kindest thing to do. If the 'atomic' failure assumption can be held then you only need traffic on any authenticated SA to satisfy yourself that remaining SAs are still up. This might mean that heartbeats only need to be sent in the absence of regular traffic. The main problem with this is that you need to associate the traffic back to the group of SAs and this might not be accounted for currently. Heartbeats are end-to-end and could be transmitted in transport mode. The phase 1 SA is essentially 'transport'. The alternative is to set up an extra ESP (tunnel or transport) SA between the peers. This is undesirable as it consumes a deal of resource for relatively little benefit. I don't think hijacking 'customer' SAs is an alternative. This would require addresses to be reserved from both ends of the SA for the keep-alive protocol. This is not possible in the general case and would cause management problems beyond the SGW. If you have a definite need to know about the status of individual SAs then you could run keep-alives down every open SA but I've already objected to this. The draft proposes that the peer periodically sends you his complete list of open SAs. I think this is much more reasonable, though it means that keep-alives must be sent regularly, regardless how much other traffic is sent. If the open-SA list is split across multiple keep-alives then the individual keep-alive messages can be kept as small as desired. > I also have concerns with the one-way heartbeat message. It forces > negotiation of expected timeout-interval, lost-packet tolerance window > and a number of other parameters between the communicating parties. This > seems to add a lot of complexity to the protocol and additional > administrative knobs. The keep-alive protocol is for the benefit of the requestor (so it can release dead resource or renegotiate). All that needs to be negotiated is the frequency at which keep-alives are to be transmitted. The remaining parameters are local to requestor. > Heartbeat protocol is one way to detect failure of a session > - but it seems to tie the failure of a transport with failure of a session. > For example if the router in the transport path is down for 5 minutes > should the SA's have to be renegotiated? These sorts of decisions are down to the equipment in question. It's not something that need be negotiated. Failure of the transport is a problem - as are intermittent transports like ISDN. The heart-beat protocol is designed to be a secure (authenticate) means for positively identifying the liveness of SAs. It can't hope to determine positively that an SA is dead. The decision on whether to maintain, drop or renegotiate an SA depends on the requirements of the user. Some users might need a high-availability service and would wish SAs to be renegotiated if the SA were quiet for a few seconds. Intermittent services like ISDN present special problems. The last thing a user will want is for the heartbeat protocol to keep the ISDN link up perpetually! I don't know whether people will want to address these issues. My thoughts are that the protocol should be capable of being able to be suspended or 'slept' to suspend or back off the keep-alives during periods when the line would be otherwise idle. > Heartbeat protocol also seem to be a very proactive way of detecting > failures. Yes, though not necessarily SA failures in particular and, if the keep-alives are easily identified, open to abuse by an attacker. It provides proof of liveness. > In addition it would be nice to a have an ping like mechanism > which would allow a communicating party to detect failures when needed > (For example if a gateway detects an SA has been inactive for a period > of time, it can issue a ping to detect if the client is still > active). There is ping already. I'm not sure of the benefit of adding more than this. An operator could attempt to ping between the various interfaces of the SGW and client. Where this is done manually there aren't the same concerns about hijacking etc. Chris > Thanks, > > -- sankar -- From owner-ipsec@lists.tislabs.com Mon Mar 27 06:40:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06498; Mon, 27 Mar 2000 06:40:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22516 Mon, 27 Mar 2000 08:12:37 -0500 (EST) Message-ID: <002c01bf97ef$df2fe860$2dcd09c0@nig95> From: "rupesh" To: "KokMing" , Subject: Re: Availability of Public Domain/Freeware for Win32 Date: Mon, 27 Mar 2000 18:55:06 +0530 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 5.00.0518.4 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk PgpNet is avilable as a opensource... link is http://www.pgpi.org/cgi/download.cgi?filename=pgp651i-win-src.zip -----Original Message----- From: KokMing Newsgroups: comp.dcom.vpn To: Date: Monday, March 27, 2000 3:51 PM Subject: Availability of Public Domain/Freeware for Win32 >Are there any opensource/freeware VPNs for Windows NT/2000? There are a >number of Unix non-commercial ones around > >I know that Microsoft has their PPTP, but I need to know if there are any >IPSEC ports to a Win32 platform. > >TIA, >Kokming Ang >FIT, Queensland University of Technology From owner-ipsec@lists.tislabs.com Mon Mar 27 07:26:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08003; Mon, 27 Mar 2000 07:26:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22764 Mon, 27 Mar 2000 08:51:46 -0500 (EST) Message-ID: <38DF6911.E8CE2D89@F-Secure.com> Date: Mon, 27 Mar 2000 16:58:41 +0300 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec-list Subject: Re: CFG mode draft, please References: <38DF3FF0.963BDBC@F-Secure.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks, got it.. Ari Ari Huttunen wrote: > > Could someone send me the text of the configuration mode > draft, ASAP. Thanks! > > Ari > > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > F-Secure Corporation http://www.F-Secure.com > > F-Secure products: Integrated Solutions for Enterprise Security -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon Mar 27 08:33:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10162; Mon, 27 Mar 2000 08:33:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23040 Mon, 27 Mar 2000 09:48:59 -0500 (EST) Message-ID: <20000327073206.8773.qmail@hotmail.com> X-Originating-IP: [196.1.109.11] From: "neha dharia" To: ipsec@lists.tislabs.com Date: Mon, 27 Mar 2000 07:32:06 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What's the diffrenc between AH and ESP Protocols? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec@lists.tislabs.com Mon Mar 27 14:29:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA16870; Mon, 27 Mar 2000 14:29:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24784 Mon, 27 Mar 2000 15:37:43 -0500 (EST) Date: Mon, 27 Mar 2000 12:34:42 -0800 (PST) From: Jan Vilhuber To: Ari Huttunen cc: "Scott G. Kelly" , SRamamoorthi@netscreen.com, akrywani@newbridge.com, "'Tero Kivinen'" , "'Ricky Charlet'" , ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available In-Reply-To: <38DF26AC.31D12DA7@F-Secure.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 27 Mar 2000, Ari Huttunen wrote: > The heartbeat draft seems unnecessarily complex. The easiest way > the functionality could be achieved would be to do the following > in phase 2 SAs: > a) Monitor incoming traffic from the peer. If replay protection is > enabled, any acceptable packet proves liveness. > b) If no traffic is incoming (because the peer has nothing to > send, or it's down, we don't know yet) we send something very > much like an ICMP-EchoRequest, and expect an ICMP-EchoReply. > This can also prove liveness without replay protection, provided > proper usage of the sequence number field in a echo request/reply > field is provided. (The actual messages sent could be real ICMP > messages, or functional equivalents.) > > The reason this doesn't already work in all cases is that some > SAs won't allow ICMP messages through. This could be fixed my > updating the IKE minor version number, so that the higher version > always allows echo requests/replys to be sent over any phase 2 SA, > provided that the recipient is *exactly* the interface with which > a connection has been negotiated. (Not another interface in the box.) > Only if both peers have the minor version number that includes > the capability to do this, will actual messages be sent. (Unless the > SA can already handle ICMP messages, in which case no new functionality > is needed.) > And you say the HAERTBEAT draft is too complex?! I'd say the above paragraph proves that what you're suggesting is even more complex ("provided ..", "unless...", etc..). Personally, I'm against using a phase 2 for keepalvies. If the user of the tunnel wants to send icmp echo's, that's they're perogative, but I am against doing this on behalf of the tunnel-user 9for lack of a better way to put it). Why? Accounting issues for one, as has been raised in the past. You use up the SA with keepalives. Say you are a reseller of ipsec services, and your customer contracted for a certain amount of traffic. You are now stealing from them to send keepalives. Yes, you could then add a keepalives option to the contract and you could all agree to do this, but then you really have to start wondering about the complexity not only in configuration but also in code to handle all the different variants of doing keepalives (send echo on same SA? different SA? Does it count as customer traffic in accounting? Does it not?). Doing the keepalives in phase one between the peers is much cleaner. jan > This has some nice properties. First, there is no need to negotiate > anything in addition to the minor version number. Both peers will simply > hold their own timers for the peer's liveness. If the timer is about to > expire, a ping will be sent. If replay protection is enabled, an echo > request is enough the reset the timer on the peer that receives it. > This should provide minimum traffic between the peers(?). > > An echo request/reply on a phase 2 SA has also another nice property. > You could use it to measure the quality of service available on that > particular connection. Measure the exact time when you send the echo > request, then wait until you receive the corresponding reply. You can't > use one-way heartbeats for this, because the clocks won't be in sync. > And a phase 1 SA can't do it, because it can't take into consideration > that some phase 2 SAs have more traffic than others. Besides, the > problem about expired phase 1 SAs goes away. > > I don't see any requirement why a phase 1 SA would need a similar > mechanism. If you try to use it to set up phase 2 SAs, and it's > expired, you'll soon enough notice this anyway. > > Ari > > "Scott G. Kelly" wrote: > > > > This touches on a point I've been trying to make. Depending upon what > > you think the requirements are, inactivity timeouts solve a large slice > > of this problem, yet this draft never mentions them. Also, as Sankar > > points out, the presence of traffic on an SA may be enough to prove that > > it is viable, but the draft does not seem to address this point either. > > > > An elucidation of the requirements driving this discussion is necessary, > > and not just for my benefit. We cannot be sure we are trying to solve > > the same problem unless we explicitly agree upon what the problem is. > > > > Sankar Ramamoorthi wrote: > > > > > > Hi, > > > > > > I have some questions and comments. > > > > > > The heartbeat protocol as described does not take into account of data > > > packets. If there is data traffic already flowing between the client > > > and gateway, the heartbeat packets from the client-to-gateway seem > > > reduntant - is there a way data packets can double as heartbeat packets? > > > > > > I also have concerns with the one-way heartbeat message. It forces > > > negotiation > > > of expected timeout-interval, lost-packet tolerance window and a number of > > > other parameters between the communicating parties. This seems to add a > > > lot of complexity to the protocol and additional administrative knobs. > > > > > > Heartbeat protocol is one way to detect failure of a session - but it seems > > > to tie the failure of a transport with failure of a session. > > > For example if the router in the transport path is down for 5 minutes > > > should the SA's have to be renegotiated? > > > > > > Heartbeat protocol also seem to be a very proactive way of detecting > > > failures. > > > In addition it would be nice to a have an ping like mechanism > > > which would allow a communicating party to detect failures when needed > > > (For example if a gateway detects an SA has been inactive for a period > > > of time, it can issue a ping to detect if the client is still > > > active). > > > > > > Thanks, > > > > > > -- sankar -- > > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Andrew Krywaniuk > > > Sent: Sunday, March 26, 2000 12:45 AM > > > To: 'Scott G. Kelly' > > > Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com > > > Subject: RE: Heartbeats draft available > > > > > > Hi Scott, > > > > > > For your sake, I'll present a list of requirements on Thursday. But don't be > > > surprised if they are very similar to the goals of the draft. > > > > > > Negotiation is not a requirement of IPsec heartbeats; it is a requirement of > > > good protocol design. If there are options, or if there is any possibility > > > of needing options in the future, there should be negotiation. > > > > > > BTW, Tero and I discussed heartbeat usage scenarios on the IPSRA list back > > > in November. Please see the attached message. > > > > > > Andrew > > > -------------------------------------- > > > Beauty with out truth is insubstantial. > > > Truth without beauty is unbearable. > > > > > > > -----Original Message----- > > > > From: owner-ipsec@lists.tislabs.com > > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott G. Kelly > > > > Sent: Thursday, March 23, 2000 12:22 PM > > > > To: akrywani@newbridge.com > > > > Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com > > > > Subject: Re: Heartbeats draft available > > > > > > > > > > > > akrywani@newbridge.com wrote: > > > > > > > > > > > > > > > > > > In fact, I investigated using other negotiation protocols > > > > for heartbeat > > > > > configuration for the simple reason that I knew that using > > > > ISAKMP-Config as > > > > > transport would result in a silly, straw-man (or rather > > > > straw-protocol) > > > > > political argument such as this one. > > > > > > > > Again, this misses the point: you have to explicitly specify the > > > > requirements, because otherwise it is not clear that negotiation is > > > > required. Only when we understand *why* negotiation is required can we > > > > intelligently discuss protocol requirements. > > > > > > > > Scott > > > > > > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > F-Secure Corporation http://www.F-Secure.com > > F-Secure products: Integrated Solutions for Enterprise Security > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Mar 27 15:00:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17518; Mon, 27 Mar 2000 15:00:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25001 Mon, 27 Mar 2000 16:36:26 -0500 (EST) Message-Id: <200003272141.NAA11338@gallium.network-alchemy.com> To: Jan Vilhuber cc: Ari Huttunen , "Scott G. Kelly" , SRamamoorthi@netscreen.com, akrywani@newbridge.com, "'Tero Kivinen'" , "'Ricky Charlet'" , ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available In-reply-to: Your message of "Mon, 27 Mar 2000 12:34:42 PST." Date: Mon, 27 Mar 2000 13:41:12 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Doing the keepalives in phase one between the peers is much cleaner. I also believe that any keepalive function should be deemed an attribute of the IKE association and not done as a Phase 2 exchange. Derrell From owner-ipsec@lists.tislabs.com Mon Mar 27 15:01:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17553; Mon, 27 Mar 2000 15:01:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25044 Mon, 27 Mar 2000 16:44:52 -0500 (EST) Date: Mon, 27 Mar 2000 13:50:45 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: ipsec mailling list Subject: RE: Heartbeats draft (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk some thoughts on Heartbeats: SPI lists: I feel that this approach to maintain synchonization between the SADs of two peers is not going to scale well. It's going to be very expensive to send the SPI list, and also check the SAD against the SPI list, as the number of SAs increase. I feel that implementing acknowledged Notifys is a much more simple and clean solution to the SA synchronization problem. Problem being solved: The major problem that is being solved here is knowing exactly when the peer went down. If we don't have heartbeats, when a peer goes down, we will continue to send encrypted traffic to the peer, and even if the peer comes back up, it is silently going to drop all the encrypted traffic (no SA). First of all, what is the probability that this situation happens? Can we say reasonably corner case. Second of all even when this happens we can change the peers behaviour to 'intellegently' start negotiating the SA with us, with the Initial Contact. I say 'intellegently' in the sense to avoid DOS attacks (but, I guess this is not a major DOS attack risk). IMHO, heartbeats would be more useful if we had a list of multiple peers which support the same trafic flow (redundancy/failover), but I guess this is getting into too much of implementation detail. It can be left to the implementations to provide this kind of redundancy. I guess there is no real customer requirement that IPSec implementations of different vendors should provide redundancy/failover across vendor implementations. Regarding the below discussion: One justification for not using a time stamp with the SPI list given is that the time may not be synchronized between the different peers. I feel that expecting IPSec peers to be able to maintain accurate time is a basic requirement for validating Certificates, and using PKI. chinna narasimha reddy pellacuru s/w engineer ---------- Forwarded message ---------- Date: Sun, 26 Mar 2000 03:25:11 -0500 From: Andrew Krywaniuk To: 'CHINNA N.R. PELLACURU' Cc: 'Tero Kivinen' Subject: RE: Heartbeats draft Good point. When comparing the SPI list with the SAD, an implementation should ignore SAs that were negotiated "recently" and SA negotiations that are still in progress. The delay attack by an intermediate router is less important because we do not claim to be able to prevent delay attacks. However, I guess that using TO_I for the above definition of "recently" would be a good practice nonetheless. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > Sent: Saturday, March 25, 2000 4:01 PM > To: akrywani@newbridge.com > Cc: 'Tero Kivinen' > Subject: Heartbeats draft > > > I feel that the SPI list specification and processing has > some problems. > > For example: > > Peer1 Peer2 > HeartBeat Sender (QM Responder) HeartBeat Receiver (QM Initiator) > Hearbeat with SPI list-----> <----- Final QM message > > Suppose Peer1 and Peer2 are negotiating a QM and Peer2 is > sending Peer1 > the fianl QM message, and Peer1 is the HeartBeat Sender. > Peer1 will not > have SPIs corresponding the QM that is being negotiated in > his SAD yet, > and so these SPIs won't be in the SPI list. But Peer2 may have just > finished processing the 2nd QM message, sends out the final > QM message, > and then installs the SAs in to it's SAD. Now when the > HeartBeat reaches > the Peer2, it won't have the SPIs for the QM that was just > negotiated, and > these SHOULD be deleted. > > I guess it is important to also communicate some sense of at > what time the > snapshot of the SAD is being sent. Or the receiver of the SA > list must be > more intelligent about deleting QM SAs that were setup just > recently (he > can probably have some upper bound on the SAs age that he > will delete in > this situation. This is useful against other kinds of simple > attacks like > someone just holding onto a legitimate HeartBeat for some time and > replaying it. The recommended timeout is 65 seconds, and if > the attacker > holds on to the packet for 60 seconds and replays it, then all the QMs > that were negotiated during that time SHOULD be deleted. The Heartbeat > packet may also arrive out of order(rarely), and may cause similar > problems with QM Sas that are being negotiated. > > > chinna narasimha reddy pellacuru > s/w engineer > > > From owner-ipsec@lists.tislabs.com Mon Mar 27 17:41:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20406; Mon, 27 Mar 2000 17:41:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25401 Mon, 27 Mar 2000 19:25:12 -0500 (EST) Reply-To: From: "Sankar Ramamoorthi" To: Cc: Subject: RE: Heartbeats draft available Date: Mon, 27 Mar 2000 16:24:56 -0800 Message-ID: <000d01bf984c$0bac7050$881410ac@NetScreen.com> 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.2910.0) Importance: Normal In-Reply-To: <000201bf97b3$bc9fc270$06dba8c0@andrewktest.timestep.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Thanks for the explanations. I have some more questions. >From: Andrew Krywaniuk [akrywani@newbridge.com] >Sent: Sunday, March 26, 2000 10:12 PM >To: SRamamoorthi@NetScreen.com >Cc: ipsec@lists.tislabs.com >Subject: RE: Heartbeats draft available > >Hi Sankar, > >> The heartbeat protocol as described does not take into account of data >> packets. If there is data traffic already flowing between the client >> and gateway, the heartbeat packets from the client-to-gateway seem >> reduntant - is there a way data packets can double as >> heartbeat packets? > >Yes, there is some redundancy, but the effect is small. The intent here is >to keep the heartbeat scheduling simple, and not base it on subjective >measures such as reception of traffic. (Reception of traffic can be used as >a sanity check, though.) > The other redundancy concern I have is about the symmetric nature of the described heartbeat protocol. Should two communicating parties have to independently negotiate heartbeat protocol if they want to ensure the other one is alive? Also is the effect really small as you describe? Consider a gateway hosting lots of clients. Eack IKE SA to the client is separate. If all clients were to send 'notify active' periodically, would'nt it add up to considerable overhead on the gateway to process the keep-alive packets, verify the hash... The scaling problem worsens if the gateway negotiates for a smaller 'notify active' time interval. Also in your draft you state that The Stateful Request/Reply Phase 1 Heartbeat: When used properly (with a sequence number and a query interval), this heartbeat mode is similar to the one described in this document. The main difference is that it requires double the bandwidth to do the same thing. Why does it require double the bandwidth? With a stateful Request/Reply protocol the sender of the request/reply message could send it only when needed - that should actually save processing time and bandwidth. With a stateful Request/Reply, all that is needed to be provided in IKE is a mechanism(echo, echo-reply). Implementations can build a 'proof-of-aliveness' check using it without needing a protocol. What am I missing? >> I also have concerns with the one-way heartbeat message. It forces >> negotiation >> of expected timeout-interval, lost-packet tolerance window >> and a number of >> other parameters between the communicating parties. This >> seems to add a >> lot of complexity to the protocol and additional administrative knobs. > >Only the heartbeat interval is negotiated. The other parameters are not >actually part of the protocol. The description of the other parameters is >merely an implementation hint that suggests what seems to be the most >logical way to decide when the connection is down "beyond a reasonable >doubt". (This point applies to any heartbeat protocol, BTW, not just the one >in the draft.) The complexity is in determining the acceptable heartbeat interval beforehand. How can the gateway determine the suitable acceptable interval to be negotiated? A time of 2 hours may look appropriate in the begining (to allow the gateway to be not overly sensitive to link, router failures..), but as the load on the system increases it may want to clean up stale SAs at a faster rate. > >> Heartbeat protocol is one way to detect failure of a session >> - but it seems >> to tie the failure of a transport with failure of a session. >> For example if the router in the transport path is down for 5 minutes >> should the SA's have to be renegotiated? > >I can't think of any way to distinguish a failure of transport from a >failure of the session. Probably yes, the SAs need to be renegotiated. >However, there is a note at the end of the draft which suggests that in the >case of dialup connections, we may want to preserve the SAs even though the >link has gone down. This would need to be negotiated. > >> Heartbeat protocol also seem to be a very proactive way of detecting >> failures. >> In addition it would be nice to a have an ping like mechanism >> which would allow a communicating party to detect failures when needed >> (For example if a gateway detects an SA has been inactive for a period >> of time, it can issue a ping to detect if the client is still >> active). > >Yes, proactive was the intent. The structure of the protocol allows the >sender to choose the maximum load it will accept from heartbeats and the >approximate recovery time. This results in a fixed overhead for the sender >and it prevents the receiver from issuing pings capriciously (e.g. every >time it receives an unauthenticated invalid SPI message). This fixed overhead is per remote peer. Is it scalable? > >Your second point is one of the exact reasons why a gateway should not issue >pings without negotiation. What if the client has an inactivity timer that >expires every 5 minutes, but the gateway issues a ping whenever it doesn't >receive any traffic on the SA for 4 minutes. In this case, the SA will stay >up forever, even though no user traffic is every being sent. > I did not get it. Why are we mixing up these pings with user traffic? If done correctly the client would see the ping from the gateway - reprime its inactivity timer and not a send a ping to the gateway. Also the inactivity timeout has no bearing on SA lifetime - right? Thanks, -- sankar -- From owner-ipsec@lists.tislabs.com Mon Mar 27 19:12:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA28282; Mon, 27 Mar 2000 19:12:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA25707 Mon, 27 Mar 2000 20:44:38 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Scott G. Kelly'" Cc: "'Tero Kivinen'" , "'Ricky Charlet'" , Subject: RE: Heartbeats draft available Date: Mon, 27 Mar 2000 20:48:06 -0500 Message-Id: <000d01bf9857$ab59a9a0$08dba8c0@andrewktest.timestep.com> 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 8.5, Build 4.71.2173.0 In-Reply-To: <38DF310D.AC47C831@redcreek.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No, I wouldn't say that (although you are wrong if you think those protocols have no negotiation -- it is just more subtle). Your notion of simplicity is utopian; it assumes that requirements will never change. The negotiation protocol is very simple and precise, and at the very least it provides a mechanism for forwards compatibility. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Scott G. Kelly > Sent: Monday, March 27, 2000 5:00 AM > To: akrywani@newbridge.com > Cc: 'Tero Kivinen'; 'Ricky Charlet'; ipsec@lists.tislabs.com > Subject: Re: Heartbeats draft available > > > Andrew Krywaniuk wrote: > > > > > Negotiation is not a requirement of IPsec heartbeats; it is > a requirement of > > good protocol design. If there are options, or if there is > any possibility > > of needing options in the future, there should be negotiation. > > So, I guess you would say that tcp, udp, smtp, ftp, ip, and many other > currently deployed non-negotiating protocols are poorly > designed, right? > I think many would argue that simplicity, as in "only that which is > necessary and sufficient for meeting the intended purpose" is a truer > measure of goodness with respect to protocol design. > > Scott > From owner-ipsec@lists.tislabs.com Mon Mar 27 19:43:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA00595; Mon, 27 Mar 2000 19:43:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25884 Mon, 27 Mar 2000 21:30:32 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Chris Trobridge'" , , Subject: RE: Heartbeats draft available Date: Mon, 27 Mar 2000 21:25:53 -0500 Message-Id: <001301bf985c$f2f21db0$08dba8c0@andrewktest.timestep.com> 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 8.5, Build 4.71.2173.0 In-Reply-To: <1FD60AE4DB6CD2118C420008C74C27B854A07D@baltimore.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Chris, > If the 'atomic' failure assumption can be held then you only > need traffic on > any authenticated SA to satisfy yourself that remaining SAs > are still up. ... > The main problem with this is that you need > to associate > the traffic back to the group of SAs and this might not be > accounted for > currently. Yes, and this is a problem specifically in the case of load sharing. A simple ping on a phase 2 is not load-sharing aware. The heartbeats draft assumes that the IKE daemon can find out which IPsec SAs are running on which hosts. > I don't think hijacking 'customer' SAs is an alternative. This would > require addresses to be reserved from both ends of the SA for > the keep-alive > protocol. This is not possible in the general case and would cause > management problems beyond the SGW. I agree. *IF* the WG is willing to designate certain SAs as "management only" SAs and they can be clearly identified as such, so that an implementation can apply one set of traffic-processing rules to those SAs and a different set of rules for "normal" SAs, then I might be willing to standardize a phase 2 heartbeat protocol. But that's a big *IF*, and I don't see any movement in that direction from the WG. > These sorts of decisions are down to the equipment in > question. It's not > something that need be negotiated. Failure of the transport > is a problem - > as are intermittent transports like ISDN. The heart-beat protocol is > designed to be a secure (authenticate) means for positively > identifying the > liveness of SAs. It can't hope to determine positively that > an SA is dead. > The decision on whether to maintain, drop or renegotiate an > SA depends on > the requirements of the user. Some users might need a > high-availability > service and would wish SAs to be renegotiated if the SA were > quiet for a few > seconds. > Intermittent services like ISDN present special problems. > The last thing a > user will want is for the heartbeat protocol to keep the ISDN link up > perpetually! I don't know whether people will want to > address these issues. > My thoughts are that the protocol should be capable of being > able to be > suspended or 'slept' to suspend or back off the keep-alives > during periods > when the line would be otherwise idle. Yes, this is true. In fact, we purposely left hooks in the draft (see future considerations 1 & 2) for this scenario. The reason I did not include a proposal on how to solve this case is that I am not yet sure what the best solution is. I have heard a few comments from vendors who are concerned about this scenario, but I would like to see a bit more discussion before we finalize on a solution. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Mon Mar 27 20:13:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA02908; Mon, 27 Mar 2000 20:13:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA25926 Mon, 27 Mar 2000 21:45:50 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'CHINNA N.R. PELLACURU'" , "'ipsec mailling list'" Subject: RE: Heartbeats draft (fwd) Date: Mon, 27 Mar 2000 21:49:38 -0500 Message-Id: <001401bf9860$4469a5c0$08dba8c0@andrewktest.timestep.com> 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 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Chinna, > SPI lists: I feel that this approach to maintain > synchonization between > the SADs of two peers is not going to scale well. It's going > to be very > expensive to send the SPI list, and also check the SAD against the SPI > list, as the number of SAs increase. I feel that implementing > acknowledged > Notifys is a much more simple and clean solution to the SA > synchronization > problem. I assume that you are advocating sending an acknowledged notify every time you receive an invalid SPI message? The problem with this is that it is too promiscuous in allowing an attacker to elicit a response from a spoofed message. Let me suggest that you instead keep track of the invalid SPIs you receive during a heartbeat interval then send SPI lists for each one in the your next heartbeat message. (But up to a certain maximum, since you don't want to allow the attacker to suck up all your memory.) > Problem being solved: The major problem that is being solved here is > knowing exactly when the peer went down. If we don't have > heartbeats, when > a peer goes down, we will continue to send encrypted traffic > to the peer, > and even if the peer comes back up, it is silently going to > drop all the > encrypted traffic (no SA). But that's what the basic heartbeat protocol is for. The SPI list is an optional payload that performs an additional function (SAD synchronization). If you just want to know when the peer as a whole is dead, then don't request to receive the SPI list. > Regarding the below discussion: One justification for not using a time > stamp with the SPI list given is that the time may not be synchronized > between the different peers. I feel that expecting IPSec > peers to be able > to maintain accurate time is a basic requirement for validating > Certificates, and using PKI. Yes. This is one of the issues I was planning to bring up at the meeting. The difference between validating heartbeats and validating certificates is that for heartbeats, the time has to be synchronized within a few seconds (whereas the requirements for validating certificates are not necessarily so rigid). Also, certificates are administered by an SA, so it is clear that the time on the certificate is based on the CA's time. Heartbeats do not require PKIs, and they are not bound to a particular CA time; therefore, there is room for confusion. One thing I considered is that the receiver could ask the sender to send him the current time (encoded as a second count... presumably in the C standard library format). Then the sender would store the offset between the two times. Comments, anyone? Would this be better than using sequence numbers? Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of CHINNA > N.R. PELLACURU > Sent: Monday, March 27, 2000 4:51 PM > To: ipsec mailling list > Subject: RE: Heartbeats draft (fwd) > > > some thoughts on Heartbeats: > > SPI lists: I feel that this approach to maintain > synchonization between > the SADs of two peers is not going to scale well. It's going > to be very > expensive to send the SPI list, and also check the SAD against the SPI > list, as the number of SAs increase. I feel that implementing > acknowledged > Notifys is a much more simple and clean solution to the SA > synchronization > problem. > > Problem being solved: The major problem that is being solved here is > knowing exactly when the peer went down. If we don't have > heartbeats, when > a peer goes down, we will continue to send encrypted traffic > to the peer, > and even if the peer comes back up, it is silently going to > drop all the > encrypted traffic (no SA). First of all, what is the > probability that this > situation happens? Can we say reasonably corner case. Second > of all even > when this happens we can change the peers behaviour to 'intellegently' > start negotiating the SA with us, with the Initial Contact. I say > 'intellegently' in the sense to avoid DOS attacks (but, I > guess this is > not a major DOS attack risk). > > IMHO, heartbeats would be more useful if we had a list of > multiple peers > which support the same trafic flow (redundancy/failover), but > I guess this > is getting into too much of implementation detail. It can be > left to the > implementations to provide this kind of redundancy. I guess > there is no > real customer requirement that IPSec implementations of > different vendors > should provide redundancy/failover across vendor implementations. > > Regarding the below discussion: One justification for not using a time > stamp with the SPI list given is that the time may not be synchronized > between the different peers. I feel that expecting IPSec > peers to be able > to maintain accurate time is a basic requirement for validating > Certificates, and using PKI. > > chinna narasimha reddy pellacuru > s/w engineer > > ---------- Forwarded message ---------- > Date: Sun, 26 Mar 2000 03:25:11 -0500 > From: Andrew Krywaniuk > To: 'CHINNA N.R. PELLACURU' > Cc: 'Tero Kivinen' > Subject: RE: Heartbeats draft > > Good point. When comparing the SPI list with the SAD, an > implementation > should ignore SAs that were negotiated "recently" and SA > negotiations that > are still in progress. > > The delay attack by an intermediate router is less important > because we do > not claim to be able to prevent delay attacks. However, I > guess that using > TO_I for the above definition of "recently" would be a good practice > nonetheless. > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > > > -----Original Message----- > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > Sent: Saturday, March 25, 2000 4:01 PM > > To: akrywani@newbridge.com > > Cc: 'Tero Kivinen' > > Subject: Heartbeats draft > > > > > > I feel that the SPI list specification and processing has > > some problems. > > > > For example: > > > > Peer1 Peer2 > > HeartBeat Sender (QM Responder) HeartBeat Receiver (QM Initiator) > > Hearbeat with SPI list-----> <----- Final QM message > > > > Suppose Peer1 and Peer2 are negotiating a QM and Peer2 is > > sending Peer1 > > the fianl QM message, and Peer1 is the HeartBeat Sender. > > Peer1 will not > > have SPIs corresponding the QM that is being negotiated in > > his SAD yet, > > and so these SPIs won't be in the SPI list. But Peer2 may have just > > finished processing the 2nd QM message, sends out the final > > QM message, > > and then installs the SAs in to it's SAD. Now when the > > HeartBeat reaches > > the Peer2, it won't have the SPIs for the QM that was just > > negotiated, and > > these SHOULD be deleted. > > > > I guess it is important to also communicate some sense of at > > what time the > > snapshot of the SAD is being sent. Or the receiver of the SA > > list must be > > more intelligent about deleting QM SAs that were setup just > > recently (he > > can probably have some upper bound on the SAs age that he > > will delete in > > this situation. This is useful against other kinds of simple > > attacks like > > someone just holding onto a legitimate HeartBeat for some time and > > replaying it. The recommended timeout is 65 seconds, and if > > the attacker > > holds on to the packet for 60 seconds and replays it, then > all the QMs > > that were negotiated during that time SHOULD be deleted. > The Heartbeat > > packet may also arrive out of order(rarely), and may cause similar > > problems with QM Sas that are being negotiated. > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Mon Mar 27 21:56:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA08178; Mon, 27 Mar 2000 21:56:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26186 Mon, 27 Mar 2000 23:33:02 -0500 (EST) Message-ID: <003801bf9870$75ea1f20$2dcd09c0@nig95> From: "rupesh" To: "neha dharia" , Subject: Re: Date: Tue, 28 Mar 2000 10:15:35 +0530 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 5.00.0518.4 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 1) AH is Authentication Header : It provides only Authentication & no Encryption. It provides Authentication to both IP layer as well as Upper layer protocols. 2) ESP is Encapsulation Security Payload : It provides optional Authentication as well as optional Encryption. One of the service MUST be selected. It provides these services Upper layer protocols & not IP layer. Reg Rupesh -----Original Message----- From: neha dharia To: Date: Monday, March 27, 2000 11:04 PM >What's the diffrenc between AH and ESP Protocols? > >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com > From owner-ipsec@lists.tislabs.com Mon Mar 27 23:32:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA13146; Mon, 27 Mar 2000 23:32:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA26400 Tue, 28 Mar 2000 01:12:28 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Cc: Subject: RE: Heartbeats draft available Date: Tue, 28 Mar 2000 01:13:06 -0500 Message-Id: <000001bf987d$25b8df70$06dba8c0@andrewktest.timestep.com> 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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <000d01bf984c$0bac7050$881410ac@NetScreen.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Sankar, > The other redundancy concern I have is about the symmetric nature > of the described heartbeat protocol. Should two communicating parties > have to independently negotiate heartbeat protocol if they want to > ensure the other one is alive? The fact that the heartbeats are negotiated separately in each direction makes the negotiation very simple. The original design of the protocol had an "optimized" negotiation mode whereby the peers could negotiate heartbeats in both directions using a single config transaction. However, we removed this option because it added complexity to the protocol (needing to have a backoff method to resolve simultaneous initiation), but without significant benefit (no reduction in latency, slight reduction in traffic). > Also is the effect really small as you describe? > Consider a gateway hosting lots of clients. Eack IKE SA to > the client is > separate. If all clients were to send 'notify active' > periodically, would'nt > it add up to considerable overhead on the gateway to process > the keep-alive > packets, verify the hash... The scaling problem worsens if the gateway > negotiates for a smaller 'notify active' time interval. The scaling is O(n), which is as optimal as you can expect. Are you suggesting multicasting to improve scaling? (multicast and security don't go together very well) Note that this correlates with the expected CPU power required to support large numbers of SAs, which is O(n) or greater. BTW, the purpose of negotiating the heartbeat interval is to ensure that neither peer is overloaded by the extra traffic (which is unlikely, BTW -- this is discussed in the draft). > The complexity is in determining the acceptable heartbeat interval > beforehand. How can the gateway determine the suitable acceptable > interval to be negotiated? A time of 2 hours may look appropriate > in the begining (to allow the gateway to be not overly sensitive to > link, router failures..), but as the load on the system increases > it may want to clean up stale SAs at a faster rate. I wouldn't really qualify that as complexity. I suggest that you always use the same heartbeat interval (2 hours is way too long -- the draft suggests 20 seconds). BTW, the primary purpose of the protocol is not to reduce memory usage from stray state (although, that is an intended side-effect), but rather to ensure that a loss in connectivity is detected in a secure and timely manner. > Why does it require double the bandwidth? With a stateful > Request/Reply > protocol the sender of the request/reply message could send it only > when needed - that should actually save processing time and bandwidth. A stateful request/reply protocol WITH A SEQUENCE NUMBER AND HEARTBEAT INTERVAL requires double the bandwidth. Without that shared state, you are succeptable to DoS. With the state you have a fixed overhead per peer. > This fixed overhead is per remote peer. Is it scalable? It is O(n) or less. In other words, yes. > I did not get it. Why are we mixing up these pings with user traffic? > If done correctly the client would see the ping from the gateway - > reprime its inactivity timer and not a send a ping to the gateway. > > Also the inactivity timeout has no bearing on SA lifetime - right? If you send the ping on a phase 2 SA that is not clearly identified as a "management only" SA then it is easy to mix up the heartbeat with user traffic. BTW, I don't think you understand what I mean by inactivity timer. The inactivity timer is meant to delete a phase 2 SA if it has gone for a long time without receiving any NON-MANAGEMENT traffic. If you send management traffic on a user SA then you are defeating this potentially useful mechanism on the peer. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Mon Mar 27 23:34:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA13182; Mon, 27 Mar 2000 23:34:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA26351 Tue, 28 Mar 2000 00:53:36 -0500 (EST) Message-ID: <004501bf987b$b597ff60$2dcd09c0@nig95> From: "rupesh" To: "À±ÁÖ´ç.." , Subject: Re: How to call from kernel to user program Date: Tue, 28 Mar 2000 11:35:59 +0530 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_003D_01BF98A9.CC2C1800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0518.4 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_003D_01BF98A9.CC2C1800 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003E_01BF98A9.CCA19620" ------=_NextPart_001_003E_01BF98A9.CCA19620 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable RFC 2367 deals with such issues. Reg Rupesh -----Original Message----- From: =C0=B1=C1=D6=B4=E7.. To: Date: Friday, March 24, 2000 7:03 PM Subject: How to call from kernel to user program =20 =20 =20 TO IPSEC developers.. =20 I am programming ipsec on LINUX. Now I have finished modifying kernel. = But I have difficulties in attaching key management entity.. =20 In RFC 2407,=20 4.3.1 Key Management Issues =20 It is expected that many systems choosing to implement ISAKMP = will strive to provide a protected domain of execution for a = combined IKE key management daemon. On protected-mode multiuser operating systems, this key management daemon will likely exist as a = separate privileged process. =20 In such an environment, a formalized API to introduce keying = material into the TCP/IP kernel may be desirable. The IP Security architecture does not place any requirements for structure or = flow between a host TCP/IP kernel and its key management provider. =20 =20 above this, key management program should be a separate process and a = form of daemon and IPSEC program should include kernel program.=20 key management program consists of client and server. And when needed, = ipsec program must be able to call key management client in order to = negotiate key and so on. So in order that kernel program calls user program, it seems to be = needed a formalized API. but I don't know how a part of kernel can call user program and how to = design a formalized API. I need your advices about reference books and your idea.. Help me!! =20 Thank you!! =20 =20 =20 ------=_NextPart_001_003E_01BF98A9.CCA19620 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable =B4=DC=C7=B3=C0=D9
RFC 2367 deals with such issues.
Reg
Rupesh
-----Original = Message-----
From:=20 À±ÁÖ´ç.. <yulli@ece.skku.ac.kr>
T= o:=20 <ipsec@lists.tislabs.com>Date:=20 Friday, March 24, 2000 7:03 PM
Subject: How to call from = kernel=20 to user program

TO IPSEC developers..
 
I am programming ipsec on LINUX. Now I have finished = modifying=20 kernel. But I have  difficulties in attaching key management=20 entity..
 
In RFC 2407,

    4.3.1 Key Management = Issues
   =20
       It is expected that many systems = choosing=20 to implement ISAKMP will
       strive to = provide=20 a protected domain of execution for a combined = IKE
   =20    key management daemon.  On protected-mode multiuser=20 operating
       systems, this key = management=20 daemon will likely exist as a separate
    =   =20 privileged process.

       In such an=20 environment, a formalized=20 API to introduce keying = material
   =20    into the TCP/IP kernel may be desirable.  The IP=20 Security
       architecture does not = place any=20 requirements for structure or flow
       = between=20 a host TCP/IP kernel and its key management provider.

 

above this, key management program should be a separate process and = a form=20 of daemon and IPSEC program should include kernel program.

key management program consists of client and server. And when = needed,=20 ipsec program must be able to call key management client in order to = negotiate=20 key and so on.

So in order that kernel program calls user program, it seems to be = needed a=20 formalized API.

but I don't know how a part of kernel can call user program and how = to=20 design a formalized API.

I need your advices about reference books and your idea..

Help me!!

 

Thank you!!



 

------=_NextPart_001_003E_01BF98A9.CCA19620-- ------=_NextPart_000_003D_01BF98A9.CC2C1800 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <003301bf987b$b0857980$2dcd09c0@nig95> R0lGODlhWAI8ANX/AP+ZM/9mAMzMM8yZZsyZM8yZAMxmZsxmM8xmAMwzM8wzAMDAwJmZZpmZM5mZ AJlmZplmM5lmAJkzZpkzM5kzAJkAAGZmZmZmM2ZmAGYzZmYzM2YzAGYAADNmMzMzMzMzADMAMzMA AAAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAAsALAAAAABYAjwAQAb/wIVw SCwaj0hh4PFIOp/QqHRKrVqv2Kx2y+16v+CweEwum0foywVigajfl8ca/pbT7+/DW3Ph3+V2eG5q gYN0g2yGcXN4go11i42Kaol/jHSBj5qElpKQlI5rbXByk5aZoIqAj26ti6aIo5ibd6azqHCGhaGV kLakl7OQuG+TvcC2xJq/xYeyyHjKrJurnpygtZTPx6+0zZrVF2jjIw8Wn3cWTBQIEe7vFPEUEfPv CBQAEQjt7+788PLcVVDjp8+bZ3AQYrLlhg8Ec4P8nNNwTtsyQhDcVGT08BefBxAy1HkoxyHITBuv FdTkh9tBZmrU6crER6TBiARF0QIEgY+F/5VxWrWRkxKkzaBMbkLMeWHiRjbeWiqMCbMpSIJXKTKt 46cgVG/m0NGRuSfo0ZMl1yw1WFFkRTZAr+Ihm9PoSJAtHxQ82XCiTlpSbU3dRDfoR7nA1PYMJo5c uY2Z3ClwV4+eP3sFDhAgMJlfhQIQIhygHGHAAQcQEDgoEKEzhAMcPHyQTduDBtt9ftZdHHN34j6Z ThpkqjuhK4N4m/4ZJPzt1uFyVeVs8zYrZEZAMVX8KD0dJb3I4QA9lwHu2ONebxpK2dRPoOJMo5N6 OHw4fKrYwW0P+juhNveNDHVTI6U8F8d10aAnHkbYYGSOT/YVtF9SFdmhkYJl8bfGSu4xl/8hNPVF M+Ev9zVF33BHqRXJSISAZ5xjI1CS0VjK8VOAappBQAACN+pDwGjzyMPPPhEQUEADBOhjmT4QFOAA Ag2086MCDdA2Wx/ZSbighLbw0VUkBe01H04zqnEUhMD1Nx9HIDXU2yF2hBPUIKMANYlEH/knTV2I EaWWmCMZciFKX3V0UHvs8YdIm9NB5Z6LK87ZjJ104BnpOajkxRsc5ZW0XqSMUtKShoeGdc1ybJYJ IHQPTJCol2pykmhSzMXVS0etihVqnYds+aaJXCIFU3NlbQRhIDCW6ZZyBO3jgJEOVHbZBh54sMGS Qv4zWQRO3hNBBQG1piQ7EWww220f3Jb/Iazh5SRRWYGwe868+dFohwYnUlXdJBUlSlVaOBl3r3LH 9YZKvqSE6R95Mu53mCmY7hGqnrmYyOhiGnWF8Fz0OWRgWngZai+c0Sh8KMNrfKUcvh/fOrEwxYh8 FMqXZGfxgCEuwp0Gwp0aIr0Z7ZdOx4zd7LFVEEeq4h9fvtviXoloxW5GA/8l8tJwwIhcxia2YQgf tllZ22yWxUOP2RQoEBAFss02Gwjnnlvt3LLd5kFZHQ7MhFZIobS1Lk9h8ihFIZlYJicimXT4QXyv aHOpAXMVk152eZ0TfcXh+iuzoGjJUL2Q+ER54Rb6xlZHiszbuMqEgc6J6DwXbrlS7X13/2JKKVU1 yjmDpPg6sJXjlBSsJAXsVDH+TpMzRnyf5Ffvyv2E4E3Sf7N86HGM7paqKj7FRMEmzndsNkcjRqBB 45hRBAPg0iPEAxE0oP789Ndv//3456///vz37///SUAABABIwAIa8IAITKACF8hALozjPG6omvfM ZzA6EIBDlTHbt8xWHwEZDhcebNwiKBhBVASHQBiyWPIsJ8FifM87JnxhrxQDOg96DYQnQhOYfhVB VIEjhUNpC3/ugymfCI+CyjFhrBgUORtSbWgDQ5DT5mDCTaEFajXE3NB6aB8XIjFi/VFGcB7ShvTQ yYtJ89PmfMbErThxYzdji1h2yDkufv+sPh1ihNbCpJCMZLAy2+IWAiYQpMmww48EGECQ0sZIdvyR HkOiAJbYJZ4S5cQmebpA4jp4tZdEkW9f8hsp5pU67v2GkjpkUfZ8IsJDubEsmIzEURRBya0B6l/T 4ZvQ8BXFQiWnN8aCGSWHArEcImouHwpmLO0wy0oxZTyx64OH2MK3WEaOcI+YXVzw5sliFoib7VqJ NoV5R3dVg5X+CuavalKXN1WNMV9KneC+M53GkMOUvGuJGyZgowP4UzSaeUcBWHO2doRmH6n5xwEQ MBooNVQzBPjAB0BQm7pV65nDyaRBbGYrQRjxfO3Sl+26SC+OAcwvDQqm0NSExEjJSzn/ZwFngBwn w04sJJUMQoomBHS0be6skyxNhq+ip8k5SvNj30QdSF2oLE7lInm47OksHNKTnrmUpPj6is2CeDSB 4aymMMspObOTHO7sLkMkOccELEJDetIBRifMhZLo4QBujaZbTdoMAipgSEdSgDWrAU079hGks4kr AqFhB4/cpoEO3I1zH/XPwypEVOSoMa7nWQ4rF+KgioXIiJ5KzKrUEloVRS4aC1krG/GzOEiNJ3od jRykcFmfEi6oUllRRdAyGpPYGiisQVGt0lg7HBIRjSHfjMv0OHvaPLLsLii11JseJpZRnNZMJ5ot QTr2NZJdl5wgUS2hxJdEV/LmYHHS/y5ItNYKVIDxApB0wAF6IlG4VYts8shvP/hRDwy4zQMhuEA8 MJDfe0i0WtTKDThaGomUwIqyTIVKJgwlwhA2IylGxYgslJqzlk4YMYvJHVh/gynICM0uDgIZpD4s qK08UU/XmdVxOAwgyKw4FyBOZfGWWuI6eK8v6HhtcHLMCQq+d7htVAxOqEMKvUDmF8RQ43w2HJek nuSWbd0Q50gLkzIeZHR7SkTPRAie98LozGhOM5pD0I55VOAeQopHBdRM5zrb+c54zrOe98znPvv5 z4AOtKAHTehCG/rQiE60ohddvx0xoIGQjrSkJ03pSlu6gYt2zAcmkOlOe/rToA61qP9HTepSm/rU qDY0Lr4nPK4Zprx40MNW+DAPV7RiceiAyqywQeMhPm5lTC4uVjJCouGy2jfFSc6RE9S8jugmdrg+ la47sSjuXcWSwWicc4BDbDzwjLcJY5a2mQfrmRJOaBFpk1AtsutUtbp2zpznytLd7aXWIVTcgbey kXyoczeqgpjAt6/JvWwa+VvY3I72iqYtjEW5G9krkQZC0r1ex/yOdf6BgH7nilhnQoADbyBXkOC8 Nmp9Kaci1CeNGlTUjZy43vN5Z+PC0a8RztSU2FspHp9xcgUjT1UOlpFx0pmyhdyLZjrdecUUTpEJ ROTpdAQGmjoU7THvIXfaDHrRX0L/9DJV6HOKydSWJ3HSm183LS+ver4yl83e4Px3v1WvMQmCdaDf dnHB7iqNvD6SZv8yhxXRGjFRu4YITMCwS+oH2qK1UAoMwB0JJVc/xjV5J9EdfBqme8w1HyYZRtze ssrKrHlupj+0tCEis1mfUCuTOCkcJNtBabm/Ec14Xa47iemZGHPopjWRL/VLNDbSXJ8Mrcq+4A05 9pZzU7pVO+grg7fpvT/Hy9OKcfMK1lKTwT7iziHM+a3HSPFj38EOZyN7n1WHIFChNZ3ppCWIJY2S CCqtAaSmHod8fDwyM4AdXQbx+TUP/8AjXxMnCRIHXeEXTFARa4UgTcQdurA02bEN/5fTJrOTKOp3 Aa6CQvciKBEoTxnIbQjIeQeicCVWVVXRW5LCCYUyB9vECBiGcBhIFBv4CQ+4gt1wMvFyFS4iNSUo GPyWGIAHc980Ve/nVqLAd2NBg0WBDRKSRz34PLyjDUqYEN80g1shEkQYDPOygxHUc9cTKx5zNB5U Hk7VbYIHVKSBf+PCGs6iGYc3D0kSDwJUJKkhLhRAAAelAO3gT/4kABM1G20jiBdQLWJCdii4CRyW WbuxLMGRPGPWe5UCiTLydpGQfIdzQrYXCHjBYMN2dA2yb8TAHY4IDLD3XXJhhky1fNewiMYBL7ID Ko6zIp0IE7EDinNQCbfUER0SU//DEIFIZHVyRG0vc0r8UYvggFH+8h4gFTWGAWFFBi99x2DJAyvE I27xwXt9VyF7NDnPQREY0FB8+COZAT/usCMEUFhmExr6sA9JMlh5aCRNglipsSPUcl93owH62FjM Qkq+915kBnjL0V1NWDSXCBy21yCrUh4PkRc5YwFOt13+0XdapiEdMj6PUBKjwINfuH7rsmXJISfY 91x3ACgMyRv0QROn8iVF0RPqkEfQEWJBqDMb2WKuRE0YKD4Z6BWjqJFadQ0n6ZAqOYvMcUZDqYBb 0YFyYZK8eFuplBznFTByAUa48xx24I8SKYQI2XsQ0n6BU1yW4SzxyI4IIAAI8CP/bWZY26IAdcUa f8WO6sgar9EaAnSPF8VHdrQmkOIXUJiAyGEBDJgL1RZtMKmKN+OKKlVLRpeVl4A6KzVGsxhhGUlF KcgUgjIxLtGK0oQL8pRLMuY6o2I7P+kzPPghSjaZ1UN4GBaaSrZrDiF7vYOYxdJKivIcNsGDNkMf qPcyKnUJQfdsaBVhj6mXWeI4DamMb7BWkgiRUBec9vRA0QcH/sAON9IAd8gjo+EACkAA1tJm+PcP ghQB2nk2a0MZddhm/9UHHdA1xYiMGZmIy8AXzLKDu9eBj4BTrTg71LaZYXQpbsKRLHFOEplvsweL zWOK3sZy3uFz1Kafh1I4tjR7/3LCKwB6nwKaCrxyDcR0kdA4QudFKp9IgstIhVAWSszjiXSEnwfZ jCEJobI4XvnWUjmZIbpRgJmojczDjRaHZW/wJKdhD3kVARVFYAAxnYNlnvFwX9eiQe5wAPUQAoa4 jxcpoevBif94VSjZRTZIeMlHDKPJTE1JQ8+mO74HMuZBoAUnWTX5We7HHiypk1OYlOeDTf9mOw5J SwBZT6pkpsA5lTPpFBFkCmM2Ea72lNNUXO/0O7j4dH9XhNBRFkUJcJUUTp8Qfbv4S8i5p1vTp0a5 RtMFovFCdp3zQm+aLKN4k30gNm5DUbPBpEyqePTgX20zNtUCpf/FWPmIR+I3ev9pQZwep34lEoLQ dFQT+amLmX15GT5JyIqR+XPxFpO75VXuRH1A9WWm2TW4dmIg2lm1FXUyQo0J6ay3Ba0YF0KEKny0 IKw41pnEUa3CSEXE8R0txSHq93nBKJARh6/J6o0G4hJNY5yhanvv8jwbxS/M8ADtBycKRxC28QEm Ry0doAEbgDZrE4BC+gG2imD6iAG4YYhhky4fYJmWg0XkM41VcTXyqZDKQDXWV07j2iJSqTLCgQgS 81vAl2HDZStVg2Lfk1TSqKXZ010SCFwdJno5GnYcUbPLc7Or1bQBF7NP5rMYpbBWCXodNiNQIzqn t5lWZLUv2AmYcjUFaLNLCTn/ukAi9JkRGVAgLueSYQcB6UM/DBAuFKBx9PBol5a3eru3fNu3fvu3 XTC3dQu4hFu4hnu4iJu4/zMZTaC4jvu4kBu5kju5C8AAEdC4lJu5mru5nNu5SABq8ZBqoju6pFu6 pnu6qJu6qru6ePYBCcC6sBu7sju7tFu7tiu7Cjaa/VYzylp9A4IAU1sc9EqRaBezB3qtBCt6jpkh 4cqgLRoRvKNzK8O7suC7ilNULJclT5YnkcWhPvNaHlO24dYbYDhzLplOG7MSulmn1tuazGua5su9 vXu0VyVZlPkzcNRDfLSNSxm9BkKw7Eth7hsfV4cd/vuQOHM626W8Fvi+37i9/21qvB0KFOB7v4qj MqPFIc+ZBjwxMp/gW2pRRumIjfolLfPgAQ6qY93nM+wRsGWLGGYloSBmH0B1ZIlam7wkvqoUVmCl wgzGjJhlWccSprAnwzbpbfBBS9d6Fbv5wt1VxDZsPj4MZaXSHzITZBM5ZIIiETUsi1frgju2NbDo e8gEki0Dxp5HKjEcxUosYj9cxZIKsJ70E3QSQfSCLI7BDACyOBP7Ds/ERRCwATnBAWkZJBUASZC1 DJLojWD4kiA1RStsFUtcjO8bbRYmWp5EglZ4rYewyJKswa+wHtF0ftXKr2GITUMZFFhJWy8IyeDK yYL5kL1KwIdDxyNIxtnUvP+ueFul4E3l5MpdYgkQYoaWPHeXYFXtsa+S/FuxPB6zrKV7/CnQo6Ce Sggw0iF+MRTmY8KT1w/C9XF9cMiJJy2GxSMUsFJ0cZtO5iA783XWMQc5aYlmqsad7EwuohGbczDM Sq/4PM92QSep+DTujJJgJXtfu1lSd4zg4SctbJRf+SH6HM9nJ8b/PDnTvDcDnRfmA1XCIV11cZF7 M79FDFobnc+9ItHPwRxl1jes2Y9qojpzNKIxWjgAfdHrLCwaTdLyZDI7fEd8kLDruhXy9y1rWDaJ ZyQGkCSGR3mt4UiWwYcRwAGHrI+5c5q8tq28Bq4S3Fk0W2F2lyKo46V7omH/PViBM6uyY4eZWd2y 34CFSDOf68u7LIKiSrY6Y/3WMel3SYsVaX04NNtWn7cJIpQx7rzX4BbUISLW6Sq+ypYIsGCnGQZH v7K1hf3XaSJifr3Wq5jY2TR3KdKFHaE1YlccFgAk8DB5Tj1YO5IAkkEBB5AA2aIk7TAZtG0P7lB+ 85vQ5sfMSqPNj/0zJck42Ya9x5pKeeqnEza1MDTRwdtJbhq2FvHbPVe9s6h9U5ivUeRK7hXGngWG esLc4BadDX3L0vddaoLQ0XkXejqf50HJZEWj7mpM9yGMVU17vA3du71Rs/kvohzckApv35As5+M1 RT3UCKA21yJASn1IBUAB/xUwX3No1IasAGpDLguFWPfgCyp4dWdkUx1OkpRKVskKe2VNO9GVyD6I z8M2yjvRQ2PqQowwovAMCVQm47q4PKUZRrhXDFKBNwC8B0o8MCK+CC9OTx3ecJxDFH+9LAS6zDjO RdFLxSe+TtkHT0HuLspac5XKlSj+4+4CwNJ7jLVDknG9a+kVCSimfiUNCGA4PJVyzZnnHpBXD+KM Le+AJAXweKetAPPlZj/iT+lo2/xVWJ1heIeteUZrHJadhGl0U0YVTMj90HoZTK9ZJgI7kcfLrUzc 2Ysun7+GFDWqWbpCRlReEFpYgZFqKvrt2DDk6KSZXZin6Czn6ZD6PTyDov940aFosRsoJYqTzk2s LiK6Xc8rYsN27OPHSOlYk+uv7noGmUSucDFBS8r3GlTLAtQwzo6JN3nbkkgBpXh5CFAN/g4EkAA/ Qo+iUVcNkLG0oY8dkGA8jQ7tJmYcIwvbJnSSDJl07djHzRvA6kOrFa3hwEu55KkW4qAIqsBc+zhe VwpC0y9sUOItsuG7IRHEQB0drggN/xcET00GT6Lng1lvSjMCH5nZ4WxzsYn+fvGYF4GsePD8ovJY tjPVFTOUFbAF//Lw4YPOPImeRQtlgu36mVj79X8E0ABO6objIoBKElD1cJaPh/QEdZYQpQEH1rDq Yo2ZnCAPYnMwBe1Gi4H/CqIL//om142otz4sKhks0O46K8n152rPz5pkpWxd941sp2KYnYiiPCXc Yu/2zRpzcb8gz9xkwUdc5TfkHQbSfE80QgRV3EqSGrX3yJX23oD4783MPXPqklqV9wxMw1R6r+iV 4tsLGoAB/bBQmwEa8sfabnYPA8UtouGW9LAZ57gPDkUAhfhft8GPWHI5E6/wNBSoj93xI1k7O/lq AT8qkQXcmqcve3lvoAghX+GT07sNDJytWT51tfPZ8k39z1ChrMBCpkkvzQT5FqYbcUqT+Nz8AuyK WqE6DvOKZmKuchTz0wz/b38yxA0EkIvlUhwai8SLppgRFh+P5+WBNFaL/0wk0TLVJo/fLlZDZBIh ympZaB5Opdni1KidwJFpOlaehJBHAgUflPyqhJgwECIQHCIKIggaBiIYIyAgIygqIxQYHSAWIw4I KEQpDg46QxFCMTE+NDxklzqWmLSqupas4p4etL6u6obEjCD+6MCsjNDypHR5o5D4mJWY4tTqkpWX odyohZ64eakQia3Y5qx2L5DjmIWB5YwtmJ5yq6uZpe6v/eYkY3bkCrgr4uZIOWcuHpQq85j9cbeE 3EAqhRIiC0ds2jCL5rChc2evF0J38Drmo8avWjeAJzVao2YQCsJ+atIUKwnlIjExU5zBFCQIGUae RTS5GlUgFScEBAioQv+waZOlSgUceELgidFWTQVYMWpQaYOHWLyE4UJyb9k/Je3ernTXpsnauGG6 WOAjb+8Wn2ByEuwHz1u6uF+wOHloJIM1Jo1X7urS2ChDPXUwlgEDeaI0CIjXTmRLD0y7C401dKum GTMY0Kcl8uHc7HGvN7fTMfRYrnWYOaZt92kW+gzu00v2UQnd+a7mMs8tqm1GR/rL3lkOe1SsvLCG fckNZQFP0ts0YUWGBpKmS0uXSqIiOHAAtQCBRqSaUq061ZGlAqa6osoSBP7jpBINPphFrfMak0C5 83gZZyErYsJnpGQo426Ju2oSbJuBpgHvJJT+8os1fSSyTLgNcUORDJr/DiKELXkgyNDFLQgbriUp iAgRwrmy8eu7eXoMBwtfVtSsnRtZjBCkKFy6AhhtYlyIx3KuLFJKDSkUiB0uQYpHMqC49DE3hqZk J0WQqKzpSJMgRGO7Ddc0Lpn2fAsSzCiKS2+Egbgx0JIDGhHFAaYKGIACDjShwNH9CDTFAVU00WQq R98jcJSqZulAA1yC4SdK3fioDItkkqvwyoN0+0gPXfrqZ5jMWtUrosAOKSRF1pzbSQ+XbK3GiSzu XIegmJSLVaLzbC2OIi6xASqaLRDS9Vg8AjsJu23P86ULYBdrM9S3viiKp2xFyugjZdubdrqJrD3K VHGAG0JZudzQsxpd/3Ed6ZgXt+WHGLq6paPOgIazKCY/b6XzgkdMIcWBRTKxJIQPOFgEU0c1toqR /wBsVFBOIAjBrFk8uEVUEaERz6KWZ7Rolyghqu6Ixs7J5TMoP0r2YI+4gDM0ul7etZuQekYSpoFm Fq4Q1oJ+YjYqtPjDu5+pJeNLNTtLC951jW5ojZdb6rlp3nTaCcSDrhYxvCYLA3FZ0XYbLMfpvLvb bKEHJkhurb3ozO8rzniCi+qUmHoXhqmAp+ouKK74k0zM+iCERvUb2cBLOalAgao6MZCCk2OxhTfT UtJy6ZTslNU1vXaVw1bP5JLjs3VySZcLuJkd+witebGnX3+QGBa5OP/uOWTr6YDf7Q3gizOpoDaq vluzvoJP4ozUBrcm9uBT04Z4xvDhOXnByzlc790sGIPbYtCFvQ9UBzdNGHLh7z44LYzP+3Ywj1KO 4qhuXL5xUx+2Nzx/vQth5cjJj7KRLSi9xmm78lP7KKSQJXBiYgQ6VAQwcLKLmaVSGwOQxuBzCct5 wAMYoIAnOGYgFibIU7YoGN02co4JdWgc60tNy6yhN9XBJDDYKFvSiAaNNQgPiMsDIA8zYqUd8mYf FsIN/Zj2jQxqRGccMdwT2Sa49vQQaxhhmUnI0cUz8QZpR0CjBl+mJjhGqw9ZAmNNxle1tLGKjA6p 4xGpoY84ZmQ8tdv/ySGm5Trv8cRtAQxKMhj3DO6UCxIHCGGCSJegD2yghI7iSuYw5QEQJMhkmjyZ WTYwOrPQYgN1AKKznic72yVMlrCRyznUoMHeoY17fPDS2sDAs4hQBEnOcp9yfnbM7QXwPEKoYiOP gsu3MScPzkzX0phWKuWg4R+3zF4skZkcZaYNe8fY0//MgTwt7dB9lZnLJFkSpdn97hjddN44CwGR f43qIfwUFTHekiJEek9r35FZ2D7SLIF1hnFVwNlyeJEyWcyQdCz0QAkxB7pNTAWEoxSlJjFpSlOe 7AKz8EvP0McTZiHNiuaBqLGoNZrdLcNxHBmOWs5mpG82c6HUBNQU/x9Em5qgy00G4akylkgdv8Tk CyFxVu70Bg2jUqinX/wp2qCApzLojYzNgyVSneRONFhRGjs9l2okkhPOGEx/TLWp35qqIZwQgo1U DY5PmYed2Dnjh7fb3V2ggQhlKsFPghRTFj6VoIla9FNMEJknMYe5D4T0lBYtyyZXGQsWfjOIGfxn 0WDSEnfKJE1ElVIaEIPOwBrCrdQzJ0bkuc0AsiMOqGGTvYrVOMOFhDwp9a1sDRvECd3ETX795W+O A1NzZjGRMqutZ5S02vNZyF3cg61zIyNccn5mrsaFR9B0EhRhYM0hLVXtL4kLO+QRC6VC8hBW+TqM bhnruMPs69eM4LMn/e6Xv/v9AFciG+D+DpjABTbwgRGcYAUvmMENdvCDIRxhCU+YwhW28IUxnGEN b1gEsNhYRquyYRGPmMQlNvGJUZxiFa+YxS1O8AJgHGMZz5jGNbZxjCvxKAYswFEQuPGPgRxkIQ+Z yEU28pGRnGQlL5nJTXbyk6EcZSlPmcpVtvKVq0yVCsSYAlj28pfBHGYxj5nMZTbzmdGcZjUDmQGO 2vGa4RxnOc+ZznW2853xnOQgAAA7 ------=_NextPart_000_003D_01BF98A9.CC2C1800 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: <003401bf987b$b0aeac60$2dcd09c0@nig95> /9j/4AAQSkZJRgABAgEASABIAAD/7QZAUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////// //////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////////// /////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQIAAAAAAAQ AAAAAQAAAkAAAAJAAAAAADhCSU0ECQAAAAAEzwAAAAEAAACAAAAAgAAAAYAAAMAAAAAEswAYAAH/ 2P/gABBKRklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0 LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwM DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAgACAAwEiAAIRAQMR Af/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSl tcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOE w9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A 6/v5hJJLhPYlA/glwklMpKVolP3pp7p++iSldvNKR3+SRS8klK+SU+CRSSUrv5JSOEo7pT2SUpKN EpMeJSJSUr4pJdkvjykp/9Dr+QkJIShKQT8E9iUEvJJLVJStfmkPw8UvglOsH70lK+PCUd0hwl8U lK8kvhwEvNL4JKUSkEtOEklKjxS0S58vNIpKUlB+SUa6duUoSU//0evTd0/YjhL569k9iUUkktJ8 0lKSBKR5S5SUrRLVIeSY68d0lL9vimGif+KXkkpWiXhHzS4S1RUoifIJaBKdPJL4oKV5/elOmiXw SnXQpKf/0uv14SOqQ8PuSPMp7EpLulKRn5JKUkPvT88pu89+ySlJQAl/rCRjg/JJS3h+Cf8AIkkf E/gkpXKQ8kvuSmPJJStO6RSS/KkpXhPdJKfH5JJKf//T69LjQpf6yl+RPYlf6hLzSB/3JdklK8+3 glz/ABKSUapKVPilx/sSB8PklISUqNP70vxCRSSUrRJKI80vNJSu6RS5S0+SSlJcaH70pCUJKf/U 6/4JDwS+CXKexK+KRMJaz8Eo7JKV3SidTwkkQkpRPyS7pSEklK5SS8+6SSla8pJtDpx5J0lLaJz/ ALwl240SJhJSo1+HZL8qXmlqR8UlP//V67wP4JylH3pTrHfunsSkuPNL8vZLySUrlJNyU6SlJdpS Snx7d0lK158UvMfclyNO6XCSlHRIJfxSSUpIpJQkpQ1SS1kSkkp//9br5180pHZKUpjT8U9iVyUu 2iXxCWqSldvBJLTsUuP4pKV2SA/2Jo08E6SlTokEuNEklKmEkw5TwOUlK8kkvwKRSUqfx4TpkuNB 80lP/9kAOEJJTQQGAAAAAAAHAAMBAQABAQD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rv c2hvcKggNC4wAP/uACFBZG9iZQBkAAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAKBwcHCAcK CAgKDwoICg8SDQoKDRIUEBASEBAUEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM AQsMDBUTFSIYGCIUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAz/wgARCADIAMgDAREAAhEBAxEB/8QAfgABAQEBAAAAAAAAAAAAAAAAAAECBgEBAQEB AAAAAAAAAAAAAAAAAAECAxABAAICAwEBAQEAAAAAAAAAAQARECEgMDFBAkASEQACAgIDAAIDAQEB AQAAAAAAAREhMUEQUWFxgZGxwaEi0RISAQAAAAAAAAAAAAAAAAAAAJD/2gAMAwEBAhEDEQAAAO04 bikKQpAUCpAUgWyKigVIpAAi0iUJGqghQCpLRI1QkQpagiLUAtiWKZtsgBSAFJZcVpBbZIW1JAUk tsgKkUAVYlIKsRakBSLUliWkFtSSFKQUJFpKQQ1bItkgFlzVkWhDSySLQEUi2ySLbKQQKublLaRC iipAoJF0kUJGiAhVtSQi6QsQAFBEtsgUAlVGbLAaJUjVFkSyyLpIWWWRagWoIUiGrZIFIUEBSAAR aiFWWI1UgAW2SAsssKCUiipFJLbIWxLELbBJaKEhSQqxm2pVkNEEFIAqrIWJRKsikQ1UEC1JZZVi USrEKLEFhSBDVSBFWWFJZZYhS1IAW1IqRSQoEC1FJVJFJF0kqrJCwokCgKspIAWpIW1M22KkUhVS KlIIVFokW2CFiKKQFCS2xAAUgWpBVgKRFqRCikFIpEKC2wjNVEXVkEQq2ySLUW2SBRUS5soAgqgE isrtIW2QCLRcpYhVWSKCFAsSrZJSFBC0gpFIUEAWsy1FUzFAtSC25LCkiggi2S1FpIWFUhJdWQKC BAAUiKssKCWWJbYktslIUyUssspKQhq2TNagsSyxJpYWpKsSLUC25Z1LAUlJZZYUgssslosgKCFI hRZVkBf/2gAIAQIAAQUAIvB43Di8bhF6Hh84srh86Xh5wOZzewxVdD7wOm4YXsOIcXoHrM1Lx87L xeXFR5XHF4OFc71weB0OQzXI5PXUeV9dS49PvTeXIcnocXzqV03lOlw4Hk4vFYeF4ZXK++8Vyeyp XOudwjn501m8HH5kIPO8ByZXA4E+4cJ1+SuusXPnJ43yvJkzUqXfCs3moPVUeF8w7L4BisOK4h0P vQuXoWf/2gAIAQMAAQUAcMviS4RzeLyS4Rw8jqrorBmuFdd5DjWLw5cV1L0vReDvDFQxXKsuPMOa zfA51ip8hK76wOb43KzX8Liug51/EuayS+Rwrg9FcTsZceN8CXyqpfZXC+dxxfA7jFx7GEcGXB11 hyub4Xi+VcbxfKo8CVj5wDhWaycSLLwcXJkOgl8F5s8x8vi9t32LiulwcmGHi5vNcL5EOLxOFcDs qViv4nj/AP/aAAgBAQABBQB3KK1LQ9B1W2jF78XcQDTN17Bmr1CXvxdyitRN6nsps3EIaLl2hWKh GiVPJ+Xe0BlQExUPFZbELusUEFly9u4bKUZQMbpqqi1EE8w2zcQvSm4XGbt8giaxe/SmXEubC9XB uaJW2VcJ5DcLpLmiBu5VzUqEWNk1B2T6tRKgBNRqW3aSyNSyVPJphG5uqAra/wCf02Mrfsqi5Uqb H47hRPv6LN1shufKI3Wp4nhYlMZutT/NR8FuJA/UEZaT8q4tEblg6nylZRYjKouVLhcQs9+1Ladw dBSEux/WtRu0YVaNghY4ojsBuUXGfm5VwoKx7C4XL3Re58LiDA2rC6Ze/taKZQpo3PES/Z5HT+bp LGA0JPI7gVKqPjU3ZcQumWkvcqo6Ft+lrPmrqXoVjTEQuwhWKLUw3C61EH9O0d/arHsChuWQlaib u3CWWEYfkjUslVDzYlM+toanksSkbYT8iS9sWJZYRnsq5e/Y7n0bmgu1CCTxFtI7l7Z8hVexLnsq 5e7lkPPJWnR/ot3ELqaIm/I+/l3tAZThtKlXCowGts3gES7hNxahbAoqoeLqF2gwsX38ui2IkVq9 CsdzcJuVtdiP5GimDSgu7fal4qoeem4Lfj+q/RWoCYqXr40wuos/IxALt9gVKJtjcLpJRAl1Ny7H FXNxN6on27xtiteT6lyowtbh5RZdK4TdF1YXTU1VDNBdqEu4x9+XumJZu1pKW9Rj6TyAMaIaKKik fH8wd0T7dTUoi6LIeOzyXEZe7qaI1NRowWxodMNKtg0yy/Volq1csIOkYk8jcKnr+jXw1jTGKyiN 1qbsGUW0z75FpG0uErZH9UEaZdN3PIlxRh+ZqbcUWI4fV15LbTXgu9M3QrA38XXy0al0E+t2DVRQ dMfC1QzbZuOwNkbq2eRDNt//2gAIAQICBj8AHH//2gAIAQMCBj8AHH//2gAIAQEBBj8AgghaIm++ MV2SSTJ50KLfRBHRR72RtEQekkpnnQot9EEELQoO+M0j4zx5xmHonJ6Si8mInohueHV9jimS/sp/ BesnpKLIIxw+uJmOz9Mt4EnXF0U4fEiapHpD3xPHpZWeJIWuLJRk/hGOLvo9McTMwJf5x2UuJyie f0KL7P4XkvJ6hLb1x+idk9FZ0Xksqy983ronTJR/rI0ecOiiyrP0OWT+CGRvQuxlCT3sUX2eFuij 9HyOcOyPwVh5Ksh48P8A562y6XZCr1CTyubK5yfI4wfBR+xfoon/AAUWtkf6LtFYGlbREcJ9Hmyh w76KI2LTRP5Jgg+eK+yiUeo7PCinHFqCe+HBOiNEaPT50Mtyxfvj0rJKqMk6I+zwrGx9PBDJeRQf sgvHHR/Bel/klOUyfwf+jjOkTt6474slYZ6RsSX2JHheDw8If0Q8n9Ieez4ou+jMHnRCZ7zWGTsZ Z1xTzwl3sjmBp/SJxx0YJVsT70WRw5Vd8x3hkTZOyetmbRZGivxxiCMoTj5LVlkdEJiivSHxars9 I2eMnZ4uPMnjHcJHq4umXZSlH8JQp/wgcX4yH+Sl9kHpGzx8TscqCSVokh0fOSiUUdvUmBa4hokp Vxk9RD+nxOxyoFURxD/PMvAl2Qvsnok+T4IL2Or7HFMl/YiCETvjqD+kPPZaI09lE95RZGirIJeh PRZKeSxVMiQiMEZIMQxMzkuuOjJEkcQj1Ek5Jynoql4Rh8fI4/HGBw+LP6eHfhDtekdEJl6yekov JOxdmMcUy/s7POz9Dl4JOhrehVfRkjOy8E7RKsspfZZTh9nRK4/0fR1HDKV9FcRkrAv2OVSwyZ4n D4rPXGaIzGxXZDyhTkr74+clEorifwK/khZEiE4YkQSvtMkU/nifwLfZ/CcPZWNkTPpZGxLbIE5t E/k84Z/zsmP+iXo7TPT0iD+FOCBn/JLJMcOU0xtk/jh96PdlEL8EYKox9n7Q+lokrBB8kkZIwQqY qvZiyehzoS6O+ysc5Op4XWyNEFmIjfMqhmJ8I+hdbLxw7nwV42UZyekY7PETB8E6JWDw/pEEctYj RVwTEEjg8I/0hI92T3ji8HjIbvs9QlviFkTxGUdrYqzgsnKeD0vJi9lYITtlo8Z2tirOCycp4P/Z ------=_NextPart_000_003D_01BF98A9.CC2C1800-- From owner-ipsec@lists.tislabs.com Mon Mar 27 23:51:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA13435; Mon, 27 Mar 2000 23:51:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA26452 Tue, 28 Mar 2000 01:29:15 -0500 (EST) Message-ID: <005801bf987f$cd316c20$7701a8c0@root94.oullim.co.kr> From: "Root Shin" To: "rupesh" Cc: Subject: Re: Date: Tue, 28 Mar 2000 15:35:25 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id BAA26449 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear. Rupesh >2) ESP is Encapsulation Security Payload : It provides optional >Authentication as well as optional Encryption. One of the service MUST be >selected. It provides these services Upper layer protocols & not IP layer. --------------------------------------------------------- Could you explain detail? "It provides these services Upper layer protocols & not IP layer." >-----Original Message----- >From: neha dharia >To: >Date: Monday, March 27, 2000 11:04 PM > > >>What's the diffrenc between AH and ESP Protocols? >> >>______________________________________________________ >>Get Your Private, Free Email at http://www.hotmail.com >> > > > From owner-ipsec@lists.tislabs.com Tue Mar 28 00:56:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA16150; Tue, 28 Mar 2000 00:56:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA26695 Tue, 28 Mar 2000 02:27:25 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A082@baltimore.com> From: Chris Trobridge To: "CHINNA N.R. PELLACURU" , ipsec mailling list Subject: RE: Heartbeats draft (fwd) Date: Tue, 28 Mar 2000 08:33:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > Sent: 27 March 2000 22:51 > To: ipsec mailling list > Subject: RE: Heartbeats draft (fwd) > > > some thoughts on Heartbeats: > > SPI lists: I feel that this approach to maintain > synchonization between > the SADs of two peers is not going to scale well. It's going > to be very > expensive to send the SPI list, and also check the SAD against the SPI > list, as the number of SAs increase. I feel that implementing > acknowledged This is only the list of SPIs from on peer to the other - I don't see any great need for this to grow dramatically. Even if it is large, the protocol allows for a portion of the list to be transmitted each time. In this way the processing effort can be maintained at a constant level at the expense of a longer verification period. The point about the heartbeat protocol is that it is relatively resistent to DOS attacks. This is particularly true if the heartbeat traffic is indistinguishable from regular traffic. In this case it can't be selectively deleted and limits the possibility of holding back traffic. In any case if an attacker can delete and insert datagrams at will then there are plenty of attacks he can make. Where the heartbeat protocol is stronger is that it can't be provoked into generating traffic or renegotiating SAs by spoofed traffic. If one peer has gone down then the 'cheap' basis for authentication has gone. This means that spoofed traffic can force either one end to generate an expensive signature or the other end to renegotiate SAs, depending on whether authentication is used or not. Chris From owner-ipsec@lists.tislabs.com Tue Mar 28 01:06:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA17286; Tue, 28 Mar 2000 01:06:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA26831 Tue, 28 Mar 2000 02:50:25 -0500 (EST) From: sami.vaarala@netseal.com Message-ID: <38E08DEB.64EA75FD@netseal.com> Date: Tue, 28 Mar 2000 13:48:11 +0300 Organization: NetSeal Technologies X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-64 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: ISAKMP commit bit and connected notifications Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry for bringing this up yet again, Can anyone give a solid reasoning as to WHY we need commit bit or connected notifications at all? As far as I can tell, a connected notification does not guarantee a consistent outcome of an exchange any more than an exchange without a connected notification. The "three army" problem seems to apply: - if the last message IS critical to the consistent completion, it must not be dropped or otherwise the exchange fails to complete consistently [if not, this message is not critical after all, right?] - on the other hand, if the message is not critical, we can remove the message from the exchange. - continuing this way, we end up in a situation where the last message is critical [for IKE, connected notifications are non-critical]. Yet, we cannot guarantee its delivery (by the very nature of IP). As far as I can see, the best (only?) solution is to keep connection state for a while after sending the last message. If a duplicate of a previous message arrives, resend the last message. Keep doing this for some sane timeout value (e.g. 3*round-trip), perhaps applying a sanity rate limiter to avoid flood attacks. This guarantees consistent completion to a certain probability (not 100%), which you can tune by choosing an appropriate timeout value. (The same reasoning applies to e.g. TCP connection teardown; there is no 100% guaranteed way of tearing down a TCP connection and TCP uses a similar timeout strategy.) Do others agree with this reasoning? If so, I suggest the following: - deprecate the commit bit from ISAKMP (or the IKE exchanges) - add wordage about proper behavior wrt last exchange message (encourage a behavior that works robustly) to either ISAKMP or IKE spec - acknowledged notifications should mandate this last message behavior (otherwise they aren't any more guaranteed than normal notifications) - normal notifications cannot benefit from the last message strategy because there is only one message to send; wordage about this should be added to clarify the difference between acknowledged notifications This is a "phase out" strategy; older implementations may continue to support commit bit but newer ones should not mandate commit bit processing. -- Sami Vaarala (sami.vaarala@netseal.com) NetSeal Technologies http://www.netseal.com/ From owner-ipsec@lists.tislabs.com Tue Mar 28 01:09:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA17619; Tue, 28 Mar 2000 01:09:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA26668 Tue, 28 Mar 2000 02:23:12 -0500 (EST) Message-ID: <38E05EB4.71ABC59F@cisco.com> Date: Mon, 27 Mar 2000 23:26:44 -0800 From: chinna pellacuru Reply-To: @cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: akrywani@newbridge.com CC: "'ipsec mailling list'" Subject: Re: Heartbeats draft (fwd) References: <001401bf9860$4469a5c0$08dba8c0@andrewktest.timestep.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If we have acknowledged notifies (all types of notifies, particularly delete notifies, as proposed in the new IKE revision), then I don't see why the SADs are going to get out of sync, except in just one case where one of the peer goes down. When one of the peer goes down, and comes back up, as I said before, the peer that went down can ("intellegently") initiate fresh SAs with the Initial Contact, and both the peers are going to sync their SADs again. So, I feel that to solve the problems that this draft is trying to solve, we do not need Heartbeats at all. We have implemented "keepalives" in our implementation, and our experience is that "keepalives" can be very expensive. -chinna Andrew Krywaniuk wrote: > Hi Chinna, > > > SPI lists: I feel that this approach to maintain > > synchonization between > > the SADs of two peers is not going to scale well. It's going > > to be very > > expensive to send the SPI list, and also check the SAD against the SPI > > list, as the number of SAs increase. I feel that implementing > > acknowledged > > Notifys is a much more simple and clean solution to the SA > > synchronization > > problem. > > I assume that you are advocating sending an acknowledged notify every time > you receive an invalid SPI message? The problem with this is that it is too > promiscuous in allowing an attacker to elicit a response from a spoofed > message. > > Let me suggest that you instead keep track of the invalid SPIs you receive > during a heartbeat interval then send SPI lists for each one in the your > next heartbeat message. (But up to a certain maximum, since you don't want > to allow the attacker to suck up all your memory.) > > > Problem being solved: The major problem that is being solved here is > > knowing exactly when the peer went down. If we don't have > > heartbeats, when > > a peer goes down, we will continue to send encrypted traffic > > to the peer, > > and even if the peer comes back up, it is silently going to > > drop all the > > encrypted traffic (no SA). > > But that's what the basic heartbeat protocol is for. The SPI list is an > optional payload that performs an additional function (SAD synchronization). > If you just want to know when the peer as a whole is dead, then don't > request to receive the SPI list. > > > Regarding the below discussion: One justification for not using a time > > stamp with the SPI list given is that the time may not be synchronized > > between the different peers. I feel that expecting IPSec > > peers to be able > > to maintain accurate time is a basic requirement for validating > > Certificates, and using PKI. > > Yes. This is one of the issues I was planning to bring up at the meeting. > The difference between validating heartbeats and validating certificates is > that for heartbeats, the time has to be synchronized within a few seconds > (whereas the requirements for validating certificates are not necessarily so > rigid). > > Also, certificates are administered by an SA, so it is clear that the time > on the certificate is based on the CA's time. Heartbeats do not require > PKIs, and they are not bound to a particular CA time; therefore, there is > room for confusion. > > One thing I considered is that the receiver could ask the sender to send him > the current time (encoded as a second count... presumably in the C standard > library format). Then the sender would store the offset between the two > times. > > Comments, anyone? Would this be better than using sequence numbers? > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of CHINNA > > N.R. PELLACURU > > Sent: Monday, March 27, 2000 4:51 PM > > To: ipsec mailling list > > Subject: RE: Heartbeats draft (fwd) > > > > > > some thoughts on Heartbeats: > > > > SPI lists: I feel that this approach to maintain > > synchonization between > > the SADs of two peers is not going to scale well. It's going > > to be very > > expensive to send the SPI list, and also check the SAD against the SPI > > list, as the number of SAs increase. I feel that implementing > > acknowledged > > Notifys is a much more simple and clean solution to the SA > > synchronization > > problem. > > > > Problem being solved: The major problem that is being solved here is > > knowing exactly when the peer went down. If we don't have > > heartbeats, when > > a peer goes down, we will continue to send encrypted traffic > > to the peer, > > and even if the peer comes back up, it is silently going to > > drop all the > > encrypted traffic (no SA). First of all, what is the > > probability that this > > situation happens? Can we say reasonably corner case. Second > > of all even > > when this happens we can change the peers behaviour to 'intellegently' > > start negotiating the SA with us, with the Initial Contact. I say > > 'intellegently' in the sense to avoid DOS attacks (but, I > > guess this is > > not a major DOS attack risk). > > > > IMHO, heartbeats would be more useful if we had a list of > > multiple peers > > which support the same trafic flow (redundancy/failover), but > > I guess this > > is getting into too much of implementation detail. It can be > > left to the > > implementations to provide this kind of redundancy. I guess > > there is no > > real customer requirement that IPSec implementations of > > different vendors > > should provide redundancy/failover across vendor implementations. > > > > Regarding the below discussion: One justification for not using a time > > stamp with the SPI list given is that the time may not be synchronized > > between the different peers. I feel that expecting IPSec > > peers to be able > > to maintain accurate time is a basic requirement for validating > > Certificates, and using PKI. > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > ---------- Forwarded message ---------- > > Date: Sun, 26 Mar 2000 03:25:11 -0500 > > From: Andrew Krywaniuk > > To: 'CHINNA N.R. PELLACURU' > > Cc: 'Tero Kivinen' > > Subject: RE: Heartbeats draft > > > > Good point. When comparing the SPI list with the SAD, an > > implementation > > should ignore SAs that were negotiated "recently" and SA > > negotiations that > > are still in progress. > > > > The delay attack by an intermediate router is less important > > because we do > > not claim to be able to prevent delay attacks. However, I > > guess that using > > TO_I for the above definition of "recently" would be a good practice > > nonetheless. > > > > Andrew > > -------------------------------------- > > Beauty with out truth is insubstantial. > > Truth without beauty is unbearable. > > > > > > > -----Original Message----- > > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > > Sent: Saturday, March 25, 2000 4:01 PM > > > To: akrywani@newbridge.com > > > Cc: 'Tero Kivinen' > > > Subject: Heartbeats draft > > > > > > > > > I feel that the SPI list specification and processing has > > > some problems. > > > > > > For example: > > > > > > Peer1 Peer2 > > > HeartBeat Sender (QM Responder) HeartBeat Receiver (QM Initiator) > > > Hearbeat with SPI list-----> <----- Final QM message > > > > > > Suppose Peer1 and Peer2 are negotiating a QM and Peer2 is > > > sending Peer1 > > > the fianl QM message, and Peer1 is the HeartBeat Sender. > > > Peer1 will not > > > have SPIs corresponding the QM that is being negotiated in > > > his SAD yet, > > > and so these SPIs won't be in the SPI list. But Peer2 may have just > > > finished processing the 2nd QM message, sends out the final > > > QM message, > > > and then installs the SAs in to it's SAD. Now when the > > > HeartBeat reaches > > > the Peer2, it won't have the SPIs for the QM that was just > > > negotiated, and > > > these SHOULD be deleted. > > > > > > I guess it is important to also communicate some sense of at > > > what time the > > > snapshot of the SAD is being sent. Or the receiver of the SA > > > list must be > > > more intelligent about deleting QM SAs that were setup just > > > recently (he > > > can probably have some upper bound on the SAs age that he > > > will delete in > > > this situation. This is useful against other kinds of simple > > > attacks like > > > someone just holding onto a legitimate HeartBeat for some time and > > > replaying it. The recommended timeout is 65 seconds, and if > > > the attacker > > > holds on to the packet for 60 seconds and replays it, then > > all the QMs > > > that were negotiated during that time SHOULD be deleted. > > The Heartbeat > > > packet may also arrive out of order(rarely), and may cause similar > > > problems with QM Sas that are being negotiated. > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > > > > > > > > > > > > > > > > > From owner-ipsec@lists.tislabs.com Tue Mar 28 01:40:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA19332; Tue, 28 Mar 2000 01:40:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA27052 Tue, 28 Mar 2000 03:28:29 -0500 (EST) Message-ID: <003501bf9891$589fa2c0$2dcd09c0@nig95> From: "rupesh" To: "Root Shin" Cc: Subject: Re: Date: Tue, 28 Mar 2000 14:10:57 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0518.4 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>2) ESP is Encapsulation Security Payload : It provides optional >>Authentication as well as optional Encryption. One of the service MUST be >>selected. It provides these services Upper layer protocols & not IP layer. > --------------------------------------------------------- > >Could you explain detail? >"It provides these services Upper layer protocols & not IP layer." ---------------------------------------------------------------------------- -------------------- It means Encryption is applied to TCP/UDP or may be other Upper layer protocols & there headers and data are in encrypted form.But , IP header & it's data is still in cleartext form.So, anyone can view IP header & it's data. Same , Authentication mechanism is applied to TCP/UDP or other Upper layer protocols & not to IP header.So, someone can change IP header & data. Reg Rupesh > > > >>-----Original Message----- >>From: neha dharia >>To: >>Date: Monday, March 27, 2000 11:04 PM >> >> >>>What's the diffrenc between AH and ESP Protocols? >>> >>>______________________________________________________ >>>Get Your Private, Free Email at http://www.hotmail.com >>> >> >> >> From owner-ipsec@lists.tislabs.com Tue Mar 28 03:18:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA26688; Tue, 28 Mar 2000 03:18:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA27259 Tue, 28 Mar 2000 04:35:36 -0500 (EST) Message-ID: <38E07DBC.A3C9F3D6@cisco.com> Date: Tue, 28 Mar 2000 01:39:08 -0800 From: chinna pellacuru Reply-To: @cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Trobridge CC: ipsec mailling list Subject: Re: Heartbeats draft (fwd) References: <1FD60AE4DB6CD2118C420008C74C27B854A082@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chris Trobridge wrote: > > -----Original Message----- > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > Sent: 27 March 2000 22:51 > > To: ipsec mailling list > > Subject: RE: Heartbeats draft (fwd) > > > > > > some thoughts on Heartbeats: > > > > SPI lists: I feel that this approach to maintain > > synchonization between > > the SADs of two peers is not going to scale well. It's going > > to be very > > expensive to send the SPI list, and also check the SAD against the SPI > > list, as the number of SAs increase. I feel that implementing > > acknowledged > > This is only the list of SPIs from on peer to the other - I don't see any > great need for this to grow dramatically. Even if it is large, the protocol > allows for a portion of the list to be transmitted each time. In this way > the processing effort can be maintained at a constant level at the expense > of a longer verification period. The number of quick mode SAs between two site to site security gateways can grow dramatically, and because the SPIs are completely randomly allocated, we have to essentially walk through all SPIs that we have with a particular peer, and then send the SPIs that are in a particular range. I don't see any real saving in processing here, although there is saving on the receiving side. And I don't see how we can cleanly comeup with ranges of SPIs that will actually divide the SPIs that we have with a peer as we intend to (or atleast reasonably equally), because SPIs are supposed to be completely random. If we use acknowledged delete notifications, the we pretty much don't have to worry about any SAD sync issues, for most of the time. The only place we need to deal with them would be when a peer goes down. > The point about the heartbeat protocol is that it is relatively resistent to > DOS attacks. This is particularly true if the heartbeat traffic is > indistinguishable from regular traffic. In this case it can't be > selectively deleted and limits the possibility of holding back traffic. In > any case if an attacker can delete and insert datagrams at will then there > are plenty of attacks he can make. > > Where the heartbeat protocol is stronger is that it can't be provoked into > generating traffic or renegotiating SAs by spoofed traffic. If one peer has > gone down then the 'cheap' basis for authentication has gone. This means > that spoofed traffic can force either one end to generate an expensive > signature or the other end to renegotiate SAs, depending on whether > authentication is used or not. > Firstly heartbeats are not going to be 'cheap', atleast from our experience they are not cheap even without the equivalent of SPI lists. If you had a lot of peers, and if you use the recommended heartbeat interval of 20 seconds, then the box is sending/processing a considerable amount of heartbeat traffic. Coming to DOS vulnerability, I am not advocating that we should try and negotiate SAs for invalid SPI errors all the time. We can "intellegently" initiate SAs only when we detect that we recently restarted, and limit the number of times we initiate to a particular peer. I don't think that this is a major DOS risk, and can be easily bounded, if we are smart about it. We can use techniques used similar to what we use to prevent against DOS attacks, when we are responding. Somehow, the argument that we will send out a heartbeat to every peer, once every 20 seconds (a lot of processing and traffic), to save ourselves against DOS attacks, is not very logical to me. -chinna > > Chris From owner-ipsec@lists.tislabs.com Tue Mar 28 07:05:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03447; Tue, 28 Mar 2000 07:05:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28266 Tue, 28 Mar 2000 08:15:33 -0500 (EST) Message-Id: <200003281322.IAA13351@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats draft available In-Reply-To: Your message of "Mon, 27 Mar 2000 21:25:53 EST." <001301bf985c$f2f21db0$08dba8c0@andrewktest.timestep.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 28 Mar 2000 08:22:02 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: Andrew> I agree. *IF* the WG is willing to designate certain SAs as Andrew> "management only" SAs and they can be clearly identified as such, Andrew> so that an implementation can apply one set of traffic-processing This is the most logical implementation in my opinion. >> Intermittent services like ISDN present special problems. The last >> thing a user will want is for the heartbeat protocol to keep the ISDN >> link up perpetually! I don't know whether people will want to address >> these issues. My thoughts are that the protocol should be capable of >> being able to be suspended or 'slept' to suspend or back off the >> keep-alives during periods when the line would be otherwise idle. Andrew> Yes, this is true. In fact, we purposely left hooks in the draft Andrew> (see future considerations 1 & 2) for this scenario. The reason I Andrew> did not include a proposal on how to solve this case is that I am Andrew> not yet sure what the best solution is. I have heard a few On possibility is, as a user configuration option, the heartbeat packets could be DS-marked with a code point which didn't bring up the link. How a failure here is distinguished from a failure in another part of the network (you can't use ICMP here, they can be forged) raises a simple question: - what's the use of heartbeats on a link that you don't want to keep alive If the line is not "otherwise idle", then there is traffic on the line, and so the SAs will be maintained. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Tue Mar 28 07:10:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03518; Tue, 28 Mar 2000 07:10:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28488 Tue, 28 Mar 2000 08:44:31 -0500 (EST) Message-Id: <3.0.5.32.20000327153809.008b5660@email.nist.gov> X-Sender: foti@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 27 Mar 2000 15:38:09 -0500 To: ipsec@lists.tislabs.com From: Jim Foti Subject: IPSec and the AES Cc: jfoti@nist.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi- I would like to remind the IPSec community of the upcoming end to the Advanced Encryption Standard Round 2 comment period. Public comments are due by May 15, 2000, and NIST would certainly be very interested in your community's opinions regarding the five AES finalists, MARS, RC6, Rijndael, Serpent, and Twofish. After May 15, NIST will be reviewing all of the comments and analysis received to-date on the finalists, and then we will make our selection for the draft AES standard. So, the end is quickly approaching, and this is the last opportunity that people will have to help us determine what the AES will be. Official public comments should be sent to . Any comments that you might care to provide will be appreciated. Here are some helpful links: Some suggested topics for public comments are listed in our call for Round 2 comments (Sept. 1999): Papers submitted to the Third AES Candidate Conference (April 13-14, 2000): Round 2 public comments received to-date: The Candidate AES Cipher Algorithms and Their Use with IPSec: AES Home Page: Thanks for your time & consideration. Gratefully, Jim NIST AES team ******************************************************************* Jim Foti National Institute of Standards and Technology (NIST) 100 Bureau Drive, Mail Stop 8930 Gaithersburg, MD 20899-8930 USA TEL: (301) 975-5237 FAX: (301) 948-1233 jfoti@nist.gov ******************************************************************* From owner-ipsec@lists.tislabs.com Tue Mar 28 08:06:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04462; Tue, 28 Mar 2000 08:06:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28661 Tue, 28 Mar 2000 09:30:24 -0500 (EST) Date: Tue, 28 Mar 2000 09:36:14 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Heartbeats draft (fwd) In-Reply-To: <38E05EB4.71ABC59F@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 27 Mar 2000, chinna pellacuru wrote: > When one of the peer goes down, and comes back up, as I said before, the peer > that went down can ("intellegently") initiate fresh SAs with the Initial > Contact... This assumes that the peer which went down is aware, when it comes back up, that it *should* initiate fresh SAs. That is not necessarily true. If it were, life would indeed be much simpler. In a world of fixed, static, pre-arranged VPN connections, each end can be told to re-initiate when it comes back up. Unfortunately, many people wish to use IPSec in much more dynamic situations, where only one end may be aware of the immediate desire to send packets. How does a rebooted server determine which of its potential clients it should re-initiate with? It may not even know their IP addresses! Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Mar 28 08:16:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04627; Tue, 28 Mar 2000 08:16:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28740 Tue, 28 Mar 2000 09:57:07 -0500 (EST) Message-ID: From: David Arrants To: ipsec@lists.tislabs.com Subject: getting off of this list Date: Tue, 28 Mar 2000 06:57:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How can I get removed from this list ? -----Original Message----- From: pau@watson.ibm.com [mailto:pau@watson.ibm.com] Sent: Monday, March 20, 2000 8:25 AM To: ipsec@lists.tislabs.com; jtiller@lucent.com Subject: Re: IKE Public Key Encryption > > > Hello All, > > I know this has been discussed, and I attempted to find the previous > discussion in the list archives - needless to say, I was unsuccessful. > --------------------------Question--------------------- > In the third message of MM with Public key authentication > (non-revised shown - but same issue for both): > > Initiator Responder > ----------- ----------- > HDR, SA --> > <-- HDR, SA > HDR, KE, [ HASH(1), ] > PubKey_r, > PubKey_r --> > HDR, KE, PubKey_i, > <-- PubKey_i > HDR*, HASH_I --> > <-- HDR*, HASH_R > > My question is about the use of HASH(1): > > "Where HASH(1) is the optional hash of the certificate which > contained Pubkey_r." > > Shouldn't the [ HASH(1), ] be required? I would agree. At least our own experience showed that this makes it much less ambiguous. Pau-Chen > > .......... > > Best regards, > Jim > > > > > From owner-ipsec@lists.tislabs.com Tue Mar 28 08:45:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA05080; Tue, 28 Mar 2000 08:45:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28836 Tue, 28 Mar 2000 10:17:10 -0500 (EST) Message-ID: <38E0B89B.D4203EA1@zopps.fi> Date: Tue, 28 Mar 2000 16:50:19 +0300 From: Jari Arkko Reply-To: jarkko@zopps.fi Organization: None X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IPsec and bandwidth sensitive applications Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi I'm looking for some guidance regarding the use of IPsec on applications that may be sensitive to packet size overhead, such as that caused by adding IPsec ESP header, trailer, authenticator, and possibly an outer IP header. Two applications are my primary concern: * Wireless, where bandwidth as such as limited and adding e.g. 32 bytes to each packet would be considered expensive. * VoIP, where size of packets is so small that even small size overhead amounts cause a large bandwidth requirement increase percentage-wise. Even if perhaps irrelevant for end-user systems, centrally located gateways and servers handling concentrated traffic may find such overhead significant. Also, I'd be interested in seeing pointers to existing documents or discussions regarding * Relationship of IPsec mechanisms to the simple RTP/RTCP encryption mechanisms as defined by RFC 1889. Are those mechanisms still recommended or replaced by the use of IPsec? * Are there any possibilities for header compression of IPsec? Such as negotiating away SPI values (something similar as in the L2TP header compression) and possibly sequence numbers, or perhaps even IVs (as is done for RTP which apparently can do without IVs as the data contents already have a random component)? * Suitability of particular algorithms and cryptographic modes to these situations? For instance, integrity checking appears to have a fairly large constant overhead (CPU+bytes) which is bad for small packets. Are there better mechanisms? What about CBC vs. OFB etc? Block versus stream ciphers? * Comparisons of security mechanisms such as IPsec, RTP-encryption, SSL, application-specific, and others in these contexts? Thanks, Jari Arkko Ericsson From owner-ipsec@lists.tislabs.com Tue Mar 28 09:21:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA05768; Tue, 28 Mar 2000 09:21:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28974 Tue, 28 Mar 2000 10:48:57 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B789008@md-exchange1.nai.com> From: "Mason, David" To: "'rupesh'" , Root Shin Cc: ipsec@lists.tislabs.com Subject: RE: Date: Tue, 28 Mar 2000 07:37:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ks_c_5601-1987" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All of the IP header is protected in ESP tunnel mode and in transport mode the addresses in the IP header are protected via the SAD. -dave -----Original Message----- From: rupesh [mailto:rupesh.jain@cdac.ernet.in] Sent: Tuesday, March 28, 2000 3:41 AM To: Root Shin Cc: ipsec@lists.tislabs.com Subject: Re: >>2) ESP is Encapsulation Security Payload : It provides optional >>Authentication as well as optional Encryption. One of the service MUST be >>selected. It provides these services Upper layer protocols & not IP layer. > --------------------------------------------------------- > >Could you explain detail? >"It provides these services Upper layer protocols & not IP layer." ---------------------------------------------------------------------------- -------------------- It means Encryption is applied to TCP/UDP or may be other Upper layer protocols & there headers and data are in encrypted form.But , IP header & it's data is still in cleartext form.So, anyone can view IP header & it's data. Same , Authentication mechanism is applied to TCP/UDP or other Upper layer protocols & not to IP header.So, someone can change IP header & data. Reg Rupesh > > > >>-----Original Message----- >>From: neha dharia >>To: >>Date: Monday, March 27, 2000 11:04 PM >> >> >>>What's the diffrenc between AH and ESP Protocols? >>> >>>______________________________________________________ >>>Get Your Private, Free Email at http://www.hotmail.com >>> >> >> >> From owner-ipsec@lists.tislabs.com Tue Mar 28 11:01:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07405; Tue, 28 Mar 2000 11:01:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29804 Tue, 28 Mar 2000 12:28:38 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B789009@md-exchange1.nai.com> From: "Mason, David" To: "'sami.vaarala@netseal.com'" , ipsec@lists.tislabs.com Subject: RE: ISAKMP commit bit and connected notifications Date: Tue, 28 Mar 2000 09:30:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The commit bit is mainly there for implementations that cannot handle dropped packets or out-of-order IKE/IPSec packets (i.e., system receives IPSec packet for an SA when the 3rd QM message for that SA was dropped or isn't processed yet). The Commit bit is one option for how an implementation can deal with this dropped packet/out-of-order packet scenario. An alternative to using the commit bit is given in Section 3.1 of RFC2408 (ISAKMP) in the NOTE: under the Commit Bit paragraph where it suggests that a properly authenticated IPSec packet can in effect take the place of the missing 3rd QM message. I'd love to see the commit bit go away even at the expense of the "Quick Mode" always being 4 messages (for those implementations that preferred the commit bit option for handling the situation described above). A 4 message Phase 2 exchange would allow for the added benefit of DH group negotiation. Another option that at least one implementation uses (which thankfully isn't recommended by any RFC) is to send out several copies of the 3rd QM message. This might help the dropped packet situation somewhat but doesn't do anything to help the out-of-order packet situation and I would recommend strongly against using this option. -dave -----Original Message----- From: sami.vaarala@netseal.com [mailto:sami.vaarala@netseal.com] Sent: Tuesday, March 28, 2000 5:48 AM To: ipsec@lists.tislabs.com Subject: ISAKMP commit bit and connected notifications Sorry for bringing this up yet again, Can anyone give a solid reasoning as to WHY we need commit bit or connected notifications at all? As far as I can tell, a connected notification does not guarantee a consistent outcome of an exchange any more than an exchange without a connected notification. The "three army" problem seems to apply: - if the last message IS critical to the consistent completion, it must not be dropped or otherwise the exchange fails to complete consistently [if not, this message is not critical after all, right?] - on the other hand, if the message is not critical, we can remove the message from the exchange. - continuing this way, we end up in a situation where the last message is critical [for IKE, connected notifications are non-critical]. Yet, we cannot guarantee its delivery (by the very nature of IP). As far as I can see, the best (only?) solution is to keep connection state for a while after sending the last message. If a duplicate of a previous message arrives, resend the last message. Keep doing this for some sane timeout value (e.g. 3*round-trip), perhaps applying a sanity rate limiter to avoid flood attacks. This guarantees consistent completion to a certain probability (not 100%), which you can tune by choosing an appropriate timeout value. (The same reasoning applies to e.g. TCP connection teardown; there is no 100% guaranteed way of tearing down a TCP connection and TCP uses a similar timeout strategy.) Do others agree with this reasoning? If so, I suggest the following: - deprecate the commit bit from ISAKMP (or the IKE exchanges) - add wordage about proper behavior wrt last exchange message (encourage a behavior that works robustly) to either ISAKMP or IKE spec - acknowledged notifications should mandate this last message behavior (otherwise they aren't any more guaranteed than normal notifications) - normal notifications cannot benefit from the last message strategy because there is only one message to send; wordage about this should be added to clarify the difference between acknowledged notifications This is a "phase out" strategy; older implementations may continue to support commit bit but newer ones should not mandate commit bit processing. -- Sami Vaarala (sami.vaarala@netseal.com) NetSeal Technologies http://www.netseal.com/ From owner-ipsec@lists.tislabs.com Tue Mar 28 14:32:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10664; Tue, 28 Mar 2000 14:32:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00646 Tue, 28 Mar 2000 15:46:01 -0500 (EST) Date: Tue, 28 Mar 2000 12:51:16 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Henry Spencer cc: IP Security List Subject: Re: Heartbeats draft (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk An invalid SPI error can be the trigger point (along with other carefully selected conditions). The peer that just came up will know the tunnel/transport end point of the peer who is trying to send traffic, and it can initiate a Main Mode SA to that endpoint. This peer should also include the initial contact, so that the SADs can be sync'ed back again. If there is some traffic originating on the side of the peer that went down, then it has to initiate an SA negotiation anyway. An initial contact will sync the SADs again. -chinna On Tue, 28 Mar 2000, Henry Spencer wrote: > On Mon, 27 Mar 2000, chinna pellacuru wrote: > > When one of the peer goes down, and comes back up, as I said before, the peer > > that went down can ("intellegently") initiate fresh SAs with the Initial > > Contact... > > This assumes that the peer which went down is aware, when it comes back > up, that it *should* initiate fresh SAs. That is not necessarily true. > If it were, life would indeed be much simpler. > > In a world of fixed, static, pre-arranged VPN connections, each end can be > told to re-initiate when it comes back up. Unfortunately, many people > wish to use IPSec in much more dynamic situations, where only one end may > be aware of the immediate desire to send packets. How does a rebooted > server determine which of its potential clients it should re-initiate > with? It may not even know their IP addresses! > > Henry Spencer > henry@spsystems.net > > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue Mar 28 14:46:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10881; Tue, 28 Mar 2000 14:46:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00708 Tue, 28 Mar 2000 16:07:27 -0500 (EST) Date: Tue, 28 Mar 2000 13:12:54 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Henry Spencer cc: IP Security List Subject: Re: Heartbeats draft (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Realistically how often does a server reboot? If the server is rebooting too often, then I guess we would be much better off, if we fixed the server, instead of trying to handle this scenario as if it is such a common scenario in IPSec. -chinna On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > An invalid SPI error can be the trigger point (along with other carefully > selected conditions). The peer that just came up will know the > tunnel/transport end point of the peer who is trying to send traffic, and > it can initiate a Main Mode SA to that endpoint. This peer should also > include the initial contact, so that the SADs can be sync'ed back again. > > If there is some traffic originating on the side of the peer that went > down, then it has to initiate an SA negotiation anyway. An initial contact > will sync the SADs again. > -chinna > > On Tue, 28 Mar 2000, Henry Spencer wrote: > > > On Mon, 27 Mar 2000, chinna pellacuru wrote: > > > When one of the peer goes down, and comes back up, as I said before, the peer > > > that went down can ("intellegently") initiate fresh SAs with the Initial > > > Contact... > > > > This assumes that the peer which went down is aware, when it comes back > > up, that it *should* initiate fresh SAs. That is not necessarily true. > > If it were, life would indeed be much simpler. > > > > In a world of fixed, static, pre-arranged VPN connections, each end can be > > told to re-initiate when it comes back up. Unfortunately, many people > > wish to use IPSec in much more dynamic situations, where only one end may > > be aware of the immediate desire to send packets. How does a rebooted > > server determine which of its potential clients it should re-initiate > > with? It may not even know their IP addresses! > > > > Henry Spencer > > henry@spsystems.net > > > > > > > > chinna narasimha reddy pellacuru > s/w engineer > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue Mar 28 15:29:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11503; Tue, 28 Mar 2000 15:29:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00890 Tue, 28 Mar 2000 16:58:02 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 28 Mar 2000 14:01:38 -0800 (PST) From: Jan Vilhuber To: "CHINNA N.R. PELLACURU" cc: Henry Spencer , IP Security List Subject: Re: Heartbeats draft (fwd) 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, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > An invalid SPI error can be the trigger point (along with other carefully > selected conditions). The peer that just came up will know the > tunnel/transport end point of the peer who is trying to send traffic, and > it can initiate a Main Mode SA to that endpoint. This peer should also > include the initial contact, so that the SADs can be sync'ed back again. > Some would consider that a potential denial-of-service attack, since I can send you dozens of spoofed packets with random spi's.. jan > If there is some traffic originating on the side of the peer that went > down, then it has to initiate an SA negotiation anyway. An initial contact > will sync the SADs again. > -chinna > > On Tue, 28 Mar 2000, Henry Spencer wrote: > > > On Mon, 27 Mar 2000, chinna pellacuru wrote: > > > When one of the peer goes down, and comes back up, as I said before, the peer > > > that went down can ("intellegently") initiate fresh SAs with the Initial > > > Contact... > > > > This assumes that the peer which went down is aware, when it comes back > > up, that it *should* initiate fresh SAs. That is not necessarily true. > > If it were, life would indeed be much simpler. > > > > In a world of fixed, static, pre-arranged VPN connections, each end can be > > told to re-initiate when it comes back up. Unfortunately, many people > > wish to use IPSec in much more dynamic situations, where only one end may > > be aware of the immediate desire to send packets. How does a rebooted > > server determine which of its potential clients it should re-initiate > > with? It may not even know their IP addresses! > > > > Henry Spencer > > henry@spsystems.net > > > > > > > > chinna narasimha reddy pellacuru > s/w engineer > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Mar 28 15:30:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11525; Tue, 28 Mar 2000 15:30:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00887 Tue, 28 Mar 2000 16:58:00 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 28 Mar 2000 14:02:23 -0800 (PST) From: Jan Vilhuber To: "CHINNA N.R. PELLACURU" cc: Henry Spencer , IP Security List Subject: Re: Heartbeats draft (fwd) 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, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > Realistically how often does a server reboot? If the server is rebooting > too often, then I guess we would be much better off, if we fixed the > server, instead of trying to handle this scenario as if it is such a > common scenario in IPSec. In an ideal world, yes. Now in the REAL world, we do have to worry about these things. jan > -chinna > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > > An invalid SPI error can be the trigger point (along with other carefully > > selected conditions). The peer that just came up will know the > > tunnel/transport end point of the peer who is trying to send traffic, and > > it can initiate a Main Mode SA to that endpoint. This peer should also > > include the initial contact, so that the SADs can be sync'ed back again. > > > > If there is some traffic originating on the side of the peer that went > > down, then it has to initiate an SA negotiation anyway. An initial contact > > will sync the SADs again. > > -chinna > > > > On Tue, 28 Mar 2000, Henry Spencer wrote: > > > > > On Mon, 27 Mar 2000, chinna pellacuru wrote: > > > > When one of the peer goes down, and comes back up, as I said before, the peer > > > > that went down can ("intellegently") initiate fresh SAs with the Initial > > > > Contact... > > > > > > This assumes that the peer which went down is aware, when it comes back > > > up, that it *should* initiate fresh SAs. That is not necessarily true. > > > If it were, life would indeed be much simpler. > > > > > > In a world of fixed, static, pre-arranged VPN connections, each end can be > > > told to re-initiate when it comes back up. Unfortunately, many people > > > wish to use IPSec in much more dynamic situations, where only one end may > > > be aware of the immediate desire to send packets. How does a rebooted > > > server determine which of its potential clients it should re-initiate > > > with? It may not even know their IP addresses! > > > > > > Henry Spencer > > > henry@spsystems.net > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > > > chinna narasimha reddy pellacuru > s/w engineer > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Mar 28 16:16:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12226; Tue, 28 Mar 2000 16:16:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00971 Tue, 28 Mar 2000 17:50:32 -0500 (EST) Date: Tue, 28 Mar 2000 14:56:57 -0800 From: Skye Poier To: ipsec@lists.tislabs.com Subject: Open Source IPSec & accelerator cards Message-ID: <20000328145657.H52760@ffwd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-URL: http://www.ffwd.com/ Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Can anyone give me a list of open source IPSec implementations that can utilize crypto acceleration cards? Namely: FreeSWAN (as far as I can tell, none supported) OpenBSD's built in IPSec KAME others? Thanks Skye -- Clarity of thought should be accompanied by clarity of technique - Mondriaan Powered by ffwd internet division [ http://www.ffwd.com/ ] From owner-ipsec@lists.tislabs.com Tue Mar 28 16:36:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12688; Tue, 28 Mar 2000 16:36:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01032 Tue, 28 Mar 2000 18:07:55 -0500 (EST) Message-ID: <38E13CB3.54A4DEB@redcreek.com> Date: Wed, 29 Mar 2000 08:43:55 +0930 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rupesh CC: =?iso-8859-1?Q?=C0=B1=C1=D6=B4=E7=2E=2E?= , ipsec@lists.tislabs.com Subject: Re: How to call from kernel to user program References: <004501bf987b$b597ff60$2dcd09c0@nig95> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please stop sending html-based email to this list. From owner-ipsec@lists.tislabs.com Tue Mar 28 16:36:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12711; Tue, 28 Mar 2000 16:36:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01073 Tue, 28 Mar 2000 18:14:47 -0500 (EST) Message-ID: <38E13E50.2A3E9DDE@redcreek.com> Date: Wed, 29 Mar 2000 08:50:48 +0930 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: pcn@cisco.com CC: Chris Trobridge , ipsec mailling list Subject: Re: Heartbeats draft (fwd) References: <1FD60AE4DB6CD2118C420008C74C27B854A082@baltimore.com> <38E07DBC.A3C9F3D6@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Chinna on virtually all points. One additional comment below: chinna pellacuru wrote: > Firstly heartbeats are not going to be 'cheap', atleast from our experience they > are not cheap even without the equivalent of SPI lists. If you had a lot of > peers, and if you use the recommended heartbeat interval of 20 seconds, then the > box is sending/processing a considerable amount of heartbeat traffic. The proposed mechanism adds a sliding window computation on the receiver. In the remote access case (the most common case, I think the receiver is that gateway. This becomes significant as the number of SAs becomes large. Scott From owner-ipsec@lists.tislabs.com Tue Mar 28 18:19:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16760; Tue, 28 Mar 2000 18:19:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01376 Tue, 28 Mar 2000 19:45:39 -0500 (EST) To: Skye Poier cc: ipsec@lists.tislabs.com In-reply-to: skye's message of Tue, 28 Mar 2000 14:56:57 PST. <20000328145657.H52760@ffwd.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: Open Source IPSec & accelerator cards From: Jun-ichiro itojun Hagino Date: Wed, 29 Mar 2000 09:50:19 +0900 Message-ID: <1041.954291019@lychee.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Hello, >Can anyone give me a list of open source IPSec implementations that can >utilize crypto acceleration cards? Namely: > >FreeSWAN (as far as I can tell, none supported) >OpenBSD's built in IPSec >KAME >others? The status I know of: - Recently OpenBSD IPsec guys are actively working on this. You may want to check the latest OpenBSD-current tree. - Unfortunately KAME has no integrated support for hardware crypto device yet. As one of KAME developer I'll be very happy to help you. itojun From owner-ipsec@lists.tislabs.com Tue Mar 28 18:47:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19376; Tue, 28 Mar 2000 18:47:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01557 Tue, 28 Mar 2000 20:25:10 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 28 Mar 2000 17:30:50 -0800 (PST) From: Jan Vilhuber To: "CHINNA N.R. PELLACURU" cc: Henry Spencer , IP Security List Subject: Re: Heartbeats draft (fwd) 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, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > I am not saying that we should totally ingnore this case, and I proposed > an alternative approach. What I am saying is that we don't have to make > IKE suite of protocols so chatty, just to handle conditions like "server > crashed", or "someone accidentaly switched the server off" etc. Such > chatty approaches to the problem are not very desirable in dialup > scenarios anyway, and I guess dialup is a significant protion of the > deployment. > I personally don't believe that. A portion, yes. How significant remains to be seen, given the advent of DSL and cable-modems, which are always on. I've already pointed out to Andrew that his scheme doesn't work well in ISDN/analog dial-up scenarios anyway, where you pay per-minute charges and heartbeats would keep the line up. In the interest of standardizing on at least ONE approach, I'm willing to sacrifice that. Afterall, I can define a new keepalive-type in Andrew's configuration scheme and write a draft about the dial-up-specific keepalives, and I'm on my way, and I'm not impeding the progress of at least ONE standardized keepalives. Also, a client that is behind a dial-up line, can simply refuse to do heartbeats during negotiation, and you're still no worse off. It can't solve EVERY problem in the universe. Let's let it solve the majority of the problems, and other cases we'll find other solutions for. > So, by heartbeats you are trying to have an expensive solution to a rarely > occuring problem ("peer going down"), and the solution may not be suitable > for most of the deployments (dialup). > Again assuming that 'most' is correct in the paragraph above, which I disagree with. jan > -chinna > > On Tue, 28 Mar 2000, Jan Vilhuber wrote: > > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > > Realistically how often does a server reboot? If the server is rebooting > > > too often, then I guess we would be much better off, if we fixed the > > > server, instead of trying to handle this scenario as if it is such a > > > common scenario in IPSec. > > > > In an ideal world, yes. Now in the REAL world, we do have to worry about > > these things. > > > > jan > > > > > > > -chinna > > > > > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > > > > > > An invalid SPI error can be the trigger point (along with other carefully > > > > selected conditions). The peer that just came up will know the > > > > tunnel/transport end point of the peer who is trying to send traffic, and > > > > it can initiate a Main Mode SA to that endpoint. This peer should also > > > > include the initial contact, so that the SADs can be sync'ed back again. > > > > > > > > If there is some traffic originating on the side of the peer that went > > > > down, then it has to initiate an SA negotiation anyway. An initial contact > > > > will sync the SADs again. > > > > -chinna > > > > > > > > On Tue, 28 Mar 2000, Henry Spencer wrote: > > > > > > > > > On Mon, 27 Mar 2000, chinna pellacuru wrote: > > > > > > When one of the peer goes down, and comes back up, as I said before, the peer > > > > > > that went down can ("intellegently") initiate fresh SAs with the Initial > > > > > > Contact... > > > > > > > > > > This assumes that the peer which went down is aware, when it comes back > > > > > up, that it *should* initiate fresh SAs. That is not necessarily true. > > > > > If it were, life would indeed be much simpler. > > > > > > > > > > In a world of fixed, static, pre-arranged VPN connections, each end can be > > > > > told to re-initiate when it comes back up. Unfortunately, many people > > > > > wish to use IPSec in much more dynamic situations, where only one end may > > > > > be aware of the immediate desire to send packets. How does a rebooted > > > > > server determine which of its potential clients it should re-initiate > > > > > with? It may not even know their IP addresses! > > > > > > > > > > Henry Spencer > > > > > henry@spsystems.net > > > > > > > > > > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > > s/w engineer > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > > > > chinna narasimha reddy pellacuru > s/w engineer > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Mar 28 18:52:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20110; Tue, 28 Mar 2000 18:52:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01497 Tue, 28 Mar 2000 20:19:54 -0500 (EST) Date: Tue, 28 Mar 2000 17:25:21 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Jan Vilhuber cc: Henry Spencer , IP Security List Subject: Re: Heartbeats draft (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am not saying that we should totally ingnore this case, and I proposed an alternative approach. What I am saying is that we don't have to make IKE suite of protocols so chatty, just to handle conditions like "server crashed", or "someone accidentaly switched the server off" etc. Such chatty approaches to the problem are not very desirable in dialup scenarios anyway, and I guess dialup is a significant protion of the deployment. So, by heartbeats you are trying to have an expensive solution to a rarely occuring problem ("peer going down"), and the solution may not be suitable for most of the deployments (dialup). -chinna On Tue, 28 Mar 2000, Jan Vilhuber wrote: > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > Realistically how often does a server reboot? If the server is rebooting > > too often, then I guess we would be much better off, if we fixed the > > server, instead of trying to handle this scenario as if it is such a > > common scenario in IPSec. > > In an ideal world, yes. Now in the REAL world, we do have to worry about > these things. > > jan > > > > -chinna > > > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > > > > An invalid SPI error can be the trigger point (along with other carefully > > > selected conditions). The peer that just came up will know the > > > tunnel/transport end point of the peer who is trying to send traffic, and > > > it can initiate a Main Mode SA to that endpoint. This peer should also > > > include the initial contact, so that the SADs can be sync'ed back again. > > > > > > If there is some traffic originating on the side of the peer that went > > > down, then it has to initiate an SA negotiation anyway. An initial contact > > > will sync the SADs again. > > > -chinna > > > > > > On Tue, 28 Mar 2000, Henry Spencer wrote: > > > > > > > On Mon, 27 Mar 2000, chinna pellacuru wrote: > > > > > When one of the peer goes down, and comes back up, as I said before, the peer > > > > > that went down can ("intellegently") initiate fresh SAs with the Initial > > > > > Contact... > > > > > > > > This assumes that the peer which went down is aware, when it comes back > > > > up, that it *should* initiate fresh SAs. That is not necessarily true. > > > > If it were, life would indeed be much simpler. > > > > > > > > In a world of fixed, static, pre-arranged VPN connections, each end can be > > > > told to re-initiate when it comes back up. Unfortunately, many people > > > > wish to use IPSec in much more dynamic situations, where only one end may > > > > be aware of the immediate desire to send packets. How does a rebooted > > > > server determine which of its potential clients it should re-initiate > > > > with? It may not even know their IP addresses! > > > > > > > > Henry Spencer > > > > henry@spsystems.net > > > > > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue Mar 28 18:56:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20588; Tue, 28 Mar 2000 18:56:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01607 Tue, 28 Mar 2000 20:27:14 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 28 Mar 2000 17:32:54 -0800 (PST) From: Jan Vilhuber To: "CHINNA N.R. PELLACURU" cc: Henry Spencer , IP Security List Subject: Re: Heartbeats draft (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Granted, but 'one more place' is 'one more attack'. Just because DOS is a problem doesn't mean we should give attackers ever more places to do DOS attacks through. I realize it can be bounded (as Dan pointed out in San Diego), but I think it's a dangerous thing to do. Not to be taken lightly at all. And there will always be people that will refuse to 'just initiate' so I think a more general solution that does NOT rely on initiating based on unknown SPI's is called for. jan On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > I have addressed the DOS risk in another mail, and I feel that the risk > can be bounded easily. You have to deal with DOS in every aspect of IKE, > and this is just one more place. > > -chinna > > On Tue, 28 Mar 2000, Jan Vilhuber wrote: > > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > > An invalid SPI error can be the trigger point (along with other carefully > > > selected conditions). The peer that just came up will know the > > > tunnel/transport end point of the peer who is trying to send traffic, and > > > it can initiate a Main Mode SA to that endpoint. This peer should also > > > include the initial contact, so that the SADs can be sync'ed back again. > > > > > Some would consider that a potential denial-of-service attack, since I can > > send you dozens of spoofed packets with random spi's.. > > > > jan > > > > > > > If there is some traffic originating on the side of the peer that went > > > down, then it has to initiate an SA negotiation anyway. An initial contact > > > will sync the SADs again. > > > -chinna > > > > > > On Tue, 28 Mar 2000, Henry Spencer wrote: > > > > > > > On Mon, 27 Mar 2000, chinna pellacuru wrote: > > > > > When one of the peer goes down, and comes back up, as I said before, the peer > > > > > that went down can ("intellegently") initiate fresh SAs with the Initial > > > > > Contact... > > > > > > > > This assumes that the peer which went down is aware, when it comes back > > > > up, that it *should* initiate fresh SAs. That is not necessarily true. > > > > If it were, life would indeed be much simpler. > > > > > > > > In a world of fixed, static, pre-arranged VPN connections, each end can be > > > > told to re-initiate when it comes back up. Unfortunately, many people > > > > wish to use IPSec in much more dynamic situations, where only one end may > > > > be aware of the immediate desire to send packets. How does a rebooted > > > > server determine which of its potential clients it should re-initiate > > > > with? It may not even know their IP addresses! > > > > > > > > Henry Spencer > > > > henry@spsystems.net > > > > > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > > > > chinna narasimha reddy pellacuru > s/w engineer > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Mar 28 18:58:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20805; Tue, 28 Mar 2000 18:58:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01551 Tue, 28 Mar 2000 20:24:54 -0500 (EST) Date: Tue, 28 Mar 2000 17:30:37 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Jan Vilhuber cc: Henry Spencer , IP Security List Subject: Re: Heartbeats draft (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have addressed the DOS risk in another mail, and I feel that the risk can be bounded easily. You have to deal with DOS in every aspect of IKE, and this is just one more place. -chinna On Tue, 28 Mar 2000, Jan Vilhuber wrote: > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > An invalid SPI error can be the trigger point (along with other carefully > > selected conditions). The peer that just came up will know the > > tunnel/transport end point of the peer who is trying to send traffic, and > > it can initiate a Main Mode SA to that endpoint. This peer should also > > include the initial contact, so that the SADs can be sync'ed back again. > > > Some would consider that a potential denial-of-service attack, since I can > send you dozens of spoofed packets with random spi's.. > > jan > > > > If there is some traffic originating on the side of the peer that went > > down, then it has to initiate an SA negotiation anyway. An initial contact > > will sync the SADs again. > > -chinna > > > > On Tue, 28 Mar 2000, Henry Spencer wrote: > > > > > On Mon, 27 Mar 2000, chinna pellacuru wrote: > > > > When one of the peer goes down, and comes back up, as I said before, the peer > > > > that went down can ("intellegently") initiate fresh SAs with the Initial > > > > Contact... > > > > > > This assumes that the peer which went down is aware, when it comes back > > > up, that it *should* initiate fresh SAs. That is not necessarily true. > > > If it were, life would indeed be much simpler. > > > > > > In a world of fixed, static, pre-arranged VPN connections, each end can be > > > told to re-initiate when it comes back up. Unfortunately, many people > > > wish to use IPSec in much more dynamic situations, where only one end may > > > be aware of the immediate desire to send packets. How does a rebooted > > > server determine which of its potential clients it should re-initiate > > > with? It may not even know their IP addresses! > > > > > > Henry Spencer > > > henry@spsystems.net > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue Mar 28 19:09:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA21765; Tue, 28 Mar 2000 19:09:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA01660 Tue, 28 Mar 2000 20:40:40 -0500 (EST) Date: Tue, 28 Mar 2000 17:46:06 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Jan Vilhuber cc: Henry Spencer , IP Security List Subject: Re: Heartbeats draft (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Probably we can be more specific(after some experimentation) about under what conditions we initiate, then try to analyse the risk. I am sure it is not very hard to come up with a simple algorithm, that can bound the risk. I think we can be smart about initiating, and it is not a major risk. Considering the recent discussion on cookies on this mialing list, I wonder how many implementations are handling the DOS risk, even in the responder case. Making the IKE protocol chatty, with expensive heartbeats to save ourselves from DOS doesn't look very logical to me. -chinna On Tue, 28 Mar 2000, Jan Vilhuber wrote: > Granted, but 'one more place' is 'one more attack'. Just because DOS is a > problem doesn't mean we should give attackers ever more places to do DOS > attacks through. > > I realize it can be bounded (as Dan pointed out in San Diego), but I think > it's a dangerous thing to do. Not to be taken lightly at all. And there will > always be people that will refuse to 'just initiate' so I think a more > general solution that does NOT rely on initiating based on unknown SPI's is > called for. > > jan > > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > > I have addressed the DOS risk in another mail, and I feel that the risk > > can be bounded easily. You have to deal with DOS in every aspect of IKE, > > and this is just one more place. > > > > -chinna > > > > On Tue, 28 Mar 2000, Jan Vilhuber wrote: > > > > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > > > An invalid SPI error can be the trigger point (along with other carefully > > > > selected conditions). The peer that just came up will know the > > > > tunnel/transport end point of the peer who is trying to send traffic, and > > > > it can initiate a Main Mode SA to that endpoint. This peer should also > > > > include the initial contact, so that the SADs can be sync'ed back again. > > > > > > > Some would consider that a potential denial-of-service attack, since I can > > > send you dozens of spoofed packets with random spi's.. > > > > > > jan > > > > > > > > > > If there is some traffic originating on the side of the peer that went > > > > down, then it has to initiate an SA negotiation anyway. An initial contact > > > > will sync the SADs again. > > > > -chinna > > > > > > > > On Tue, 28 Mar 2000, Henry Spencer wrote: > > > > > > > > > On Mon, 27 Mar 2000, chinna pellacuru wrote: > > > > > > When one of the peer goes down, and comes back up, as I said before, the peer > > > > > > that went down can ("intellegently") initiate fresh SAs with the Initial > > > > > > Contact... > > > > > > > > > > This assumes that the peer which went down is aware, when it comes back > > > > > up, that it *should* initiate fresh SAs. That is not necessarily true. > > > > > If it were, life would indeed be much simpler. > > > > > > > > > > In a world of fixed, static, pre-arranged VPN connections, each end can be > > > > > told to re-initiate when it comes back up. Unfortunately, many people > > > > > wish to use IPSec in much more dynamic situations, where only one end may > > > > > be aware of the immediate desire to send packets. How does a rebooted > > > > > server determine which of its potential clients it should re-initiate > > > > > with? It may not even know their IP addresses! > > > > > > > > > > Henry Spencer > > > > > henry@spsystems.net > > > > > > > > > > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > > s/w engineer > > > > > > > > > > > > > > -- > > > Jan Vilhuber vilhuber@cisco.com > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue Mar 28 19:55:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25484; Tue, 28 Mar 2000 19:55:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01803 Tue, 28 Mar 2000 21:22:28 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 28 Mar 2000 18:27:16 -0800 (PST) From: Jan Vilhuber To: "CHINNA N.R. PELLACURU" cc: Henry Spencer , IP Security List Subject: Re: Heartbeats draft (fwd) 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, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > Probably we can be more specific(after some experimentation) about under > what conditions we initiate, then try to analyse the risk. I am sure it is > not very hard to come up with a simple algorithm, that can bound the risk. > I think we can be smart about initiating, and it is not a major risk. > > Considering the recent discussion on cookies on this mialing list, I > wonder how many implementations are handling the DOS risk, even in the > responder case. > > Making the IKE protocol chatty, with expensive heartbeats to save > ourselves from DOS doesn't look very logical to me. > I really don't get your logic. It seems faulty to me. Just because there's issues with cookies doesn't mean we should add yet ANOTHER way that IKE can be taken down via DOS (bounded.. yes yes...). Also, we're not creating an, as you put it, 'chatty protocol', JUST to save ourselves from DOS stuff. We're creating this protocol to do keepalives which serve a useful purpose, besides DOS stuff. I'm not following you at all. jan > -chinna > > On Tue, 28 Mar 2000, Jan Vilhuber wrote: > > > Granted, but 'one more place' is 'one more attack'. Just because DOS is a > > problem doesn't mean we should give attackers ever more places to do DOS > > attacks through. > > > > I realize it can be bounded (as Dan pointed out in San Diego), but I think > > it's a dangerous thing to do. Not to be taken lightly at all. And there will > > always be people that will refuse to 'just initiate' so I think a more > > general solution that does NOT rely on initiating based on unknown SPI's is > > called for. > > > > jan > > > > > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > > > > I have addressed the DOS risk in another mail, and I feel that the risk > > > can be bounded easily. You have to deal with DOS in every aspect of IKE, > > > and this is just one more place. > > > > > > -chinna > > > > > > On Tue, 28 Mar 2000, Jan Vilhuber wrote: > > > > > > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > > > > An invalid SPI error can be the trigger point (along with other carefully > > > > > selected conditions). The peer that just came up will know the > > > > > tunnel/transport end point of the peer who is trying to send traffic, and > > > > > it can initiate a Main Mode SA to that endpoint. This peer should also > > > > > include the initial contact, so that the SADs can be sync'ed back again. > > > > > > > > > Some would consider that a potential denial-of-service attack, since I can > > > > send you dozens of spoofed packets with random spi's.. > > > > > > > > jan > > > > > > > > > > > > > If there is some traffic originating on the side of the peer that went > > > > > down, then it has to initiate an SA negotiation anyway. An initial contact > > > > > will sync the SADs again. > > > > > -chinna > > > > > > > > > > On Tue, 28 Mar 2000, Henry Spencer wrote: > > > > > > > > > > > On Mon, 27 Mar 2000, chinna pellacuru wrote: > > > > > > > When one of the peer goes down, and comes back up, as I said before, the peer > > > > > > > that went down can ("intellegently") initiate fresh SAs with the Initial > > > > > > > Contact... > > > > > > > > > > > > This assumes that the peer which went down is aware, when it comes back > > > > > > up, that it *should* initiate fresh SAs. That is not necessarily true. > > > > > > If it were, life would indeed be much simpler. > > > > > > > > > > > > In a world of fixed, static, pre-arranged VPN connections, each end can be > > > > > > told to re-initiate when it comes back up. Unfortunately, many people > > > > > > wish to use IPSec in much more dynamic situations, where only one end may > > > > > > be aware of the immediate desire to send packets. How does a rebooted > > > > > > server determine which of its potential clients it should re-initiate > > > > > > with? It may not even know their IP addresses! > > > > > > > > > > > > Henry Spencer > > > > > > henry@spsystems.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > > > s/w engineer > > > > > > > > > > > > > > > > > > -- > > > > Jan Vilhuber vilhuber@cisco.com > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > > > > chinna narasimha reddy pellacuru > s/w engineer > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Mar 28 23:24:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA09304; Tue, 28 Mar 2000 23:24:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA02232 Wed, 29 Mar 2000 00:07:51 -0500 (EST) Date: Tue, 28 Mar 2000 21:13:17 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Jan Vilhuber cc: Henry Spencer , IP Security List Subject: Re: Heartbeats draft (fwd) 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, 28 Mar 2000, Jan Vilhuber wrote: > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > Probably we can be more specific(after some experimentation) about under > > what conditions we initiate, then try to analyse the risk. I am sure it is > > not very hard to come up with a simple algorithm, that can bound the risk. > > I think we can be smart about initiating, and it is not a major risk. > > > > Considering the recent discussion on cookies on this mialing list, I > > wonder how many implementations are handling the DOS risk, even in the > > responder case. > > > > Making the IKE protocol chatty, with expensive heartbeats to save > > ourselves from DOS doesn't look very logical to me. > > > I really don't get your logic. It seems faulty to me. If you look at the two proposals for solving the problem of syncing peers when one of them goes down (which I think is a fairly corner case): heartbeats/no heartbeats. Heartbeats solution is chatty, and it sucks up a lot of processing and bandwidth, but it doesn't have any DOS considerations. And the major disadvantage is that it is not very acceptable in dialer scenarios, which represent a major portion of our deployment base for IPSec. No heartbeats solution has some DOS considerations, that I feel are EASY to tackle. Advantages are it can be used in dial environments, and not bandwidth/processing intensive. So, I feel that we should tackle the DOS issues here, instead of imposing an un-ending DOS attack on ourselves by doing Heartbeats, once every 20 seconds (the recommended heartbeat interval) to all the peers in the world that we know of. This doesn't scale. I would rather prefer to tackle the DOS issues, and save processing and bandwidth for sending real traffic. > > Just because there's issues with cookies doesn't mean we should add yet > ANOTHER way that IKE can be taken down via DOS (bounded.. yes yes...). > For any protocol, bad implementations can be brought down, and that doesn't mean that it is a failure of the protocol. I guess it is pretty sraight forward to avoid any DOS vulnerablity in this case, and if the implementation chooses to be dumb about it, then I guess it is the implementation's problem, and not a protocol problem. > Also, we're not creating an, as you put it, 'chatty protocol', JUST to save > ourselves from DOS stuff. We're creating this protocol to do keepalives which > serve a useful purpose, besides DOS stuff. > The problem that the heartbeats are trying to solve, can be solved even without them. If you have any specific scenario where heartbeats are the only solution to the problem, please post it. -chinna > I'm not following you at all. > jan > > > > -chinna > > > > On Tue, 28 Mar 2000, Jan Vilhuber wrote: > > > > > Granted, but 'one more place' is 'one more attack'. Just because DOS is a > > > problem doesn't mean we should give attackers ever more places to do DOS > > > attacks through. > > > > > > I realize it can be bounded (as Dan pointed out in San Diego), but I think > > > it's a dangerous thing to do. Not to be taken lightly at all. And there will > > > always be people that will refuse to 'just initiate' so I think a more > > > general solution that does NOT rely on initiating based on unknown SPI's is > > > called for. > > > > > > jan > > > > > > > > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > > > > > > I have addressed the DOS risk in another mail, and I feel that the risk > > > > can be bounded easily. You have to deal with DOS in every aspect of IKE, > > > > and this is just one more place. > > > > > > > > -chinna > > > > > > > > On Tue, 28 Mar 2000, Jan Vilhuber wrote: > > > > > > > > > On Tue, 28 Mar 2000, CHINNA N.R. PELLACURU wrote: > > > > > > An invalid SPI error can be the trigger point (along with other carefully > > > > > > selected conditions). The peer that just came up will know the > > > > > > tunnel/transport end point of the peer who is trying to send traffic, and > > > > > > it can initiate a Main Mode SA to that endpoint. This peer should also > > > > > > include the initial contact, so that the SADs can be sync'ed back again. > > > > > > > > > > > Some would consider that a potential denial-of-service attack, since I can > > > > > send you dozens of spoofed packets with random spi's.. > > > > > > > > > > jan > > > > > > > > > > > > > > > > If there is some traffic originating on the side of the peer that went > > > > > > down, then it has to initiate an SA negotiation anyway. An initial contact > > > > > > will sync the SADs again. > > > > > > -chinna > > > > > > > > > > > > On Tue, 28 Mar 2000, Henry Spencer wrote: > > > > > > > > > > > > > On Mon, 27 Mar 2000, chinna pellacuru wrote: > > > > > > > > When one of the peer goes down, and comes back up, as I said before, the peer > > > > > > > > that went down can ("intellegently") initiate fresh SAs with the Initial > > > > > > > > Contact... > > > > > > > > > > > > > > This assumes that the peer which went down is aware, when it comes back > > > > > > > up, that it *should* initiate fresh SAs. That is not necessarily true. > > > > > > > If it were, life would indeed be much simpler. > > > > > > > > > > > > > > In a world of fixed, static, pre-arranged VPN connections, each end can be > > > > > > > told to re-initiate when it comes back up. Unfortunately, many people > > > > > > > wish to use IPSec in much more dynamic situations, where only one end may > > > > > > > be aware of the immediate desire to send packets. How does a rebooted > > > > > > > server determine which of its potential clients it should re-initiate > > > > > > > with? It may not even know their IP addresses! > > > > > > > > > > > > > > Henry Spencer > > > > > > > henry@spsystems.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > > > > s/w engineer > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Jan Vilhuber vilhuber@cisco.com > > > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > > s/w engineer > > > > > > > > > > -- > > > Jan Vilhuber vilhuber@cisco.com > > > Cisco Systems, San Jose (408) 527-0847 > > > > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed Mar 29 01:18:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA15933; Wed, 29 Mar 2000 01:18:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA02621 Wed, 29 Mar 2000 02:29:24 -0500 (EST) Message-Id: <200003290729.CAA21278@adk.gr> X-Mailer: exmh version 2.0.2 2/24/98 To: Skye Poier Cc: ipsec@lists.tislabs.com Subject: Re: Open Source IPSec & accelerator cards In-reply-to: Your message of "Tue, 28 Mar 2000 14:56:57 PST." <20000328145657.H52760@ffwd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Mar 2000 02:29:16 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20000328145657.H52760@ffwd.com>, Skye Poier writes: >Hello, > >Can anyone give me a list of open source IPSec implementations that can >utilize crypto acceleration cards? Namely: I recently added a crypto hardware framework in OpenBSD, and fix the IPsec stack to take advantage of it (convert from linear processing to callback-based). We have preliminary support for the hifn 7751 chip (which is in fact used in a couple of different products), but it's not fully debugged yet. Probably a couple of weeks away. We're trying to get docs for more crypto cards (and start supporting big-num cards too) -- Intel and 3Com are not being very helpful in providing specs for their new cards though... -Angelos From owner-ipsec@lists.tislabs.com Wed Mar 29 03:57:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25684; Wed, 29 Mar 2000 03:57:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA03446 Wed, 29 Mar 2000 05:29:44 -0500 (EST) Date: Wed, 29 Mar 2000 05:37:39 -0500 From: Richard Guy Briggs To: Skye Poier Cc: ipsec@lists.tislabs.com Subject: Re: Open Source IPSec & accelerator cards Message-ID: <20000329053739.A32339@grendel.conscoop.ottawa.on.ca> References: <20000328145657.H52760@ffwd.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Kj7319i9nmIyA2yE; micalg=pgp-md5; protocol="application/pgp-signature" X-Mailer: Mutt 0.95.7i In-Reply-To: <20000328145657.H52760@ffwd.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Tue, Mar 28, 2000 at 02:56:57PM -0800, Skye Poier wrote: > Hello, >=20 > Can anyone give me a list of open source IPSec implementations that can > utilize crypto acceleration cards? Namely: >=20 > FreeSWAN (as far as I can tell, none supported) We are working with gcrypt (Werner Koch, GPG) and Bart Trojanowski (Chrysalis-ITS) to put in a generic hardware crypto I/F, which will also help to paralellise a purely software deployment by being able to take advantage of SMP machines. > OpenBSD's built in IPSec > KAME > others? >=20 > Skye =2E..in Oz until May, presently 11Mb wireless @ IETF 47 in Adelaide, slainte mhath, RGB --=20 Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada Prevent Internet Wiretapping! -- FreeS/WAN: Thanks for voting Green! -- Marillion: --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3i iQCVAwUBOOHc8d+sBuIhFagtAQGOxAP/e+h8g1HOYw+gpcfugIObGTkY5MkLGBih SY01jv8xO0MJhs/v1sXdKaJAmTYNiM4ww117rFEXgZoPs8PYNPmGeUxwsArfGvsl hZvMni9ZWcSxqTAaBUSRKifmH2JLrONu8LINH3AWol5a06N9RV0tjSF9Ix8quOU8 Ym+BeACqeJg= =GGGs -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-ipsec@lists.tislabs.com Wed Mar 29 06:34:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28864; Wed, 29 Mar 2000 06:34:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04122 Wed, 29 Mar 2000 07:58:09 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Michael Richardson'" , Subject: RE: Heartbeats draft available Date: Wed, 29 Mar 2000 05:47:12 -0500 Message-Id: <000101bf997e$c53299e0$06dba8c0@andrewktest.timestep.com> 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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200003281322.IAA13351@solidum.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > - what's the use of heartbeats on a link that you don't > want to keep alive There's a reason why we call them heartbeats instead of keep-alives. A keep-alive forces the peer to keep the link alive. A heartbeat merely allows the peer to detect if it goes down. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Mar 29 06:35:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28928; Wed, 29 Mar 2000 06:35:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04063 Wed, 29 Mar 2000 07:42:31 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A09E@baltimore.com> From: Chris Trobridge To: IP Security List , "CHINNA N.R. PELLACURU" Subject: RE: Heartbeats draft (fwd) Date: Wed, 29 Mar 2000 13:48:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The problem to solve is to detect when a peer has gone down so that some action can be taken. This action may something other than renegotiating with the same peer - it might mean just deleting the SA or it may mean finding an alternative gateway. This latter case is important in the provision of high availability networks and cannot be solved by the peer renegotiating when it comes back up. The peer might not actually be the equipment at fault or it might be 'lost' permanently. Obviously not every network needs this so it's something that should be configurable (and optional). Heartbeats should only be requested when required and it should be possible for an implmentation to control the quantity of heartbeats it generates and to which peers. I'd still like there to be the option of a phase 1 heartbeat which is only sent in the absence of traffic on any connected phase 2 SAs. This will cover a wide range of situations and means that no heartbeat traffic is generated while the associated SAs are in active use. This would reduce the benefit of the active SA listing and I think that should be optional too. Chris > -----Original Message----- > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > Sent: 29 March 2000 06:13 > To: Jan Vilhuber > Cc: Henry Spencer; IP Security List > Subject: Re: Heartbeats draft (fwd) > > If you look at the two proposals for solving the problem of > syncing peers > when one of them goes down (which I think is a fairly corner case): > heartbeats/no heartbeats. > > Heartbeats solution is chatty, and it sucks up a lot of processing and > bandwidth, but it doesn't have any DOS considerations. And the major > disadvantage is that it is not very acceptable in dialer > scenarios, which > represent a major portion of our deployment base for IPSec. > > No heartbeats solution has some DOS considerations, that I > feel are EASY > to tackle. Advantages are it can be used in dial environments, and not > bandwidth/processing intensive. > > So, I feel that we should tackle the DOS issues here, instead > of imposing > an un-ending DOS attack on ourselves by doing Heartbeats, > once every 20 > seconds (the recommended heartbeat interval) to all the peers > in the world > that we know of. This doesn't scale. I would rather prefer to > tackle the > DOS issues, and save processing and bandwidth for sending > real traffic. > > > > > Just because there's issues with cookies doesn't mean we > should add yet > > ANOTHER way that IKE can be taken down via DOS (bounded.. > yes yes...). > > > > For any protocol, bad implementations can be brought down, and that > doesn't mean that it is a failure of the protocol. I guess it > is pretty > sraight forward to avoid any DOS vulnerablity in this case, and if the > implementation chooses to be dumb about it, then I guess it is the > implementation's problem, and not a protocol problem. > > > Also, we're not creating an, as you put it, 'chatty > protocol', JUST to save > > ourselves from DOS stuff. We're creating this protocol to > do keepalives which > > serve a useful purpose, besides DOS stuff. > > > > The problem that the heartbeats are trying to solve, can be > solved even > without them. If you have any specific scenario where > heartbeats are the > only solution to the problem, please post it. > > -chinna From owner-ipsec@lists.tislabs.com Wed Mar 29 06:40:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29044; Wed, 29 Mar 2000 06:40:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA04121 Wed, 29 Mar 2000 07:58:08 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'ipsec mailling list'" Subject: RE: Heartbeats draft (fwd) Date: Wed, 29 Mar 2000 07:36:43 -0500 Message-Id: <000201bf997e$e1e714d0$06dba8c0@andrewktest.timestep.com> 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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <38E07DBC.A3C9F3D6@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Chinna, > The number of quick mode SAs between two site to site > security gateways can grow > dramatically, and because the SPIs are completely randomly > allocated, we have to > essentially walk through all SPIs that we have with a > particular peer, and then > send the SPIs that are in a particular range. I don't see any > real saving in > processing here, although there is saving on the receiving > side. And I don't see > how we can cleanly comeup with ranges of SPIs that will > actually divide the SPIs > that we have with a peer as we intend to (or atleast > reasonably equally), > because SPIs are supposed to be completely random. If this is really a problem for you then I suggest you invest in some good database software. > If we use > acknowledged delete > notifications, the we pretty much don't have to worry about > any SAD sync issues, > for most of the time. The only place we need to deal with > them would be when a > peer goes down. You don't have to use the SPI list if you don't want to; if you think acknowledge delete notifications are sufficient then by all means use them (the draft recommends it). Of course, acknowledged deletes don't work if the peer can't send them. For example, the peer may periodically dangle the phase 2 SAs, in which case there won't be a phase 1 available on which to send the delete. Alternately, the link may have gone down temporarily, in which case the SADs may be out of synch. > Firstly heartbeats are not going to be 'cheap', atleast from > our experience they > are not cheap even without the equivalent of SPI lists. If > you had a lot of > peers, and if you use the recommended heartbeat interval of > 20 seconds, then the > box is sending/processing a considerable amount of heartbeat traffic. As has been pointed out before, the cost of heartbeats is O(n). This is a theoretical minimum, and I maintain that any alternate scheme you might propose will also be O(n). Yes, if you have N times as many peers then you also have to send N times as many heartbeats. But you are ignoring the fact that you will also have N times as many SAs, which means N times as much traffic, which means that you need an N times bigger box with N times as much CPU power. And this N times bigger box is properly equipped to process N times as many heartbeat packets. And BTW, as technology advances, users will demand more traffic per (phase 1) SA. This will result in heartbeat traffic being an increasingly small percentage of total traffic. > Coming to DOS vulnerability, I am not advocating that we > should try and > negotiate SAs for invalid SPI errors all the time. We can > "intellegently" > initiate SAs only when we detect that we recently restarted, > and limit the > number of times we initiate to a particular peer. Which means that you will be extra vulnerable to DoS attacks right after we restart, which is fine as long as it wasn't a DoS attack which caused you to crash in the first place. Also, I find it abhorent that an attacker would be able to force me to initiate an SA with some arbitrary peer just by sending me an invalid spi notify. Plus, you are ignoring all the other benefits you get from using heartbeats. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Mar 29 08:28:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01387; Wed, 29 Mar 2000 08:28:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05101 Wed, 29 Mar 2000 09:42:46 -0500 (EST) Date: Wed, 29 Mar 2000 06:48:36 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Chris Trobridge cc: IP Security List Subject: RE: Heartbeats draft (fwd) In-Reply-To: <1FD60AE4DB6CD2118C420008C74C27B854A09E@baltimore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If the problem we are trying to solve is high availability (the Heartbeats draft doesn't address this anyway), there are many ways to solve it. We don't have to start with the premise that keepalives are absolutely necessary, and then apply the keepalives solution to all the problems. -chinna On Wed, 29 Mar 2000, Chris Trobridge wrote: > The problem to solve is to detect when a peer has gone down so that some > action can be taken. This action may something other than renegotiating > with the same peer - it might mean just deleting the SA or it may mean > finding an alternative gateway. This latter case is important in the > provision of high availability networks and cannot be solved by the peer > renegotiating when it comes back up. The peer might not actually be the > equipment at fault or it might be 'lost' permanently. > > Obviously not every network needs this so it's something that should be > configurable (and optional). Heartbeats should only be requested when > required and it should be possible for an implmentation to control the > quantity of heartbeats it generates and to which peers. > > I'd still like there to be the option of a phase 1 heartbeat which is only > sent in the absence of traffic on any connected phase 2 SAs. This will > cover a wide range of situations and means that no heartbeat traffic is > generated while the associated SAs are in active use. This would reduce the > benefit of the active SA listing and I think that should be optional too. > > Chris > > > -----Original Message----- > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > Sent: 29 March 2000 06:13 > > To: Jan Vilhuber > > Cc: Henry Spencer; IP Security List > > Subject: Re: Heartbeats draft (fwd) > > > > > > > If you look at the two proposals for solving the problem of > > syncing peers > > when one of them goes down (which I think is a fairly corner case): > > heartbeats/no heartbeats. > > > > Heartbeats solution is chatty, and it sucks up a lot of processing and > > bandwidth, but it doesn't have any DOS considerations. And the major > > disadvantage is that it is not very acceptable in dialer > > scenarios, which > > represent a major portion of our deployment base for IPSec. > > > > No heartbeats solution has some DOS considerations, that I > > feel are EASY > > to tackle. Advantages are it can be used in dial environments, and not > > bandwidth/processing intensive. > > > > So, I feel that we should tackle the DOS issues here, instead > > of imposing > > an un-ending DOS attack on ourselves by doing Heartbeats, > > once every 20 > > seconds (the recommended heartbeat interval) to all the peers > > in the world > > that we know of. This doesn't scale. I would rather prefer to > > tackle the > > DOS issues, and save processing and bandwidth for sending > > real traffic. > > > > > > > > Just because there's issues with cookies doesn't mean we > > should add yet > > > ANOTHER way that IKE can be taken down via DOS (bounded.. > > yes yes...). > > > > > > > For any protocol, bad implementations can be brought down, and that > > doesn't mean that it is a failure of the protocol. I guess it > > is pretty > > sraight forward to avoid any DOS vulnerablity in this case, and if the > > implementation chooses to be dumb about it, then I guess it is the > > implementation's problem, and not a protocol problem. > > > > > Also, we're not creating an, as you put it, 'chatty > > protocol', JUST to save > > > ourselves from DOS stuff. We're creating this protocol to > > do keepalives which > > > serve a useful purpose, besides DOS stuff. > > > > > > > The problem that the heartbeats are trying to solve, can be > > solved even > > without them. If you have any specific scenario where > > heartbeats are the > > only solution to the problem, please post it. > > > > -chinna > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed Mar 29 09:15:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02283; Wed, 29 Mar 2000 09:15:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05482 Wed, 29 Mar 2000 10:50:18 -0500 (EST) Date: Wed, 29 Mar 2000 10:55:04 -0500 Message-Id: <200003291555.KAA07434@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: pcn@cisco.com Cc: CTrobridge@baltimore.com, ipsec@lists.tislabs.com Subject: RE: Heartbeats draft (fwd) References: <1FD60AE4DB6CD2118C420008C74C27B854A09E@baltimore.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chinna, I would tend to agree with Chris. We have seen the sort of problems he mentioned in the real world. In addition, less likely to be a problem but still significant is the issue of self-stabilization. I know that not all protocols include this as an issue, but I have learned to treat it as a mandatory property. If you want to argue against the proposed mechanism, you might find it easier to convince people if you put forth an alternate proposal (with details of algorithms and protocols) that achieves the same ends with more efficiency. You mention, for example, that the SA database out of sync problem is easy to solve by other ways, but the approach you refer to in passing is one that has been considered before and found risky and/or unworkable. If you believe something has been overlooked, please fill in the details. paul From owner-ipsec@lists.tislabs.com Wed Mar 29 12:52:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06817; Wed, 29 Mar 2000 12:52:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06272 Wed, 29 Mar 2000 14:11:09 -0500 (EST) From: "Nir Selickter" To: "IPSEC" Subject: Reassembly and Fragmentation - detailed Question Date: Wed, 29 Mar 2000 21:18:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I would like to ask a question about reassembly and fragmentation. Maybe I am based on wrong assumption so please correct me if necessary. I am sorry that the email is long but I try to build some example with real values. A company with two remote site, build Intranet with two S.G implementing IPSec. These gateways are mounted at the edge of each site. Site A ------ S.G A ----------- Internet --------- S.G B ---------- Site B Now suppose, some host from Site A do "ping" with datagram size of 5000 bytes to some host in Site B. As I understand, Host A, will fragment the packet into 3 packets of 1500 and one packet of 500 bytes. ( Site A is Ethernet based ). 1500 + 1500 + 1500 + 500. Suppose that the Tunnel between S.G A and S.G B is AH and ESP (nested tunnel - bundle of SA ) in tunnel mode. If I assume that the Tunneling add 50- 100 bytes to the IP datagram ( 3DES, HMAC-MD5). Question: What actually will happen in S.G A : 1. Should the IP layer at S.G A reassembly al the 5000 bytes before it pass it up to AH and ESP processing ? 2. If 1 is true, Now the AH and ESP add 50- 100 bytes. Now we got datagram of ~5100 bytes. 3. If the Wan connection S.G A has MTU of 1000, should the IPSec fragment the packet before it pass it to the IP or should the IP fragment the packet ? ( 6 fragment 1000 + 1000 + 1000 +1000 + 1000 + 100 ? ) 4. Suppose that in the Internet the packets pass via some path with 512 MTU , hence the 1000 bytes packets cut again to 512 and 488 bytes. 5. Finally the packets reach S.G B and it should pass after processing to Host B. Can someone explain if the process that I describes is correct ? What happens at S.G B? Thanks in advance. Nir From owner-ipsec@lists.tislabs.com Wed Mar 29 13:03:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07036; Wed, 29 Mar 2000 13:03:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06498 Wed, 29 Mar 2000 14:58:32 -0500 (EST) From: "Bob Doud" To: "Angelos D. Keromytis" , "Skye Poier" Cc: Subject: RE: Open Source IPSec & accelerator cards Date: Wed, 29 Mar 2000 15:08:27 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200003290729.CAA21278@adk.gr> X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IRE has a crypto accelerator card (SafeNet Crypt/PCI) that's optimized for very high performance acceleration of IPsec transforms as well as IKE crypto computations. It uses the ADSP-2141 crypto chip and can provide 155 Mbps ESP (3-DES/SHA) throughput. We'd be happy to work with anyone out there that is adding hardware support to an IPsec implementation. Bob Doud IRE Secure Solutions, Inc. Voice: (978) 539-4812 mailto:bdoud@ire-ma.com http://www.ire.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Angelos D. Keromytis > Sent: Wednesday, March 29, 2000 2:29 AM > To: Skye Poier > Cc: ipsec@lists.tislabs.com > Subject: Re: Open Source IPSec & accelerator cards > > > > In message <20000328145657.H52760@ffwd.com>, Skye Poier writes: > >Hello, > > > >Can anyone give me a list of open source IPSec implementations that can > >utilize crypto acceleration cards? Namely: > > I recently added a crypto hardware framework in OpenBSD, and fix the IPsec > stack to take advantage of it (convert from linear processing to > callback-based). We have preliminary support for the hifn 7751 chip (which > is in fact used in a couple of different products), but it's not fully > debugged yet. Probably a couple of weeks away. > > We're trying to get docs for more crypto cards (and start supporting big-num > cards too) -- Intel and 3Com are not being very helpful in providing specs for > their new cards though... > -Angelos > > > > > From owner-ipsec@lists.tislabs.com Wed Mar 29 14:59:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08669; Wed, 29 Mar 2000 14:59:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07054 Wed, 29 Mar 2000 16:54:10 -0500 (EST) Message-ID: From: Claudio Lordello To: Nir Selickter , IPSEC Subject: RE: Reassembly and Fragmentation - detailed Question Date: Wed, 29 Mar 2000 16:59:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some answers below. Claudio Lordello. > > A company with two remote site, build Intranet with two S.G implementing > IPSec. > > These gateways are mounted at the edge of each site. > > Site A ------ S.G A ----------- Internet --------- S.G B ----------Site B > > Now suppose, some host from Site A do "ping" with datagram size of 5000 > bytes to some host in Site B. > > As I understand, Host A, will fragment the packet into 3 packets of 1500 and > one packet of 500 bytes. ( Site A is Ethernet based ). 1500 + 1500 + 1500 + > 500. > > Suppose that the Tunnel between S.G A and S.G B is AH and ESP (nested > tunnel - bundle of SA ) in tunnel mode. > > If I assume that the Tunneling add 50- 100 bytes to the IP datagram ( 3DES, > HMAC-MD5). > > Question: > > What actually will happen in S.G A : > > 1. Should the IP layer at S.G A reassembly al the 5000 bytes before it pass > it up to AH and ESP processing ? Typically this does not happen. Re-assembly is a task performed by the endpoint and not the router. > 2. If 1 is true, Now the AH and ESP add 50- 100 bytes. Now we got datagram > of ~5100 bytes. > 3. If the Wan connection S.G A has MTU of 1000, should the IPSec fragment > the packet before it pass it to the IP or should the IP fragment the packet? > ( 6 fragment 1000 + 1000 + 1000 +1000 + 1000 + 100 ? ) One approach is that when IPSec is attached to an IP interface it should present to the IP Interface a MTU "discounted" of the IPSec overhead. In your case, the IPSec stack would make the IP interface "think" that the MTU is 900 (assuming a maximum overhead of 100). Therefore, IP would then fragment the pieces BEFORE AH and ESP encapsulation. The packets presented for IPSec processing would then be: [900 + 600 + 900 + 600 + 900 + 600 + 500]. IPSec now processes those packets and assuming a fixed overhead of 100 the fragments now look like: [1000 + 700 + 1000 + 700 + 1000 + 700 + 600] > 4. Suppose that in the Internet the packets pass via some path with 512 MTU > , hence the 1000 bytes packets cut again to 512 and 488 bytes. There are some options regarding this. The one we use and I assume it is a popular one is to set the DF bit in all IPSec encapsulated packets and do path MTU discovery. This way if such encapsulated packet does find such 512 MTU router on its path the packet would be discarded but an ICMP message would be returned to SG A. SG A would now use the ICMP message info to reduce the IP interface's MTU to 412. Now on, no further packets would be discarded. Have a look at Path MTU discovery stuff. > 5. Finally the packets reach S.G B and it should pass after processing to > Host B. > > Can someone explain if the process that I describes is correct ? > What happens at S.G B? > > Thanks in advance. > > Nir Claudio Lordello. From owner-ipsec@lists.tislabs.com Wed Mar 29 15:04:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08764; Wed, 29 Mar 2000 15:04:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07034 Wed, 29 Mar 2000 16:48:04 -0500 (EST) Message-ID: <38E27B7F.6A78670E@mihy.mot.com> Date: Wed, 29 Mar 2000 15:54:07 -0600 From: rohit Organization: Motorola X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Nir Selickter CC: IPSEC Subject: Re: Reassembly and Fragmentation - detailed Question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Question: > > What actually will happen in S.G A : > > 1. Should the IP layer at S.G A reassembly al the 5000 bytes before it pass > it up to AH and ESP processing ? No It should not do that.. IPSEC Outbound processing shouldbe applied separately on each of the 1500 bytes packet. Here a lot depends on the selectors you use for selecting the Security Policy to apply. > 2. If 1 is true, Now the AH and ESP add 50- 100 bytes. Now we got datagram > of ~5100 bytes > 3. If the Wan connection S.G A has MTU of 1000, should the IPSec fragment > the packet before it pass it to the IP or should the IP fragment the packet > ? IP Layer can take care of fragmenting the packet.. > ( 6 fragment 1000 + 1000 + 1000 +1000 + 1000 + 100 ? ) > 4. Suppose that in the Internet the packets pass via some path with 512 MTU > , hence the 1000 bytes packets cut again to 512 and 488 bytes. > 5. Finally the packets reach S.G B and it should pass after processing to > Host B. IMHO, SG.B's inbound security processing can do one reassembly before doing the deauthentication and decrypting the inbound packet.. Hope it helps.. -Rohit -- Rohit V. Aradhya From owner-ipsec@lists.tislabs.com Wed Mar 29 15:20:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08928; Wed, 29 Mar 2000 15:20:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07116 Wed, 29 Mar 2000 17:12:19 -0500 (EST) Date: Wed, 29 Mar 2000 14:18:01 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Paul Koning cc: CTrobridge@baltimore.com, ipsec@lists.tislabs.com Subject: RE: Heartbeats draft (fwd) In-Reply-To: <200003291555.KAA07434@tonga.xedia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Why do we have to start with the premise that we definitely need Heartbeats? I think, everybody is aware of atleast one implementation that elegantly provides high availability, in the current framework of IKE and IPSec. So, I feel that high availability can be acheived in an efficient way if we do it in an implementation specific way. -chinna On Wed, 29 Mar 2000, Paul Koning wrote: > Chinna, > > I would tend to agree with Chris. We have seen the sort of problems > he mentioned in the real world. In addition, less likely to be a > problem but still significant is the issue of self-stabilization. I > know that not all protocols include this as an issue, but I have > learned to treat it as a mandatory property. > > If you want to argue against the proposed mechanism, you might find it > easier to convince people if you put forth an alternate proposal (with > details of algorithms and protocols) that achieves the same ends with > more efficiency. You mention, for example, that the SA database out > of sync problem is easy to solve by other ways, but the approach you > refer to in passing is one that has been considered before and found > risky and/or unworkable. If you believe something has been > overlooked, please fill in the details. > > paul > > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed Mar 29 15:33:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA09134; Wed, 29 Mar 2000 15:33:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07168 Wed, 29 Mar 2000 17:28:53 -0500 (EST) Date: Wed, 29 Mar 2000 14:34:46 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Andrew Krywaniuk cc: "'ipsec mailling list'" Subject: RE: Heartbeats draft (fwd) In-Reply-To: <000201bf997e$e1e714d0$06dba8c0@andrewktest.timestep.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 29 Mar 2000, Andrew Krywaniuk wrote: > Hi Chinna, > > > The number of quick mode SAs between two site to site > > security gateways can grow > > dramatically, and because the SPIs are completely randomly > > allocated, we have to > > essentially walk through all SPIs that we have with a > > particular peer, and then > > send the SPIs that are in a particular range. I don't see any > > real saving in > > processing here, although there is saving on the receiving > > side. And I don't see > > how we can cleanly comeup with ranges of SPIs that will > > actually divide the SPIs > > that we have with a peer as we intend to (or atleast > > reasonably equally), > > because SPIs are supposed to be completely random. > > If this is really a problem for you then I suggest you invest in some good > database software. Please also suggest databases from which vendor are the best for IPSec, for the benefit of the list. I don't think anyone has explored that yet. > > > > If we use > > acknowledged delete > > notifications, the we pretty much don't have to worry about > > any SAD sync issues, > > for most of the time. The only place we need to deal with > > them would be when a > > peer goes down. > > You don't have to use the SPI list if you don't want to; if you think > acknowledge delete notifications are sufficient then by all means use them > (the draft recommends it). > > Of course, acknowledged deletes don't work if the peer can't send them. For > example, the peer may periodically dangle the phase 2 SAs, in which case > there won't be a phase 1 available on which to send the delete. Alternately, > the link may have gone down temporarily, in which case the SADs may be out > of synch. > If you have dangling Phase2 SAs you cant do Heartbeats either! > > > Firstly heartbeats are not going to be 'cheap', atleast from > > our experience they > > are not cheap even without the equivalent of SPI lists. If > > you had a lot of > > peers, and if you use the recommended heartbeat interval of > > 20 seconds, then the > > box is sending/processing a considerable amount of heartbeat traffic. > > As has been pointed out before, the cost of heartbeats is O(n). This is a > theoretical minimum, and I maintain that any alternate scheme you might > propose will also be O(n). The cost for each peer is huge, and O(n) of some huge cost is not cheap. > Yes, if you have N times as many peers then you also have to send N times as > many heartbeats. But you are ignoring the fact that you will also have N > times as many SAs, which means N times as much traffic, which means that you > need an N times bigger box with N times as much CPU power. And this N times > bigger box is properly equipped to process N times as many heartbeat > packets. > > And BTW, as technology advances, users will demand more traffic per (phase > 1) SA. This will result in heartbeat traffic being an increasingly small > percentage of total traffic. > Please don't mix management traffic with real customer traffic. I think in most implementations we deal with management traffic and real traffic differently. Even if Heartbeats traffic may look small (one message per peer, per 20 seconds), we need to make the distinction that it is management traffic, and no real traffic. In client systems you many not have such distiction, but in bigger and bigger boxes, we are very very sensitive to these things. > > > Coming to DOS vulnerability, I am not advocating that we > > should try and > > negotiate SAs for invalid SPI errors all the time. We can > > "intellegently" > > initiate SAs only when we detect that we recently restarted, > > and limit the > > number of times we initiate to a particular peer. > > Which means that you will be extra vulnerable to DoS attacks right after we > restart, which is fine as long as it wasn't a DoS attack which caused you to > crash in the first place. > If a DOS attack caused you to crash, then I don't see how you are not going to crash again (even if didn't have to deal with the new DOS risk). > Also, I find it abhorent that an attacker would be able to force me to > initiate an SA with some arbitrary peer just by sending me an invalid spi > notify. Firslty, the proposal is to act on an invalid SPI error condition, and not responding to an Invalid SPI notification. We need scalability, and Heartbeats are not going to scale. > > Plus, you are ignoring all the other benefits you get from using heartbeats. What benefits? I cant use them in dialer environments anyway. -chinna > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed Mar 29 18:43:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16256; Wed, 29 Mar 2000 18:43:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA07818 Wed, 29 Mar 2000 20:10:08 -0500 (EST) Message-ID: <38E2A6F2.3ADD5BD0@redcreek.com> Date: Wed, 29 Mar 2000 14:59:30 -0800 From: Ricky Charlet X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ".ipsec" Subject: my presentation on heartbeats Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, Below is the text of the heartbeat presentation I made at the ipsec WG meeting. Is this the real problem? If so, is this the right way to rank cantidate solutions. -- Ricky Charlet rcharlet@redcreek.com usa 510-795-6903 =========================================== slide 1 Ricky Charlet Redcreek Communications rcharlet@redcreek.com ============================ slide 2. the problem black hole detection for redundancy/error messaging for resource recovery for time based accounting ============================== slide 3. problem reduction If you trust your own list of SPIs, then you only need to know about peer reachablility. o current authenticated conversation on any phase 1 or 2 SA proves peer is still there. o on a silent but good connection an authenticated hello exchange over any single phase 1 or 2 SA proves the peer is still there. =============================== slide 4. criteria o variable granularity to detect within seconds, or detect within minutes o scales to thousands of connections ie. does not take a lot of work o low cost to implement (simple) =============================== slide 5. score board o P2 conditional pings inband: - moderate scaling, high cost of implementation o P1 tell your peer to send hellos and keep sliding windows: - poor scaling, high cost of implementation (perhaps scaling properties are fixable) o P1 conditional send hellos - good scaling, low cost of implementation (new 'hello' notify packet, hello process) o P2 new transport SA to carry pings - poor scaling, low cost of implementation (ping process extra cost of config work) =================================== slide 6 Darts? Any challenges to my claims? ================================== From owner-ipsec@lists.tislabs.com Thu Mar 30 01:02:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06239; Thu, 30 Mar 2000 01:02:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA08883 Thu, 30 Mar 2000 02:29:47 -0500 (EST) Message-ID: <38E2FFF2.D15523E0@redcreek.com> Date: Wed, 29 Mar 2000 21:19:14 -0800 From: Ricky Charlet X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ".ipsec" Subject: Re: my presentation on heartbeats References: <38E2A6F2.3ADD5BD0@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, So I just realized that my 'slides' will be terribly vague to people who did not hear me speak at the WG meeting. So I will intersperse 'speakers notes' into the presentation. Ricky Charlet wrote: > > Howdy, > Below is the text of the heartbeat presentation I made at the ipsec > WG meeting. Is this the real problem? If so, is this the right way to > rank cantidate solutions. > > -- > Ricky Charlet rcharlet@redcreek.com usa 510-795-6903 > > =========================================== > slide 1 > Ricky Charlet > > Redcreek Communications > rcharlet@redcreek.com > > ============================ > slide 2. the problem > > black hole detection > for redundancy/error messaging > for resource recovery > for time based accounting Here I claim there is only one problem that we are trying to solve with heartbeats, 'black hole detection'. But we all have differing motivations for wanting black-hole-detection. These motivations are at least the three bullets above. If any one has more reasons for wanting to know about a black hole, then please provide feedback. If anyone thinks that our problem space is bigger than just black hole detection, then please provide feedback. Note that if your only motivation for black hole detection is resource recovery, that is, you don't care about time accounting or taking quick recovery actions, then your time granularity to dectection can be in minutes. Otherwise your time granularity to detection needs to be in seconds. For example, a gatway terminating many thousands of clients, may not care about contacting secondary clients if the primary is down. So a simple inactivity timeout at about 10~15 minutes without active heartbeats would suffice there. > > ============================== > slide 3. problem reduction > > If you trust your own list of SPIs, > then you only need to know about peer reachablility. > > o current authenticated conversation on any phase 1 or 2 SA proves > peer is still there. > > o on a silent but good connection an authenticated hello exchange over > any single phase 1 or 2 SA proves the peer is still there. Here I claim that we do not need black-hole-detection per SA, only per peer. Current traffic on any SA (P1 or P2) from a peer proves that peer is still reachable. And a hello exchange on any P1 or P2 SA proves the peer is still reachable. Although a large motivator for these heatbeat threads was to help solve SAD desychronozation, I claim that is not really in our problem space. IKE can be, and is being amended to improve the integrity of SAD sychronozation. > > =============================== > slide 4. criteria > > o variable granularity to detect within seconds, or detect within > minutes > > o scales to thousands of connections > ie. does not take a lot of work > > o low cost to implement (simple) Here, I hope to propose criteria to judge which solution to pick. If you caught the last bit of the last slide, you noticed there there are at least two ways to prove a peer is still reachable, through phase 1 and through phase 2. At least 4 propsals I have noticed on the list offer cantidate mechanisms to do heartbeats. On the next slide I scoreboard the proposals. Notice that my idea of using a ping inside of 'hijacked' P2 SAs, scores very low. bummer :-( > > =============================== > slide 5. score board > > o P2 conditional pings inband: > - moderate scaling, high cost of implementation > o P1 tell your peer to send hellos and keep sliding windows: > - poor scaling, high cost of implementation > (perhaps scaling properties are fixable) > o P1 conditional send hellos > - good scaling, low cost of implementation > (new 'hello' notify packet, hello process) > o P2 new transport SA to carry pings > - poor scaling, low cost of implementation > (ping process extra cost of config work) > > =================================== > slide 6 Darts? > > Any challenges to my claims? > > ================================== From owner-ipsec@lists.tislabs.com Thu Mar 30 03:16:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA15859; Thu, 30 Mar 2000 03:16:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA09550 Thu, 30 Mar 2000 05:00:56 -0500 (EST) Message-ID: <714BE32F82EED211B9CA0008C7C5A4DA0313D6E7@zuk28exm01.ecid.cig.mot.com> From: Shi Rong-rongshi1 To: IPSEC Subject: IPSEC related system performance issues Date: Thu, 30 Mar 2000 11:07:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, Does anyone know whether there is any work going on to study the overhead added by IPSec to IP? Is there any quantative figure to support this? Thanks, Rong Shi Motorola, GSM Applied Research From owner-ipsec@lists.tislabs.com Thu Mar 30 06:29:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19147; Thu, 30 Mar 2000 06:29:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10357 Thu, 30 Mar 2000 08:07:12 -0500 (EST) From: Mark Burkley To: ipsec@lists.tislabs.com Subject: Looking for performance data - SHA1 Date: Thu, 30 Mar 2000 14:11:52 +0100 Organization: Basis Communications Europe Reply-To: mburkley@basiscomm.ie Message-ID: X-Mailer: Forte Agent 1.7/32.534 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA10354 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm doing some research into implementing IPSec. One of the figures I need to find is clock cycles required per bit for the AH transforms. Specifically, I'm looking for performance data for software SHA1 implementations as (it seems to me) SHA1 is more demanding than MD5 and this would make a better "worst case" analysis. Anyone know where I could find any info on the SHA1 algorithm? TIA -- Mark Burkley mburkley@basiscomm.ie Basis Communications Europe +353 61 716026 From owner-ipsec@lists.tislabs.com Thu Mar 30 07:25:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20619; Thu, 30 Mar 2000 07:25:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10960 Thu, 30 Mar 2000 09:15:31 -0500 (EST) X-Authentication-Warning: keeks-gw.cyber.ee: helger owned process doing -bs Date: Thu, 30 Mar 2000 16:22:21 +0200 (EET) From: Helger Lipmaa X-Sender: helger@keeks To: Mark Burkley cc: ipsec@lists.tislabs.com Subject: Re: Looking for performance data - SHA1 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, 30 Mar 2000, Mark Burkley wrote: > Specifically, I'm looking for performance data for software SHA1 > implementations as (it seems to me) SHA1 is more demanding than MD5 > and this would make a better "worst case" analysis. > > Anyone know where I could find any info on the SHA1 algorithm? See http://www.esat.kuleuven.ac.be/~bosselae/fast.html for fast implementations on the Pentium (SHA-1: 837 cycles per block or 55.1 Mbit/sec on a 90 MHz Pentium) Or libsha from ftp://ftp.psy.uq.oz.au/pub/Crypto/libeay/ - this one isalso available as a source code and has also a Pentium Pro optimized version. Helger Lipmaa http://home.cyber.ee/helger From owner-ipsec@lists.tislabs.com Thu Mar 30 10:01:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23782; Thu, 30 Mar 2000 10:01:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11429 Thu, 30 Mar 2000 11:30:39 -0500 (EST) Date: Thu, 30 Mar 2000 11:36:30 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: Heartbeats draft (fwd) 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, 29 Mar 2000, CHINNA N.R. PELLACURU wrote: > I think, everybody is aware of atleast one implementation that elegantly > provides high availability, in the current framework of IKE and IPSec. So, > I feel that high availability can be acheived in an efficient way if we do > it in an implementation specific way. Uh, no, not everybody is aware of such an implementation. Please be more specific instead of vaguely alluding to it. Explanations of exactly how it is done would also be welcome. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Mar 30 13:20:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27462; Thu, 30 Mar 2000 13:20:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12103 Thu, 30 Mar 2000 14:53:24 -0500 (EST) Date: 30 Mar 2000 16:16:36 -0000 Message-ID: <20000330161636.8568.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipsec@lists.tislabs.com Subject: Re: Looking for performance data - SHA1 References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Helger Lipmaa writes: > 55.1 Mbit/sec on a 90 MHz Pentium Not for packets of realistic sizes. The same Pentium will need more than a second to authenticate 30000 64-byte messages. ---Dan From owner-ipsec@lists.tislabs.com Thu Mar 30 13:48:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27839; Thu, 30 Mar 2000 13:48:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA12348 Thu, 30 Mar 2000 15:43:23 -0500 (EST) Date: Thu, 30 Mar 2000 15:49:44 -0500 Message-Id: <200003302049.PAA17465@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djb@cr.yp.to Cc: ipsec@lists.tislabs.com Subject: Re: Looking for performance data - SHA1 References: <20000330161636.8568.qmail@cr.yp.to> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "D" == D J Bernstein writes: D> Helger Lipmaa writes: >> 55.1 Mbit/sec on a 90 MHz Pentium D> Not for packets of realistic sizes. The same Pentium will need D> more than a second to authenticate 30000 64-byte messages. It shouldn't be quite that bad, though it's close. Then again, 64 bytes is exactly the worst case, the hit is a factor of 3 (for HMAC). 64 bytes isn't a realistic average packet size, though. paul From owner-ipsec@lists.tislabs.com Thu Mar 30 15:25:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA29265; Thu, 30 Mar 2000 15:25:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13035 Thu, 30 Mar 2000 17:19:47 -0500 (EST) Message-Id: <200003302226.RAA12372@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Looking for performance data - SHA1 In-Reply-To: Your message of "30 Mar 2000 16:16:36 GMT." <20000330161636.8568.qmail@cr.yp.to> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Mar 2000 17:25:49 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "D" == D J Bernstein writes: D> Helger Lipmaa writes: >> 55.1 Mbit/sec on a 90 MHz Pentium D> Not for packets of realistic sizes. The same Pentium will need more D> than a second to authenticate 30000 64-byte messages. Considering how easy denial of service attacks are, I would want to be able to perform the authentication function at 110% of my line speed. If that means getting a *slower* internet connection, then I'd do that :-) :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Thu Mar 30 17:26:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA01091; Thu, 30 Mar 2000 17:26:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13316 Thu, 30 Mar 2000 19:21:05 -0500 (EST) Date: Thu, 30 Mar 2000 16:26:32 -0800 (PST) From: "CHINNA N.R. PELLACURU" To: Henry Spencer cc: IP Security List Subject: RE: Heartbeats draft (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What I am trying to point out is that, it is possible (efficient) to do it in an implementation specic way, within the framework of the current IKE/IPSec standards. Heartbeats is not the only solution to the problem, and heartbeats are not efficient. -chinna On Thu, 30 Mar 2000, Henry Spencer wrote: > On Wed, 29 Mar 2000, CHINNA N.R. PELLACURU wrote: > > I think, everybody is aware of atleast one implementation that elegantly > > provides high availability, in the current framework of IKE and IPSec. So, > > I feel that high availability can be acheived in an efficient way if we do > > it in an implementation specific way. > > Uh, no, not everybody is aware of such an implementation. Please be more > specific instead of vaguely alluding to it. Explanations of exactly how it > is done would also be welcome. > > Henry Spencer > henry@spsystems.net > > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Mar 30 18:51:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA04517; Thu, 30 Mar 2000 18:51:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA13625 Thu, 30 Mar 2000 20:51:54 -0500 (EST) From: Sheela Rowles Message-Id: <200003310157.RAA26908@sigma.cisco.com> Subject: WG Last call: draft-ietf-ipsec-isakmp-gss-auth-05.txt To: ddp@network-alchemy.com (Derrell Piper), briansw@microsoft.com (Brian Swander) Date: Thu, 30 Mar 2000 17:57:44 -0800 (PST) Cc: tytso@valinux.com (Theodore Tso), srowles@cisco.com (Sheela Rowles), ipsec@lists.tislabs.com (IPSec List) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derrell and Brian (Swander), My understanding is that the isakmp-gss draft is an informational draft, that basically documents one vendor's implementation (Microsoft). As it turns out, we are also implementing the draft (we = Cisco), and so wondered if this should be considered as a future RFC rather than an informational draft. Is there anyone else out there who plans to implement this? In any case, since this is an informational draft (documenting Microsoft's work in this area, the draft needs to be modified to reflect some differences between the draft and Microsoft's current implementation: 1. The draft currently mentions that exchanging an attribute in the first exchange 'may' be done, but as far as I can tell, there is no easy way to interoperate with MS unless this is done. It seems this should be a 'must'. 2. Currently MS has implemented this attribute as a wide character string, so the spec should specify that. My understanding is that MS will be adding the one-byte character strings but this is not true in the current WIN2K release. 3. Finally, the vendor ID doesn't match. MS currently has the vendorid implemented as "GSSAPI" while the spec has a different vendor id specified. thanks. Sheela From owner-ipsec@lists.tislabs.com Fri Mar 31 01:02:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA24489; Fri, 31 Mar 2000 01:02:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA14678 Fri, 31 Mar 2000 02:37:22 -0500 (EST) Message-ID: <38E457AA.C6C1F37E@mailer2.cefriel.it> Date: Fri, 31 Mar 2000 09:45:46 +0200 From: Elena Spreafico X-Mailer: Mozilla 4.71 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IPSec vs SSL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, who can explain me why some companies are trying to use IPSec end to end, for example client to server (and not gateway to gateway), instead of SSL? Some articles says that IPSec is more secure (why?). Are there other reasons? Thanks Elena From owner-ipsec@lists.tislabs.com Fri Mar 31 08:20:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18893; Fri, 31 Mar 2000 08:20:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15844 Fri, 31 Mar 2000 09:50:12 -0500 (EST) Message-Id: <01BF9B4C.67D07E00.venkatn@future.futsoft.com> From: Venkatesh N Reply-To: "venkatn@future.futsoft.com" To: "'ipsec@lists.tislabs.com'" Subject: Inbound packet processing- mobile host problem Date: Fri, 31 Mar 2000 20:05:03 +0530 Organization: Future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all I have the following doubts regarding the IPSEC (1) According to the RFC, for the inbound packets, the SA (tunnel mode) is retrieved based on the --The Destination IP address of the Outer IP header --SPI --IPsec protocol (a)Does this mean that the security gateway can allot the same SPI value for the different IP addresses (supposing It has more than one IP addresses)? (2) In the case of a mobile host contacting the home security gateway after dialing to a local PPP server on the Internet and then crossing the Internet to the home organization's firewall , then is there any automated way for the discovery/verification of the security gateway/mobile host?? Venkatesh From owner-ipsec@lists.tislabs.com Fri Mar 31 09:26:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19713; Fri, 31 Mar 2000 09:26:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16150 Fri, 31 Mar 2000 11:14:06 -0500 (EST) Message-Id: <3.0.5.32.20000331191823.03226d00@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 31 Mar 2000 19:18:23 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Inbound packet processing- mobile host problem In-Reply-To: <01BF9B4C.67D07E00.venkatn@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA16100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 20:05 31.3.2000 +0530, you wrote: >Hi all >I have the following doubts regarding the IPSEC > >(1) According to the RFC, for the inbound packets, the SA (tunnel mode) is retrieved based on the > > --The Destination IP address of the Outer IP header > --SPI > --IPsec protocol > > (a)Does this mean that the security gateway can allot the same SPI value for the different IP addresses (supposing It has > more than one IP addresses)? > Yes it can. I wouldn't implement it that way, though. It's easier that check whether the destination addr belongs to the GW at all and then do a (prot/SPI) lookup on incoming packets. >(2) In the case of a mobile host contacting the home security gateway after dialing to a local PPP >server on the Internet and then crossing the Internet to the home organization's firewall , then is there any automated way >for the discovery/verification of the security gateway/mobile host?? > I'm afraid that you have to rephrase that. A drawing (ASCII) would be nice as well. If you're asking how a FW and a SGW (two computers) can communicate (how does the FW know that packets were handled by the SGW), the usual way is to map the mobile users into a private network using NAT. > >Venkatesh > J–rn Sierwald From owner-ipsec@lists.tislabs.com Fri Mar 31 11:50:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA22093; Fri, 31 Mar 2000 11:50:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16612 Fri, 31 Mar 2000 13:31:24 -0500 (EST) Message-ID: <38E4FDC2.ADB3E177@certicom.com> Date: Fri, 31 Mar 2000 13:34:26 -0600 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IPSec vs SSL References: <8242F05CABD6E00B852568B3002DE29D.002DCEC3852568B3@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Elena, You can't say that IPSec is more secure than SSL. It depends on what crypto algorithms are really used in each case. If you use SSL, you'll get security at application level (a Web browser for instance). If you use IPSec, you'll get security at network level, in which case all your applications can be protected. I say "can", because you have to set proper security policy for your network traffic. You choose either IPSec or SSL based on your needs. Thanks, Yuri Poeluev Certicom Corp Elena Spreafico wrote: > Hi, > who can explain me why some companies are trying to use IPSec end to > end, for example client to server (and not gateway to gateway), instead > of SSL? Some articles says that IPSec is more secure (why?). Are there > other reasons? > Thanks > Elena From owner-ipsec@lists.tislabs.com Fri Mar 31 15:07:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24721; Fri, 31 Mar 2000 15:07:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17108 Fri, 31 Mar 2000 16:12:28 -0500 (EST) Message-Id: <200003312119.QAA03166@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: IPSec vs SSL In-Reply-To: Your message of "Fri, 31 Mar 2000 13:34:26 CST." <38E4FDC2.ADB3E177@certicom.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 31 Mar 2000 16:19:00 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Yuri" == Yuri Poeluev writes: Yuri> You can't say that IPSec is more secure than SSL. It depends on Yuri> what crypto algorithms are really used in each case. If you use Yuri> SSL, you'll get security at application level (a Web browser for Yuri> instance). If you use IPSec, you'll get security at network level, Yuri> in which case all your applications can be protected. I say "can", It has nothing to do with that. You can use, for instance, SSL or a GSSAPI enabled SOCKS-Winsock client and get "all your applications" protected. The difference between IPsec and something like SSL that runs over TCP is that SSL gets killed as soon as someone starts an active attack on the underlying TCP connection. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Fri Mar 31 16:24:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25522; Fri, 31 Mar 2000 16:24:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17426 Fri, 31 Mar 2000 18:12:40 -0500 (EST) Message-ID: <38E53FB2.8756EDCF@certicom.com> Date: Fri, 31 Mar 2000 18:15:46 -0600 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: IPSec vs SSL References: <13AC370967F6DF24852568B3007A987D.007A942F852568B3@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, What kind of "active attacks"? Please be specific. I agree that IPSec can prevent some attacks "on the underlying TCP connection". I was talking about crypto suites strength. Sorry, if I was misunderstood. By the way, IPSec can't possibly prevent activating a virus received over a secure IPSec channel, which can cause losing all data on your computer or system crash. :-) Another point - you might want to use SSL on VPN as well. So, you will have both at the same time. As I said, it depends on your needs. Are you suggesting to use IPSec instead SSL? Regards, Yuri Poeluev Certicom Corp. Michael Richardson wrote: > >>>>> "Yuri" == Yuri Poeluev writes: > Yuri> You can't say that IPSec is more secure than SSL. It depends on > Yuri> what crypto algorithms are really used in each case. If you use > Yuri> SSL, you'll get security at application level (a Web browser for > Yuri> instance). If you use IPSec, you'll get security at network > level, > Yuri> in which case all your applications can be protected. I say > "can", > > It has nothing to do with that. > You can use, for instance, SSL or a GSSAPI enabled SOCKS-Winsock client > and get "all your applications" protected. The difference between IPsec > and something like SSL that runs over TCP is that SSL gets killed as soon > as someone starts an active attack on the underlying TCP connection. > > :!mcr!: | Solidum Systems Corporation, > http://www.solidum.com > Michael Richardson |For a better connected world,where data flows > faster > Personal: > http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html > mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com