From owner-ipsec@lists.tislabs.com Tue Feb 1 02:54: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 CAA20735; Tue, 1 Feb 2000 02:54:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA01246 Tue, 1 Feb 2000 03:45:48 -0500 (EST) Date: Tue, 1 Feb 2000 00:49:46 -0800 Message-Id: <200002010849.AAA26330@homer.ka9q.ampr.org> From: Phil Karn To: msa@hemuli.tte.vtt.fi CC: sandy@storm.ca, ipsec@lists.tislabs.com In-reply-to: <200001201359.PAA18372@anise.tte.vtt.fi> (message from Markku Savela on Thu, 20 Jan 2000 15:59:17 +0200 (EET)) Subject: Re: Bruce Schneier on IPsec Reply-to: karn@qualcomm.com References: <200001201359.PAA18372@anise.tte.vtt.fi> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I don't understand what the big fuss is about two modes. In my >implementation the core IPSEC code implements only TRANSPORT MODE! The >tunnel mode is achieved simply by slapping IP tunnel on a packet and >THEN applying the transport mode transformation. Seems to work fine >and is very simple. Exactly. I could never figure it out either. I read the Counterpane paper, and I strongly agreed with almost everything they said. About the only exception was their proposal to do away with transport mode, which is exactly opposite of what should be done. As you say, tunnel mode should be eliminated in favor of standard tunneling techniques (IP in IP, GRE, etc) before the packet is handed to IPSec. Their complaints about the extreme complexity of IPSEC really resonated with me. I've watched the IPSec specifications grow seemingly without bound or discipline in the 8 years since I held the BoF in San Diego that led to the IPSec working group. Indeed, the most important thing that can be done to the IPSec specs now is to go at them with a meat cleaver, removing all the superflouous modes (e.g., AH) and whittling the remainder down to something that is both implementable and analyzable from a security point of view. Phil From owner-ipsec@lists.tislabs.com Tue Feb 1 03:12: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 DAA22004; Tue, 1 Feb 2000 03:12:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA01385 Tue, 1 Feb 2000 04:28:42 -0500 (EST) Date: Tue, 1 Feb 2000 01:33:39 -0800 Message-Id: <200002010933.BAA26358@homer.ka9q.ampr.org> From: Phil Karn To: pkoning@xedia.com CC: HORMAN@novell.com, ipsec@lists.tislabs.com In-reply-to: <200001201431.JAA04992@tonga.xedia.com> (message from Paul Koning on Thu, 20 Jan 2000 09:31:16 -0500) Subject: Re: Bruce Schneier on IPsec Reply-to: karn@qualcomm.com References: <200001201431.JAA04992@tonga.xedia.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >While I sympathize with Bruce and Niels's dissatisfaction with the >committee based process, I see no particular advantage in discussing >that. For better or worse, that's the IETF process. If enough people That's not true at all. I can point to several IETF standardization efforts that produced much better results much more quickly than the IPSec group. The key to success was that these groups knew ahead of time what they wanted to accomplish, and already had reference implementations with some actual use. So the WG only had to bless the work that already existed, perhaps with some minor changes. Bruce and Niel are exactly right -- the IPSec group was a committee out of control, trying to satisfy everyone at the same time. Phil From owner-ipsec@lists.tislabs.com Tue Feb 1 06:41: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 GAA28916; Tue, 1 Feb 2000 06:41:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA01833 Tue, 1 Feb 2000 07:36:18 -0500 (EST) Message-Id: <200002011241.MAA19451@orchard.arlington.ma.us> To: karn@qualcomm.com cc: msa@hemuli.tte.vtt.fi, sandy@storm.ca, ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec In-Reply-To: Message from Phil Karn of "Tue, 01 Feb 2000 00:49:46 PST." <200002010849.AAA26330@homer.ka9q.ampr.org> Date: Tue, 01 Feb 2000 07:41:08 -0500 From: Bill Sommerfeld Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I read the Counterpane paper, and I strongly agreed with almost > everything they said. About the only exception was their proposal to > do away with transport mode, which is exactly opposite of what should > be done. As you say, tunnel mode should be eliminated in favor of > standard tunneling techniques (IP in IP, GRE, etc) before the packet > is handed to IPSec. I agree and disagree here. >From the protocol/over-the-wire standpoint, this is exactly right. However, from the POV of packet filtering/policy checking, tunnel mode and transport mode require very different sorts of policy checks on the addresses in the outer and inner ip headers. Now, if all of your interfaces (including your tunnels) are set up with appropriate inbound filters, this isn't a big deal, but traditionally, that sort of filtering is not part of an IP stack. Always having the inner ip header (making the outer ip header irrelevant) would allow the check to always be done as part of ipsec rather than over in some other part of the system. - Bill From owner-ipsec@lists.tislabs.com Tue Feb 1 10:38: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 KAA09424; Tue, 1 Feb 2000 10:38:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02417 Tue, 1 Feb 2000 10:29:36 -0500 (EST) Message-Id: <200002011534.KAA01770@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec In-Reply-To: Your message of "Tue, 01 Feb 2000 00:49:46 PST." <200002010849.AAA26330@homer.ka9q.ampr.org> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 01 Feb 2000 10:34:38 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Phil" == Phil Karn writes: >> I don't understand what the big fuss is about two modes. In my >> implementation the core IPSEC code implements only TRANSPORT MODE! The >> tunnel mode is achieved simply by slapping IP tunnel on a packet and >> THEN applying the transport mode transformation. Seems to work fine >> and is very simple. Phil> Exactly. I could never figure it out either. Phil> I read the Counterpane paper, and I strongly agreed with almost Phil> everything they said. About the only exception was their proposal Phil> to do away with transport mode, which is exactly opposite of what Phil> should be done. As you say, tunnel mode should be eliminated in Phil> favor of standard tunneling techniques (IP in IP, GRE, etc) before Phil> the packet is handed to IPSec. I must agree strongly. However, the definitions of the various tunnel techniques do not have security in mind. Tunnel entry and exit conditions are important. Phil> Their complaints about the extreme complexity of IPSEC really Phil> resonated with me. I've watched the IPSec specifications grow Phil> seemingly without bound or discipline in the 8 years since I held Frankly, one reason is that doing everything right is complicated. I tend to favour specifying the minimum, and then letting people like l0pht.com determine which vendors understood the problem and which vendors implemented literally only what the spec said they had to. Others felt that unless the spec said "do X" there was very little chance that they'd ever see a product that "did X" Phil> the BoF in San Diego that led to the IPSec working group. Indeed, Phil> the most important thing that can be done to the IPSec specs now is Phil> to go at them with a meat cleaver, removing all the superflouous You are probably right. I think this should be done in the form of BCPs. There are a number of things that we built in that just aren't needed *today*. But I think we will find that people use them as soon as the products start shipping with IPsec standard. The export regulations relaxation, and projects like FreeS/WAN and KAME will get IPsec into people's basements, and those people will start discovering which features are frequently used, and which turn out to be a loss. :!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 Feb 1 11:38: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 LAA12460; Tue, 1 Feb 2000 11:38:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03047 Tue, 1 Feb 2000 13:00:54 -0500 (EST) Date: Tue, 1 Feb 2000 10:05:23 -0800 Message-Id: <200002011805.KAA27122@homer.ka9q.ampr.org> From: Phil Karn To: sommerfeld@orchard.arlington.ma.us CC: msa@hemuli.tte.vtt.fi, sandy@storm.ca, ipsec@lists.tislabs.com In-reply-to: <200002011241.MAA19451@orchard.arlington.ma.us> (message from Bill Sommerfeld on Tue, 01 Feb 2000 07:41:08 -0500) Subject: Re: Bruce Schneier on IPsec Reply-to: karn@qualcomm.com References: <200002011241.MAA19451@orchard.arlington.ma.us> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Always having the inner ip header (making the outer ip header >irrelevant) would allow the check to always be done as part of ipsec >rather than over in some other part of the system. But these features are already being implemented in firewall and policy routing modules (e.g., the policy routing stuff in Linux 2.2). Why reinvent the wheel? Phil From owner-ipsec@lists.tislabs.com Tue Feb 1 11:38: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 LAA12471; Tue, 1 Feb 2000 11:38:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02951 Tue, 1 Feb 2000 12:46:40 -0500 (EST) Date: Tue, 1 Feb 2000 12:50:47 -0500 (EST) From: Henry Spencer To: Bill Sommerfeld cc: karn@qualcomm.com, msa@hemuli.tte.vtt.fi, sandy@storm.ca, ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec In-Reply-To: <200002011241.MAA19451@orchard.arlington.ma.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 1 Feb 2000, Bill Sommerfeld wrote: > [is tunnel mode superfluous?] > Now, if all of your interfaces (including your tunnels) are set up > with appropriate inbound filters, this isn't a big deal, but > traditionally, that sort of filtering is not part of an IP stack. It may not be traditional, but it is increasingly common in the real world. And the sysadmins are not going to want to deal with two separate filtering mechanisms, one inside IPSec and one for everything else. > Always having the inner ip header (making the outer ip header > irrelevant) would allow the check to always be done as part of ipsec > rather than over in some other part of the system. And this is important why? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Feb 1 11:52: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 LAA13332; Tue, 1 Feb 2000 11:51:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03213 Tue, 1 Feb 2000 13:34:59 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF0113B924@exchange> From: Andrew Krywaniuk To: ipsec@lists.tislabs.com Subject: RE: issues raised at VPN interoperability workshop Date: Tue, 1 Feb 2000 13:41:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Will. > > I don't think this is a fair assumption. If I am not expecting a > > NOTIFY_CONNECTED then I will most likely delete my quick > mode object soon > > after sending QM3. (I will keep it around for a little > while in case I need > > to retransmit.) This creates a race conditions: If your spurious > > NOTIFY_CONNECTED arrives after I have deleted my quick mode > object then I > > will not know what to do with it. (In fact, I will most > likely think that it > > is a malformed QM1.) > > If your implementation receives a spurious connect-notify > will it affect > (i.e. delete) the previously negotiated P2 SA? I hope it won't. No. I think we just send Payload Malformed (and only if you send it after we have stopped waiting for retransmits). > If we can all agree that an implementation MUST reflect the CB if they > intend to honor it otherwise they should not reflect the CB > then I would > not send the C-N as a responder if the initiator did not reflect it. Since my box is only ever a commit bit responder, I don't really care whether an implementation is allowed to turn the commit bit off, SO LONG AS IT IS STANDARDIZED. I thought Dan's explanation at the town hall meeting was that clearing the commit bit in QM3 did not abdicate the responder from sending the C-N. >From Dan's Town Hall Summary: > * Can you clear the commit bit during phase 2? > > Yes. > > * Is the commit bit even mandatory? If it's not and you > don't support it > what do you do if it's set in an offer? Refuse it? > > It's mandatory. In other words, you can clear the commit bit, but you can't refuse the offer. > > 2. The initiator was the one who decided to initiate the > SA. Therefore, one > > can conclude that he will also be the first one to use it. > > I'm not sure this is true. Let's say Host A initiates the 1st QM > negotiation for a IPSec tunnel between Host A and Host B then Host B > initiates the next QM negotiation that will refresh the P2 SA > for the IPSec > tunnel between them because Host B's P2 SA lifetime was > shorter than Host > A's. Which host will be the first to use the new P2 SA? My quote above was actually an attempt to explain why it is not necessary for the initiator to send a C-N. You have already agreed with me on this subject. But since you brought up rekeying, "draft-jenkins-ipsec-rekeying" explains quite explicitly how you can avoid the lost packets problem by continuing to use the old SA for a brief period before switching to the new one. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Tue Feb 1 14:18: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 OAA21861; Tue, 1 Feb 2000 14:18:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03756 Tue, 1 Feb 2000 15:56:39 -0500 (EST) Date: Tue, 1 Feb 2000 15:01:39 -0600 From: Will Fiveash To: ipsec@lists.tislabs.com Subject: Re: issues raised at VPN interoperability workshop Message-ID: <20000201150138.A64112@austin.ibm.com> Mail-Followup-To: ipsec@lists.tislabs.com References: <319A1C5F94C8D11192DE00805FBBADDF0113B924@exchange> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF0113B924@exchange>; from akrywaniuk@TimeStep.com on Tue, Feb 01, 2000 at 01:41:58PM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Feb 01, 2000 at 01:41:58PM -0500, Andrew Krywaniuk wrote: > Since my box is only ever a commit bit responder, I don't really care > whether an implementation is allowed to turn the commit bit off, SO LONG AS > IT IS STANDARDIZED. I thought Dan's explanation at the town hall meeting was > that clearing the commit bit in QM3 did not abdicate the responder from > sending the C-N. I agree with your statement concerning standardization. More comments follow below. > >From Dan's Town Hall Summary: > > > * Can you clear the commit bit during phase 2? > > > > Yes. > > > > * Is the commit bit even mandatory? If it's not and you > > don't support it > > what do you do if it's set in an offer? Refuse it? > > > > It's mandatory. > > In other words, you can clear the commit bit, but you can't refuse the > offer. Dan, can we change the draft-ieft-ipsec-ike-01.txt so that we get a standardized way of interpreting the reflection or non-reflection of the CB? I think this will give impementors reasonable flexibility in that if they do not want to implement CB they just have to make sure they don't reflect the CB. If they do support CB then they have to check for reflection which is easy. -- Will Fiveash From owner-ipsec@lists.tislabs.com Tue Feb 1 14:22: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 OAA22084; Tue, 1 Feb 2000 14:22:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03704 Tue, 1 Feb 2000 15:50:19 -0500 (EST) Message-Id: <4.2.0.58.20000201093303.00d1dcb0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 01 Feb 2000 09:52:41 -0500 To: Bill Sommerfeld , karn@qualcomm.com From: Robert Moskowitz Subject: Re: Bruce Schneier on IPsec Cc: msa@hemuli.tte.vtt.fi, sandy@storm.ca, ipsec@lists.tislabs.com In-Reply-To: <200002011241.MAA19451@orchard.arlington.ma.us> References: <200002010849.AAA26330@homer.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 07:41 AM 2/1/2000 -0500, Bill Sommerfeld wrote: At this point I will not same too much about Schneier's paper. We talked a bit at RSA and I am working on my official response (and not in any official IETF position; remember I stepped down as co-chair). However, what I saw over time was a requirements creep, or rather a combination of a number of separate requirements, all munged into one (actually two, IPsec, and IKE) protocol. The workgroup effectively killed off AH for IPv4 at the Danvers IETF, but it took a while to admit that and develop a NULL encrypt mode for ESP. The ONLY arguements for AH in v4 space were political/administrative. I will drop this line of reason at this point before I dig a fight line :) ESP tried to meet to separate requirements: gateway needs and end ssytem needs and evolved tunnel and transport modes. Steve Kent and others did a fantastic job balancing these two power poles. The vendors concentrated on gateways and tunnle mode; lots of reasons for this. I now view this as a tactical move to get initial IPsec deployment, but not what the Net needs. End to end IPsec needs to be the strategic goal and the total hygenics around such a goal needs review. IMNSHO, IPsec end to end means: ESP transport mode, A KMP with fewer policy knobs and simpler rekeying at least, and distributed control (for organizations) of security. > > I read the Counterpane paper, and I strongly agreed with almost > > everything they said. About the only exception was their proposal to > > do away with transport mode, which is exactly opposite of what should > > be done. As you say, tunnel mode should be eliminated in favor of > > standard tunneling techniques (IP in IP, GRE, etc) before the packet > > is handed to IPSec. > >I agree and disagree here. > > From the protocol/over-the-wire standpoint, this is exactly right. > >However, from the POV of packet filtering/policy checking, tunnel mode >and transport mode require very different sorts of policy checks on >the addresses in the outer and inner ip headers. > >Now, if all of your interfaces (including your tunnels) are set up >with appropriate inbound filters, this isn't a big deal, but >traditionally, that sort of filtering is not part of an IP stack. >Always having the inner ip header (making the outer ip header >irrelevant) would allow the check to always be done as part of ipsec >rather than over in some other part of the system. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Tue Feb 1 17:17: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 RAA05167; Tue, 1 Feb 2000 17:17:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04399 Tue, 1 Feb 2000 18:55:06 -0500 (EST) Message-ID: <392A357CE6FFD111AC3E00A0C99848B001F04172@hdsmsx31.hd.intel.com> From: "Georgescu, Cristina" To: ipsec@lists.tislabs.com Subject: Notifications for failure in Config mode Date: Tue, 1 Feb 2000 16:00:03 -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 Does anyone know how notifications are used for Config mode? For example, if a system receive a failure notification for a Transaction Exchange in progress, what it will be into the SPI? A notification usualy has the SPI that will match the phase 2 SPI for a phase 2 or the 2 cookies for a phase 1. What is used for identification for config mode? From owner-ipsec@lists.tislabs.com Tue Feb 1 18:15: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 SAA08944; Tue, 1 Feb 2000 18:15:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04553 Tue, 1 Feb 2000 19:58:41 -0500 (EST) Date: Tue, 1 Feb 2000 17:03:40 -0800 Message-Id: <200002020103.RAA29790@homer.ka9q.ampr.org> From: Phil Karn To: rgm-sec@htt-consult.com CC: ipsec@lists.tislabs.com In-reply-to: <4.2.0.58.20000201093303.00d1dcb0@homebase.htt-consult.com> (message from Robert Moskowitz on Tue, 01 Feb 2000 09:52:41 -0500) Subject: Re: Bruce Schneier on IPsec Reply-to: karn@qualcomm.com References: <200002010849.AAA26330@homer.ka9q.ampr.org> <4.2.0.58.20000201093303.00d1dcb0@homebase.htt-consult.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >it took a while to admit that and develop a NULL encrypt mode for ESP. The >ONLY arguements for AH in v4 space were political/administrative. I will >drop this line of reason at this point before I dig a fight line :) I point out that those political/administrative arguments were made largely obsolete two weeks ago when the US crypto export rules were finally relaxed. As I understand it, US export controls were the primary motivation both for AH (or an authentication-only ESP) and for single-key DES. Phil From owner-ipsec@lists.tislabs.com Tue Feb 1 19:15: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 TAA13835; Tue, 1 Feb 2000 19:15:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA04754 Tue, 1 Feb 2000 21:07:58 -0500 (EST) Message-Id: <10002020214.AA03045@Ichiko.imailab.iis.u-tokyo.ac.jp> From: Kanta Matsuura Date: Wed, 02 Feb 2000 11:14:31 +0900 To: "Michael H. Warfield" Cc: Ari Huttunen , Michael Richardson , ipsec@lists.tislabs.com, "Mr. Anderson" Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing In-Reply-To: <20000131105240.B9337@alcove.wittsend.com> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I also think IKE should be more DoS resistant. At least, we have three problems: (1) Cookie-related state (2) other state (3) computational load (as heavy as modular exponentiation). Regarding statelessness, Pekka's idea is excellent and referred in http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt with a corrected use of ISAKMP Cookies. The draft also presents how to save computational power against DoS. This works better if combined with the stateless connection as described in the draft. Any comments welcome. Unfortunately I couldn't be at the coming IETF meeting. I do not mind anyone else's introducing my draft into the discussion in IKE modification. Thanks, "Michael H. Warfield" wrote: >>On Mon, Jan 31, 2000 at 08:09:05AM +0200, Ari Huttunen wrote: >>> "Michael H. Warfield" wrote: >> >>> > On Sun, Jan 30, 2000 at 06:30:57PM -0500, Michael Richardson wrote: >> >>> > > Switching to TCP does nothing. If you naively implement ISAKMP on top >>> > > of TCP, then you must include TCP SYN spoof protection, which is much more >>> > > difficult to deploy and hard to provide different levels of protection for, >>> > > say, HTTP servers vs ISAKMP daemons. >> >>> > I believe the arguement was that the problem with creating state >>> > due to spoofed packets could have been avoided. It has nothing to do with >>> > tcp vs udp. I'm not at the bottom of it yet, but it appears that some >>> > bad choices may have been made and some issues were not been given the >>> > serious consideration they deserved. >> >>> The problem of creating state, or 'cookie crumbs' can be successfully avoided >>> in at least some of the cases. The basic idea is for the entity that normally >>> would hold the state to encapsulate the state in a "state payload", and send >>> that back to to the other entity. The "state payload" would be unforgeable by >>> the peer, because it has been signed by the entity that created it (using >>> private key crypto.) When the next protocol message is to be processed, the >>> entity uses the state in the "state payload" and the other fields contained >>> in the message to process the message. Only the information needed to verify >>> the signing on the "state payload" needs to be retained, and that can be shared >>> with all the connections. >> >> This is good... We have a working DoS exploit, so now we need >>a way to address the problem. This should be incorporated into the >>standard, since there are vulnerable implimentations being fielded right >>now. If we can avoid this one, lets do it and get it out of the way. >> >> The things that disturb me are "can be successfully avoided in >>at least some of the cases". If it could have been avoided it should have >>been and I wonder why it wasn't in the first place. If you say "at least >>in some of the cases", does that mean that there are some cases where it >>can not be avoided. If so, then we haven't eliminated the problem, we've >>merely made it more difficult to exploit. I'm not totally sure that's much >>of a gain. >> >>> The idea is from the paper: >>> Tuomas Aura and Pekka Nikander, "Stateless connections", in proceedings of >>> International Conference on Information and Communications Security >>> ICICS'97, Beijing, November 1997, pp. 87-97, Lecture Notes in Computer Science 1334, >>> Springer Verlag 1997. >>> http://www.tcm.hut.fi/~pnr/publications/index.html >> >>> This "state payload" is about the same idea that I've written about in >>> my previous postings about the DoS attack, but at that time I didn't use >>> the same terminology or encapsulate the information in one place. >> >>> The "state payload" can be used by only some of the entities in the >>> Internet if we give it the following rule: >>> - If a "state payload" is received in message N by entity A, entity >>> A must include the "state payload" in message N+1 sent by entity A, >>> without any modifications to its contents. >>> This puts all of the responsibility for the security properties of >>> the "state payload" to the entity that uses it. (And ultimately to >>> IETF to specify safe usages for it.) >> >>> If there's interest for the "state payload", I can write it in the >>> form of a draft. >> >> I would personally say so... I would like to see if this could >>be implemented and effectively nullify this attack. ---- **** ---- Kanta MATSUURA, Ph.D. Lecturer 3rd Department, Institute of Industrial Science, University of Tokyo, Roppongi 7-22-1, Minato-ku, Tokyo 106-8558, JAPAN Tel: +81-3-3402-6231 (ext. 2325) Fax: +81-3-3479-1736 E-Mail: kanta@iis.u-tokyo.ac.jp From owner-ipsec@lists.tislabs.com Tue Feb 1 19:23: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 TAA14390; Tue, 1 Feb 2000 19:23:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA04769 Tue, 1 Feb 2000 21:10:55 -0500 (EST) Date: Tue, 1 Feb 2000 18:15:30 -0800 Message-Id: <200002020215.SAA29853@homer.ka9q.ampr.org> From: Phil Karn To: mcr@solidum.com CC: ipsec@lists.tislabs.com In-reply-to: <200002011534.KAA01770@solidum.com> (message from Michael Richardson on Tue, 01 Feb 2000 10:34:38 -0500) Subject: Re: Bruce Schneier on IPsec Reply-to: karn@qualcomm.com References: <200002011534.KAA01770@solidum.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > You are probably right. I think this should be done in the form of BCPs. This is starting to sound an awful lot like OSI "profiles", does it not? Phil From owner-ipsec@lists.tislabs.com Wed Feb 2 07:37: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 HAA14506; Wed, 2 Feb 2000 07:37:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06966 Wed, 2 Feb 2000 09:00:29 -0500 (EST) Message-ID: <389709CA.8125AD94@americasm01.nt.com> Date: Tue, 01 Feb 2000 11:28:58 -0500 From: "Kim Edwards" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: "ipsec@lists.tislabs.com" Subject: Racing IKE SAs Revisited Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk context.... two peers simultaneously attempt to negotiate an IKE SA with each other After perusing the archives, it seems that implementations are supporting the simultaneous negotiation of 2 IKE SAs. Assume that PFS is not required and the two IKE SAs were successfully negotiated. Do we still keep both IKE SAs around until they expire? If so, can one peer use both IKE SAs to negotiate two different IPsec SAs? -- Kim Edwards ILS Software Engineer, Nortel Networks (613)765-8551 From owner-ipsec@lists.tislabs.com Wed Feb 2 07:37: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 HAA14513; Wed, 2 Feb 2000 07:37:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06972 Wed, 2 Feb 2000 09:01:29 -0500 (EST) Message-ID: <3896CB80.A5AB8161@F-Secure.com> Date: Tue, 01 Feb 2000 14:03: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: Andrew Krywaniuk CC: Joern Sierwald , ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <319A1C5F94C8D11192DE00805FBBADDF0113B6AC@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew Krywaniuk wrote: > > Joern: > > Question is, why wasn't this build into ISAKMP? The normal ISAKMP > cookies could have been exchanged before sending the SA payload. > Would have taken an extra round-trip, of course. > > Andrew: > > I don't know. Maybe we need to go back and scavenge a few ideas from > Photuris. Although Photuris does seem to be vulnerable to modular > exponentiation attacks (which is typical of identity protection exchanges), > the cookie request exchange is similar to what you proposed. One reason I formed the concept of "state payload" is that with it a responder could protect itself from some DoS attacks with minimal changes to ISAKMP. It does not protect from all attacks. It can consume a significant amount of space, making ISAKMP packets in UDP cumbersome. If the contents of the state payload are specified incorrectly, security could be broken. However, it does not even have to be used unless necessary. And implementations that don't want it, need only understand enough to send it back in the next message. > Ari's comment about using public-key crypto to sign the info seems like > overkill. Cookies can be encrypted based on local secret info using a fast > algorithm. (Why sacrifice CPU consumption to save memory consumption?) I didn't state public-key crypto.. read again. > In Photuris, the responder generates the SA proposal list. Therefore, he > does not need to keep a state (since the proposal list is presumably static > or, at the very least, easy to regenerate from policy). Sounds like this leaks security information from responder.. My point being that I'd rather not start respecifying the whole protocol again. Only when necessary should there be changes, but IF necessary, the changes should be done. -- 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 Wed Feb 2 07:37: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 HAA14535; Wed, 2 Feb 2000 07:37:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06959 Wed, 2 Feb 2000 08:59:29 -0500 (EST) Message-ID: <3897836A.CAFEB4D3@redcreek.com> Date: Tue, 01 Feb 2000 17:07:54 -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: ipsec@lists.tislabs.com CC: "Pereira, Roy" , "Bitan, Sara" Subject: Re: Notifications for failure in Config mode References: <392A357CE6FFD111AC3E00A0C99848B001F04172@hdsmsx31.hd.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is not so much in reply to this particular post as it is for all config/xauth messages that have been on this list since the bakeoff. First, I think that discussion on these topics rightly belongs on the ipsra list (ietf-ipsra@vpnc.org). Second, I believe that the general consensus at the ipsra bof at the Washington IETF was that modifying IKE to provide these functionalities is probably undesireable, and that alternative mechanisms should be fully considered and probably given preference. However, I have seen no effort on the part of the (proposed) chairs for that working group to moderate this discussion in that light, and in fact, have noted that Roy seems to be encouraging the continued movement down this path. I suggest that we move this discussion to ipsra, and that we get down to the work of actually solving this problem, rather than simply waiting (hoping?) for these mechanisms to proliferate beyond the point of no return. Scott From owner-ipsec@lists.tislabs.com Wed Feb 2 08:13: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 IAA16093; Wed, 2 Feb 2000 08:13:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08501 Wed, 2 Feb 2000 09:51:44 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B788F2A@md-exchange1.nai.com> From: "Mason, David" To: "'Kanta Matsuura'" , "Michael H. Warfield" Cc: Ari Huttunen , Michael Richardson , ipsec@lists.tislabs.com, "Mr. Anderson" Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Date: Wed, 2 Feb 2000 06:52:50 -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 Another simple approach could be to introduce two new payloads: REFLECT REFLECTION When you receive a REFLECT payload you must send a REFLECTION payload back in your next message that contains the exact contents of the REFLECT payload that you received. For example the first three payloads of Signature/Preshared Key Main Mode (just say no to Aggressive Mode :) would look something like this: HDR, SA [, VIDi] --> <-- HDR, SA, REFLECT [, VIDr] HDR, KE, Ni, REFLECTION The responder would send what ever state information it deemed necessary in the REFLECT payload which might take the format of the following: timestamp Initiators SA and VID Responders SA Other implementation dependent stuff Padding Hash And this could be encrypted with a key (randomly generated upon each reboot) the responder uses to encrypt it's REFLECT (decrypt REFLECTION) payloads using the responder's cookie as an IV. -dave -----Original Message----- From: Kanta Matsuura [mailto:kanta@hideki.iis.u-tokyo.ac.jp] Sent: Tuesday, February 01, 2000 9:15 PM To: Michael H. Warfield Cc: Ari Huttunen; Michael Richardson; ipsec@lists.tislabs.com; Mr. Anderson Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Hi, I also think IKE should be more DoS resistant. At least, we have three problems: (1) Cookie-related state (2) other state (3) computational load (as heavy as modular exponentiation). Regarding statelessness, Pekka's idea is excellent and referred in http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt with a corrected use of ISAKMP Cookies. The draft also presents how to save computational power against DoS. This works better if combined with the stateless connection as described in the draft. Any comments welcome. Unfortunately I couldn't be at the coming IETF meeting. I do not mind anyone else's introducing my draft into the discussion in IKE modification. Thanks, "Michael H. Warfield" wrote: >>On Mon, Jan 31, 2000 at 08:09:05AM +0200, Ari Huttunen wrote: >>> "Michael H. Warfield" wrote: >> >>> > On Sun, Jan 30, 2000 at 06:30:57PM -0500, Michael Richardson wrote: >> >>> > > Switching to TCP does nothing. If you naively implement ISAKMP on top >>> > > of TCP, then you must include TCP SYN spoof protection, which is much more >>> > > difficult to deploy and hard to provide different levels of protection for, >>> > > say, HTTP servers vs ISAKMP daemons. >> >>> > I believe the arguement was that the problem with creating state >>> > due to spoofed packets could have been avoided. It has nothing to do with >>> > tcp vs udp. I'm not at the bottom of it yet, but it appears that some >>> > bad choices may have been made and some issues were not been given the >>> > serious consideration they deserved. >> >>> The problem of creating state, or 'cookie crumbs' can be successfully avoided >>> in at least some of the cases. The basic idea is for the entity that normally >>> would hold the state to encapsulate the state in a "state payload", and send >>> that back to to the other entity. The "state payload" would be unforgeable by >>> the peer, because it has been signed by the entity that created it (using >>> private key crypto.) When the next protocol message is to be processed, the >>> entity uses the state in the "state payload" and the other fields contained >>> in the message to process the message. Only the information needed to verify >>> the signing on the "state payload" needs to be retained, and that can be shared >>> with all the connections. >> >> This is good... We have a working DoS exploit, so now we need >>a way to address the problem. This should be incorporated into the >>standard, since there are vulnerable implimentations being fielded right >>now. If we can avoid this one, lets do it and get it out of the way. >> >> The things that disturb me are "can be successfully avoided in >>at least some of the cases". If it could have been avoided it should have >>been and I wonder why it wasn't in the first place. If you say "at least >>in some of the cases", does that mean that there are some cases where it >>can not be avoided. If so, then we haven't eliminated the problem, we've >>merely made it more difficult to exploit. I'm not totally sure that's much >>of a gain. >> >>> The idea is from the paper: >>> Tuomas Aura and Pekka Nikander, "Stateless connections", in proceedings of >>> International Conference on Information and Communications Security >>> ICICS'97, Beijing, November 1997, pp. 87-97, Lecture Notes in Computer Science 1334, >>> Springer Verlag 1997. >>> http://www.tcm.hut.fi/~pnr/publications/index.html >> >>> This "state payload" is about the same idea that I've written about in >>> my previous postings about the DoS attack, but at that time I didn't use >>> the same terminology or encapsulate the information in one place. >> >>> The "state payload" can be used by only some of the entities in the >>> Internet if we give it the following rule: >>> - If a "state payload" is received in message N by entity A, entity >>> A must include the "state payload" in message N+1 sent by entity A, >>> without any modifications to its contents. >>> This puts all of the responsibility for the security properties of >>> the "state payload" to the entity that uses it. (And ultimately to >>> IETF to specify safe usages for it.) >> >>> If there's interest for the "state payload", I can write it in the >>> form of a draft. >> >> I would personally say so... I would like to see if this could >>be implemented and effectively nullify this attack. ---- **** ---- Kanta MATSUURA, Ph.D. Lecturer 3rd Department, Institute of Industrial Science, University of Tokyo, Roppongi 7-22-1, Minato-ku, Tokyo 106-8558, JAPAN Tel: +81-3-3402-6231 (ext. 2325) Fax: +81-3-3479-1736 E-Mail: kanta@iis.u-tokyo.ac.jp From owner-ipsec@lists.tislabs.com Wed Feb 2 08:18: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 IAA16451; Wed, 2 Feb 2000 08:18:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08573 Wed, 2 Feb 2000 10:08:23 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B788F2C@md-exchange1.nai.com> From: "Mason, David" To: "'karn@qualcomm.com'" , rgm-sec@htt-consult.com Cc: ipsec@lists.tislabs.com Subject: RE: Bruce Schneier on IPsec Date: Wed, 2 Feb 2000 07:09:50 -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 thought ESPNULL might be useful for things like IETF web sites where you might be retrieving public documents that you want to make sure you receive unaltered but aren't concerned about the confidentiality of the traffic. -dave -----Original Message----- From: Phil Karn [mailto:karn@ka9q.ampr.org] Sent: Tuesday, February 01, 2000 8:04 PM To: rgm-sec@htt-consult.com Cc: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec >it took a while to admit that and develop a NULL encrypt mode for ESP. The >ONLY arguements for AH in v4 space were political/administrative. I will >drop this line of reason at this point before I dig a fight line :) I point out that those political/administrative arguments were made largely obsolete two weeks ago when the US crypto export rules were finally relaxed. As I understand it, US export controls were the primary motivation both for AH (or an authentication-only ESP) and for single-key DES. Phil From owner-ipsec@lists.tislabs.com Wed Feb 2 09:23: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 JAA18992; Wed, 2 Feb 2000 09:23:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08805 Wed, 2 Feb 2000 10:54:25 -0500 (EST) Date: Wed, 2 Feb 2000 10:59:21 -0500 Message-Id: <200002021559.KAA08363@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David_Mason@nai.com Cc: karn@qualcomm.com, rgm-sec@htt-consult.com, ipsec@lists.tislabs.com Subject: RE: Bruce Schneier on IPsec References: <447A3F40A07FD211BA2700A0C99D759B788F2C@md-exchange1.nai.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Mason," == Mason, David writes: Mason,> I thought ESPNULL might be useful for things like IETF web Mason,> sites where you might be retrieving public documents that you Mason,> want to make sure you receive unaltered but aren't concerned Mason,> about the confidentiality of the traffic. That's conceivable but it seems a bit of a stretch. A much better way of doing that is to sign the documents, as is already done, say, with Linux kernels. paul From owner-ipsec@lists.tislabs.com Wed Feb 2 10:59: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 KAA21866; Wed, 2 Feb 2000 10:59:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09219 Wed, 2 Feb 2000 12:16:36 -0500 (EST) From: Dan McDonald Message-Id: <200002021721.JAA21574@kebe.eng.sun.com> Subject: IPsec at Connectathon To: ipsec@lists.tislabs.com Date: Wed, 2 Feb 2000 09:21:37 -0800 (PST) Reply-To: audrey@vanb.com X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's official now. IPsec will be at Connectathon next month. See the web site: www.connectathon.org for details, or contact Audrey Van Bellingham: audrey@vanb.com. Thanks, Dan From owner-ipsec@lists.tislabs.com Wed Feb 2 11:08: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 LAA22116; Wed, 2 Feb 2000 11:08:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09342 Wed, 2 Feb 2000 12:43:48 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF011712B4@exchange> From: Andrew Krywaniuk To: Ari Huttunen Cc: ipsec@lists.tislabs.com Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Date: Wed, 2 Feb 2000 12:50:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Ari, I actually agree with what you said. My only disagreement was that I thought you were suggesting using a CPU-intensive algorithm (e.g. RSA) to sign the data when a fast algorithm would work just as well. That was just a misunderstanding of your previous message. What I was trying to point out is that reflecting the state payload is functionally equivalent to just sending the information when it is needed. How you design the protocol is based on the tradeoffs involved. As Ted pointed out, the design of the current IKE exchanges was a tradeoff of responder state against network latency. But within the Isakmp/Oakley framework, you are free to propose new phase 1 exchanges. We already have one proposal for a DoS resistant (against CPU-usage attacks) exchange (base mode), and if it becomes necessary then someone can invent a new exchange that has resistance to cookie clogging attacks. The state payload would work for this, but in terms of efficiency (in this case, throughput), having the responder generate the SA proposal would be more efficient. I don't see anywhere in Isakmp where it says that the initiator must generate the proposals; if you are inventing a new exchange, you are free to put the payloads in whichever message you want. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Feb 2 17:31: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 RAA28457; Wed, 2 Feb 2000 17:31:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10486 Wed, 2 Feb 2000 18:59:30 -0500 (EST) Date: Wed, 2 Feb 2000 16:04:31 -0800 Message-Id: <200002030004.QAA03240@homer.ka9q.ampr.org> From: Phil Karn To: David_Mason@nai.com CC: rgm-sec@htt-consult.com, ipsec@lists.tislabs.com In-reply-to: <447A3F40A07FD211BA2700A0C99D759B788F2C@md-exchange1.nai.com> (David_Mason@nai.com) Subject: Re: Bruce Schneier on IPsec Reply-to: karn@qualcomm.com References: <447A3F40A07FD211BA2700A0C99D759B788F2C@md-exchange1.nai.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I thought ESPNULL might be useful for things like IETF web sites where you >might be retrieving public documents that you want to make sure you receive >unaltered but aren't concerned about the confidentiality of the traffic. This sort of thing is *much* better accomplished with PGP cleartext signatures. This is already standard practice for the distribution of much open source software, especially security software. The big benefit is that the protection is much more end-to-end than anything IPSec could provide. Consider the effect of mirror sites and web caches, for example. Phil From owner-ipsec@lists.tislabs.com Wed Feb 2 17: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 RAA28485; Wed, 2 Feb 2000 17:31:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10497 Wed, 2 Feb 2000 19:00:23 -0500 (EST) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 2 Feb 2000 16:04:04 -0800 (PST) From: Jan Vilhuber To: Kim Edwards cc: "ipsec@lists.tislabs.com" Subject: Re: Racing IKE SAs Revisited In-Reply-To: <389709CA.8125AD94@americasm01.nt.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 1 Feb 2000, Kim Edwards wrote: > context.... two peers simultaneously attempt to negotiate an IKE SA with > each other > > After perusing the archives, it seems that implementations are > supporting the simultaneous negotiation of 2 IKE SAs. Assume that PFS > is not required and the two IKE SAs were successfully negotiated. > > Do we still keep both IKE SAs around until they expire? > If so, can one peer use both IKE SAs to negotiate two different IPsec > SAs? > Yes. You must keep both around. Which would you delete? What if the peer deleted the other one? I don't see a reason to not use either. If someone wants to formalize a way to drop one of the two, I wouldn't have any objections. As it is, it's an annoyance, but doesn't present any problems. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Feb 2 17:44: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 RAA28737; Wed, 2 Feb 2000 17:44:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10624 Wed, 2 Feb 2000 19:25:39 -0500 (EST) Message-Id: <4.2.0.58.20000202192816.00d1f740@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 02 Feb 2000 19:30:34 -0500 To: "Mason, David" , "'karn@qualcomm.com'" From: Robert Moskowitz Subject: RE: Bruce Schneier on IPsec Cc: ipsec@lists.tislabs.com In-Reply-To: <447A3F40A07FD211BA2700A0C99D759B788F2C@md-exchange1.nai.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 07:09 AM 2/2/2000 -0800, Mason, David wrote: >I thought ESPNULL might be useful for things like IETF web sites where you >might be retrieving public documents that you want to make sure you receive >unaltered but aren't concerned about the confidentiality of the traffic. ESPNULL is for things like connections between robots and robotic controllers on assembly lines. No one cares who sees the robot instructions: turn here, weld here. But you care a lot who tells the robots what to do. Plus those robots ain't so smart. they need all of their CPU to weld the cars, not the people. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Wed Feb 2 17:50: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 RAA28860; Wed, 2 Feb 2000 17:50:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10607 Wed, 2 Feb 2000 19:20:02 -0500 (EST) Date: Wed, 2 Feb 2000 16:24:28 -0800 Message-Id: <200002030024.QAA03282@homer.ka9q.ampr.org> From: Phil Karn To: henry@spsystems.net CC: ipsec@lists.tislabs.com In-reply-to: (message from Henry Spencer on Tue, 1 Feb 2000 12:50:47 -0500 (EST)) Subject: Re: Bruce Schneier on IPsec Reply-to: karn@qualcomm.com References: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >It may not be traditional, but it is increasingly common in the real >world. And the sysadmins are not going to want to deal with two separate >filtering mechanisms, one inside IPSec and one for everything else. Exactly my point. IP policy routing mechanisms can be complicated and hard to understand, even for someone who is already familiar with IP routing. So it is especially important to do things in a modular fashion and to avoid redundant duplication of redundant facilities... Phil From owner-ipsec@lists.tislabs.com Wed Feb 2 20:42: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 UAA10951; Wed, 2 Feb 2000 20:42:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA10908 Wed, 2 Feb 2000 21:16:51 -0500 (EST) Date: Wed, 2 Feb 2000 18:21:47 -0800 Message-Id: <200002030221.SAA03463@homer.ka9q.ampr.org> From: Phil Karn To: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec Reply-to: karn@qualcomm.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some more thoughts on IPSec and where it is going. Large committee projects like IPSec always tend to take on lives of their own. Not only is there "feature creep", but they tend to resist or ignore external events and trends that change the relevance of their original goals. When IPSec started in 1992, most Internet nodes were still large, stationary and connected through LANs and other hardwired paths. Internet encryption was nearly nonexistent. PGP was less than a year old and its legal status was controversial at best. It certainly wasn't used to sign files as much as it is now. SSL didn't exist. SSH didn't exist. Heck, the web didn't exist. Lots of people were contemplating adding security to each application protocol, and I pitched IPSec as a way to reduce duplication of development effort. But IPSec's real problem is that TCP/IP is steadily becoming less and less end-to-end. Email is the best example. We have lots of dumb email clients like Netscape and Eudora that cannot do their own outbound delivery; and we have POP, needed by the millions of PC users on dialup ISPs who cannot run their own full-time mail receivers. Many web transactions are also not end-to-end, thanks to web proxy caches and mirrors. And then there's NAT and SOCKS... I don't like this retreat from end-to-end purity either, but it's a fact of life. These applications still need security, and it's clear that IPSec cannot hope to provide it on a proper end-to-end basis. There's just no alternative to application-level security. IPSec still has a very important role in creating secure virtual private networks. But it is going to have to be *substantially* simplified if it's going to have a real chance to do this in a way that satisfies experts like Schneier. The very last thing we want is something we think is secure, but isn't. Phil From owner-ipsec@lists.tislabs.com Thu Feb 3 01:18: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 BAA18602; Thu, 3 Feb 2000 01:18:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA11555 Thu, 3 Feb 2000 02:47:27 -0500 (EST) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E37079@eseis06nok> To: ipsec@lists.tislabs.com Subject: DoS Attacks review? Date: Thu, 3 Feb 2000 09:52:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm new in the list. Could someone one give me a list of possible protections methods against DoS attacks when using ISAKMP? Thanks! Toni Barrera From owner-ipsec@lists.tislabs.com Thu Feb 3 02:01: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 CAA19551; Thu, 3 Feb 2000 02:01:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11699 Thu, 3 Feb 2000 03:39:55 -0500 (EST) Date: Thu, 3 Feb 2000 10:44:52 +0200 (EET) From: Markku Savela Message-Id: <200002030844.KAA28887@anise.tte.vtt.fi> To: karn@qualcomm.com CC: ipsec@lists.tislabs.com In-reply-to: <200002030221.SAA03463@homer.ka9q.ampr.org> (message from Phil Karn on Wed, 2 Feb 2000 18:21:47 -0800) Subject: Re: Bruce Schneier on IPsec Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > But IPSec's real problem is that TCP/IP is steadily becoming less and > less end-to-end. Email is the best example. We have lots of dumb email > clients like Netscape and Eudora that cannot do their own outbound > delivery; and we have POP, needed by the millions of PC users on > dialup ISPs who cannot run their own full-time mail receivers. POP and IMAP servers are one place to apply IPSEC. Instead of having to create special SSLized POP/IMAP/etc clients, one could have machines running the servers require IPSEC for accessing the services. This is just another form of end-to-end application. Actually HTTPS could also be similarly replaced with IPSEC + HTTP? This way the client applications can be used unchanged, when the client host has IPSEC. The servers admin would also be its own CA, and thus having the full control of the certificates being used to access. The above scenario applies to the situations where the user end is users own personal host (PC, palm device or mobile phone). It does not fit a case where the users end is just an account on a shared host. But then, who would trust cryptographic programs on a host that one does not have full control of? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Feb 3 04:08: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 EAA23940; Thu, 3 Feb 2000 04:08:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA12158 Thu, 3 Feb 2000 05:47:27 -0500 (EST) Message-Id: <200002031052.NAA15642@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: ipsec@lists.tislabs.com Date: Thu, 3 Feb 2000 13:51:56 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Multiple transforms in New Group mode X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a question regarding New Group mode. Is it possible to put multiple transforms proposing different groups into one SA in New Group mode? IKE says nothing about this, so it is not explicitly prohibited. However, if it is allowed, what semantics does it have for responder? Should responder select only one group (usual SA semantics) or is he/she allowed to select multiple of them, or must he/she always accept/reject all the proposals? How other vendors handle this situation? Best regards, Valera. From owner-ipsec@lists.tislabs.com Thu Feb 3 07:46: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 HAA29644; Thu, 3 Feb 2000 07:45:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12890 Thu, 3 Feb 2000 09:11:18 -0500 (EST) From: "Mr. Anderson" Message-Id: <200002031416.JAA18116@linux.silkroad.com> Subject: Re: Bruce Schneier on IPsec To: ipsec@lists.tislabs.com Date: Thu, 3 Feb 100 09:16:03 -0500 (EST) In-Reply-To: <200002030221.SAA03463@homer.ka9q.ampr.org> from "Phil Karn" at Feb 2, 0 06:21:47 pm 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 > I don't like this retreat from end-to-end purity either, but it's a > fact of life. These applications still need security, and it's clear > that IPSec cannot hope to provide it on a proper end-to-end basis. > There's just no alternative to application-level security. > > IPSec still has a very important role in creating secure virtual > private networks. But it is going to have to be *substantially* > simplified if it's going to have a real chance to do this in a way > that satisfies experts like Schneier. The very last thing we want is > something we think is secure, but isn't. > Concur 101 percent. Should build something simple and secure without too many features and insure that DoS attacks are addressed. Building a very secure tunnel mode first, which is easily managed, sustainable, and not subject to every future kiddie script-style hack is 'key'. Suggest a phased approach which insures a level playing field for all potential IPSEC vendors. -Neo From owner-ipsec@lists.tislabs.com Thu Feb 3 07:51: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 HAA29900; Thu, 3 Feb 2000 07:51:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13020 Thu, 3 Feb 2000 09:40:49 -0500 (EST) Date: Thu, 3 Feb 2000 16:45:52 +0200 (EET) Message-Id: <200002031445.QAA28482@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Valery Smyslov" Cc: ipsec@lists.tislabs.com Subject: Multiple transforms in New Group mode In-Reply-To: <200002031052.NAA15642@relay1.trustworks.com> References: <200002031052.NAA15642@relay1.trustworks.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 Valery Smyslov writes: > I have a question regarding New Group mode. Is it possible to put > multiple transforms proposing different groups into one SA in New > Group mode? Yes. > IKE says nothing about this, so it is not explicitly > prohibited. However, if it is allowed, what semantics does it have > for responder? Should responder select only one group (usual SA > semantics) or is he/she allowed to select multiple of them, or must > he/she always accept/reject all the proposals? He must select only one group. > How other vendors handle this situation? At least that is what we do in that situation. -- 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 Feb 3 08:53: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 IAA01640; Thu, 3 Feb 2000 08:53:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13279 Thu, 3 Feb 2000 10:32:59 -0500 (EST) Message-Id: Date: Thu, 3 Feb 2000 10:30:47 EST From: opitz@thematrix.ncsc.mil (Dave Opitz) To: ipsec@lists.tislabs.com Subject: Denial of Service Testing Results Cc: opitz@thematrix.ncsc.mil Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've used a program derived from Simpson's, as well as another program of my own to do some testing for the practicality of IPSec DoS attacks. I have a few IPSec devices from different vendors with which I can do this testing. While there are certainly theoretical DoS attacks against IKE, I don't think these attacks are very real, and I don't think the IPSec specifications need to be changed. I was able to use (a variation of) Simpson's code to flood some devices, sometimes using up to 100% of the CPU, but I don't think it had anything to do with IPSec. Later testing of sending just a few hundred IKE message 1's showed that the first few (around 50-100) got responses, while the rest were just ignored. It takes resources to ignore many messages, perhaps maxing out the network card, or filling the input buffer. I think it could have been any type of packet coming that fast. While the above attack was going on, I checked the memory usage on the Windows machine, and it barely moved. I don't think the "cookie crumbs" amounted to a hill of beans. The suggested garbage collection was probably working, and connections beyond what the device could handle were just dropped. One of the gateway devices required me to type in the address of the other gateway I could have multiple gateways for the other side, but I had to type each one in. This prevented me from using the spoofing capability in Simpson's code, and the gateway was smart enough to attempt to finish (timeout, in this case) one negotiation with a location before responding to another IKE request from the same address. Another gateway allowed wildcard characters for the other gateway. However, this one ran in Main Mode. I could get similar results using the flooding reported above. To test if the Diffie-Hellman calculation slowed things down, I created another program to capture the returned IKE message 2, grab the cookie out of it, and then send a bogus message 3 at the target. The target just didn't respond to IKE message 1's fast enough, only creating occasional message 2's, so the message 3's appeared relatively infrequently (compared to the frequency of the message 1's), and the target was able to keep up generating message 4's. One problem with collecting message 2's to force the Diffie-Hellman calculation in Main Mode is that you must be on the return path of the spoofed IP address. Gaining this much access to a target can be very difficult. I also did some testing by sending a few hundred IKE packets at something that could do either Main Mode or Aggressive Mode. In each case, it dropped everything other than approximately the first 60 negotiations (MM) or 35 negotiations (AM). And because it only started up 35 Aggressive Mode negotiations, it was able to time them out quicker, and recover FASTER than against the Main Mode attack. I've also heard the some IPSec devices can handle 500, or maybe 1,000 simultaneous connections. I haven't figured out how these work. Are those 500 completed IKE exchanges, or 500 initiated ones? If only initiated, then one could use up these resources (as opposed to CPU or memory) using the flooding from above, and then only send an occasional new connection to take the place of timed out connections. To sum up - I don't see much of a DoS problem between gateways (one very common use of IPSec). I don't see much of a DoS problem in Main Mode. And in the most common cases remaining (Aggressive Mode, and Remote Access), I think garbage collecting, and timing out negotiations can be effectively used. You can't stop all DoS attacks, but I don't see a need to rewrite the IPSec documents to handle this. There are issues I haven't been able to test, and maybe someone can provide some answers. Devices that are specifically designed to accept Remote Access connections can be connected to from any IP address. I didn't test any of these - only gateway devices that allow wildcard characters. How would they stand up to this testing? What about hardware IPSec boxes that may have limited memory? Has anyone gotten any of these attacks to work in practice? Can anyone suggest a thorough DoS test plan? What other defenses do implementors use against DoS in IPSec? Dave Opitz NSA opitz@thematrix.ncsc.mil From owner-ipsec@lists.tislabs.com Thu Feb 3 09:04: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 JAA01797; Thu, 3 Feb 2000 09:04:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13365 Thu, 3 Feb 2000 10:49:04 -0500 (EST) Message-Id: <4.2.0.58.20000203104823.00d259b0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 03 Feb 2000 10:53:38 -0500 To: "Mr. Anderson" , ipsec@lists.tislabs.com From: Robert Moskowitz Subject: Re: Bruce Schneier on IPsec In-Reply-To: <200002031416.JAA18116@linux.silkroad.com> References: <200002030221.SAA03463@homer.ka9q.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:16 AM 2/3/2000 -0500, Mr. Anderson wrote: >Building a very secure tunnel mode first, which >is easily managed, sustainable, and not subject to every >future kiddie script-style hack is 'key'. I have thought about this for over a year and have realized this was one of our design FLAWS. We designed for gateways instead of end systems. End systems don't need tunnels, they only need warpping. In part we took this approach because, 'it will take too long to update the end systems'. But proxy services could have handled this in the interim. Now we have and industry of gateway systems that need technology that advances their core business models. The trick is how to rebuild the bridge while using it. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Thu Feb 3 11:02: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 LAA04489; Thu, 3 Feb 2000 11:02:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13772 Thu, 3 Feb 2000 12:32:35 -0500 (EST) Date: Thu, 3 Feb 2000 11:37:40 -0600 From: Will Fiveash To: ipsec@lists.tislabs.com Subject: Commit Bit and SPI? Message-ID: <20000203113740.B64112@austin.ibm.com> Mail-Followup-To: ipsec@lists.tislabs.com References: <319A1C5F94C8D11192DE00805FBBADDF0113B924@exchange> <20000201150138.A64112@austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <20000201150138.A64112@austin.ibm.com>; from will@austin.ibm.com on Tue, Feb 01, 2000 at 03:01:39PM -0600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Feb 01, 2000 at 03:01:39PM -0600, Will Fiveash wrote: > Dan, can we change the draft-ieft-ipsec-ike-01.txt so that we get a > standardized way of interpreting the reflection or non-reflection of the > CB? I think this will give implementors reasonable flexibility in that if > they do not want to implement CB they just have to make sure they don't > reflect the CB. If they do support CB then they have to check for > reflection which is easy. And while I am on the subject of connect-notify. Can someone tell me whether I need to check the SPI in the connect-notify against the SPI in my P2 SA? I ask this because I saw almost every permutation of SPI in the connect-notify payload from various vendors. And I noticed that few vendors checked the SPI I sent in the connect-notify. If I am supposed to check the SPI, can someone make it painfully clear as to which SPI is supposed to be sent in the connect-notify? Given the confusion in the last bakeoff it seems to me that this issue should be addressed in one of the documents. As an aside, I am somewhat disappointed that I haven't seen any responses from the document owners stating whether they agree with the recent e-mails regarding commit bit processing and SPIs. Does anyone else find it ironic that Bruce Schneier's paper which criticizes the IPSec workgroup method of standards development is receiving lots of discussion on this list while the discussion on commit bit which is trying to clarify the protocol documentation is receiving little attention? -- Will Fiveash IBM AIX System Development From owner-ipsec@lists.tislabs.com Thu Feb 3 13: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 NAA06952; Thu, 3 Feb 2000 13:46:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA14490 Thu, 3 Feb 2000 15:05:28 -0500 (EST) Message-ID: <3899DCB2.B35EBF92@radium.ncsc.mil> Date: Thu, 03 Feb 2000 14:53:22 -0500 From: Desiree Beck X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: digital signature description in IKE draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A comment on the text in Section 6.1.1.2, "Main Mode Authentication with Digital Signatures" of draft-ietf-ipsec-ike-01.txt I don't think the redefinitions of the usual notions of digital signatures are explicit enough and consequently, I think the text is confusing. Assuming that I have an accurate understanding of what's intended, I suggest that the text after the message exchange diagram read: ----- begin ----- Where SIG_I and SIG_R are digital signatures of I-digest and R-digest (section 4.1), respectively, and are presented in a signature payload. Note that, in general, the signature will be computed directly over the I-digest or R-digest, which are generated by the pseudo-random function. However, if the signature algorithm is tied to a particular hash algorithm, then the digest should be computed using that particular hash algorithm. In other words, instead of computing the digest as digest = prf(key|msg), the digest should be computed as digest = hash(key|msg). For example, when using DSA signatures, SHA-1 must be used in place of the prf to compute the I-digest and R-digest (DSA is only defined with SHA-1). Furthermore, the DSA signature MUST be encoded as the value "r" followed by the value "s" where "r" is computed as usual, but where "s" = (k^(-1))(digest + xr) mod q. When using RSA signatures, SIG_I and SIG_R are actually private key encryptions where the I-digest and R-digest are encoded by the PKCS #1 v2.0 (OAEP) method used for encryption, rather than by the method used for signatures ([PKCS1]). Note that there is no correlation between the hash OIDs used in [PKCS1] and those used in this document; however, since the prf is known, there is no need to encode the OID into the signature. See Section 9, "Security Considerations", for PKCS1 padding requirements. ----- end ----- Desiree Beck NSA dbeck@radium.ncsc.mil From owner-ipsec@lists.tislabs.com Thu Feb 3 14:28: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 OAA07451; Thu, 3 Feb 2000 14:28:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14827 Thu, 3 Feb 2000 16:14:20 -0500 (EST) Date: Thu, 3 Feb 2000 13:19:17 -0800 (PST) Message-Id: <200002032119.NAA10359@servo.qualcomm.com> From: Phil Karn To: msa@hemuli.tte.vtt.fi CC: ipsec@lists.tislabs.com, karn@qualcomm.com In-reply-to: <200002030844.KAA28887@anise.tte.vtt.fi> (message from Markku Savela on Thu, 3 Feb 2000 10:44:52 +0200 (EET)) Subject: Re: Bruce Schneier on IPsec Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >POP and IMAP servers are one place to apply IPSEC. Instead of having >to create special SSLized POP/IMAP/etc clients, one could have >machines running the servers require IPSEC for accessing the >services. This is just another form of end-to-end application. You miss my point. The introduction of POP, IMAP and outbound mail relays has destroyed the end-to-end nature of TCP/IP. Sure, you can apply IPSEC to POP and IMAP sessions, just like any other TCP/IP application. That would be better than nothing. But your email is still exposed on the POP/IMAP/SMTP servers, and IPSEC is powerless to protect it. Only a tool like PGP, run at the ultimate endpoints (i.e., the users' mail agents), can provide true end-to-end email security. Phil From owner-ipsec@lists.tislabs.com Thu Feb 3 17:55: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 RAA10048; Thu, 3 Feb 2000 17:55:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA15463 Thu, 3 Feb 2000 19:32:50 -0500 (EST) Date: Thu, 3 Feb 2000 16:37:53 -0800 Message-Id: <200002040037.QAA10399@homer.ka9q.ampr.org> From: Phil Karn To: rgm-sec@htt-consult.com CC: David_Mason@nai.com, ipsec@lists.tislabs.com In-reply-to: <4.2.0.58.20000202192816.00d1f740@homebase.htt-consult.com> (message from Robert Moskowitz on Wed, 02 Feb 2000 19:30:34 -0500) Subject: Re: Bruce Schneier on IPsec Reply-to: karn@qualcomm.com References: <4.2.0.58.20000202192816.00d1f740@homebase.htt-consult.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >No one cares who sees the robot instructions: turn here, weld here. But >you care a lot who tells the robots what to do. Plus those robots ain't so >smart. they need all of their CPU to weld the cars, not the people. I think if these robots are smart enough to run an authentication algorithm, they are almost certainly smart enough to run an encryption algorithm. phil From owner-ipsec@lists.tislabs.com Thu Feb 3 22: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 WAA25089; Thu, 3 Feb 2000 22:43:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA16223 Fri, 4 Feb 2000 00:24:47 -0500 (EST) Date: Thu, 3 Feb 2000 22:48:03 -0500 (EST) From: Henry Spencer To: Phil Karn cc: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec In-Reply-To: <200002032119.NAA10359@servo.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 3 Feb 2000, Phil Karn wrote: > You miss my point. The introduction of POP, IMAP and outbound mail > relays has destroyed the end-to-end nature of TCP/IP... your email is > still exposed on the POP/IMAP/SMTP servers, and IPSEC is powerless to > protect it... I would say that POP etc. are johnny-come-latelies here. SMTP stopped being guaranteed end-to-end with the advent of the MX record. (Indeed, somewhat before that if you were on, say, CSNET -- MX just formalized and generalized tricks which were already being done by special-case kludges.) > Only a tool like PGP, run at the ultimate endpoints (i.e., > the users' mail agents), can provide true end-to-end email security. If one is taking "end-to-end" in this strong a sense, then one should not muddy the waters with references to POP etc. Not even pre-MX SMTP delivered this level of end-to-end-ness; delivery direct to your host seldom, if ever, implied delivery direct to your mail agent. (And for that matter, even delivery direct to your mail agent still requires that you trust the infrastructure it is running on, e.g. the memory protection of the operating system.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Feb 4 06:02: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 GAA05485; Fri, 4 Feb 2000 06:02:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA17430 Fri, 4 Feb 2000 07:21:57 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14490.50523.321831.912149@thomasm-u1.cisco.com> Date: Fri, 4 Feb 2000 04:26:03 -0800 (PST) To: Henry Spencer Cc: Phil Karn , ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec In-Reply-To: References: <200002032119.NAA10359@servo.qualcomm.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 Henry Spencer writes: > On Thu, 3 Feb 2000, Phil Karn wrote: > > Only a tool like PGP, run at the ultimate endpoints (i.e., > > the users' mail agents), can provide true end-to-end email security. > > If one is taking "end-to-end" in this strong a sense, then one should not > muddy the waters with references to POP etc. Not even pre-MX SMTP > delivered this level of end-to-end-ness; delivery direct to your host > seldom, if ever, implied delivery direct to your mail agent. (And for > that matter, even delivery direct to your mail agent still requires that > you trust the infrastructure it is running on, e.g. the memory protection > of the operating system.) I hope that the implications here are not that this is some sort of either/or situation. It may be perfectly reasonable to use hop by hop IPsec to secure transport, as well as using end to end PGP for application layer privacy. They are two different problems. For example, I'd like to thwart spammers from creating spam lists by snooping at unencrypted SMTP packets going by. This can easily be achieved by using hop to hop IPSec. I suppose that PGP could do that too, but there may be big benefits of caching the results of public key operations for key exchange in the form of SA's for well traveled mail paths, and IPSec does this quite nicely. The less well traveled paths devolve into their non-cached counterpart which is probably a wash. SIP has an identical set of issues, FWIW. Mike From owner-ipsec@lists.tislabs.com Fri Feb 4 06:40: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 GAA06333; Fri, 4 Feb 2000 06:40:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17604 Fri, 4 Feb 2000 08:21:30 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: ipsec@lists.tislabs.com Message-ID: <8525687A.008033CC.00@domino2.certicom.com> Date: Thu, 3 Feb 2000 15:25:40 -0800 Subject: config mode Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all: I was trying to understand config mode and how it works/how widely deployed is. Would anybody have any pointers? Thanks in advance - John From owner-ipsec@lists.tislabs.com Fri Feb 4 12:07: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 MAA20415; Fri, 4 Feb 2000 12:07:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA18837 Fri, 4 Feb 2000 13:10:30 -0500 (EST) Message-Id: <200002041812.KAA08252@potassium.network-alchemy.com> To: Will Fiveash cc: ipsec@lists.tislabs.com Subject: Re: Commit Bit and SPI? In-reply-to: Your message of "Thu, 03 Feb 2000 11:37:40 CST." <20000203113740.B64112@austin.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8249.949687953.1@network-alchemy.com> Date: Fri, 04 Feb 2000 10:12:33 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Will, Should you check the SPI and if so which one? Well if you have to check the SPI it makes sense for it to be the one with the responder's destination address in the tuple that identifies the SA since it is the responder saying, "OK, now I'm ready, you can start using this". But should you even check it? I'm not so sure. If N SA pairs were negotiated in the single Quick Mode do you send N notify messages? That doesn't seem all that informative. When the responder sends the final message it means he's ready with everything so if that message contains 1 notify or N it's meaning isn't different (at least to me). The other issue is do you have to reflect back the bit if the peer sets it or can you "negotiate" this capability? Well if you could choose to reflect it what if the initiator sets it in Quick Mode message #3? Something has to be said to clear this up, yes. But it's a decision of the WG. Do we send a notify for each SA pair containing the responder's SPI(s) or do we send a single notify with no SPIs? Can we not reflect the commit bit and if so what does that mean? Who can set the commit bit and where should that be allowed and prohibited? If we can get some consensus on this matter it'll go in the document but a unilateral decision by me will only result in conflict. I'm sorry you are disappointed in my lack of attention to this but the IETF does not pay and consequently gets put in my queue at the appropriate place. I'm trying but these are crazy times. Dan. On Thu, 03 Feb 2000 11:37:40 CST you wrote > On Tue, Feb 01, 2000 at 03:01:39PM -0600, Will Fiveash wrote: > > Dan, can we change the draft-ieft-ipsec-ike-01.txt so that we get a > > standardized way of interpreting the reflection or non-reflection of the > > CB? I think this will give implementors reasonable flexibility in that if > > they do not want to implement CB they just have to make sure they don't > > reflect the CB. If they do support CB then they have to check for > > reflection which is easy. > > And while I am on the subject of connect-notify. Can someone tell me > whether I need to check the SPI in the connect-notify against the SPI in my > P2 SA? I ask this because I saw almost every permutation of SPI in the > connect-notify payload from various vendors. And I noticed that few > vendors checked the SPI I sent in the connect-notify. > > If I am supposed to check the SPI, can someone make it painfully clear as > to which SPI is supposed to be sent in the connect-notify? Given the > confusion in the last bakeoff it seems to me that this issue should be > addressed in one of the documents. > > As an aside, I am somewhat disappointed that I haven't seen any responses > from the document owners stating whether they agree with the recent e-mails > regarding commit bit processing and SPIs. Does anyone else find it ironic > that Bruce Schneier's paper which criticizes the IPSec workgroup method of > standards development is receiving lots of discussion on this list while > the discussion on commit bit which is trying to clarify the protocol > documentation is receiving little attention? > > -- > Will Fiveash > IBM AIX System Development From owner-ipsec@lists.tislabs.com Fri Feb 4 13:11: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 NAA24962; Fri, 4 Feb 2000 13:11:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19436 Fri, 4 Feb 2000 14:46:50 -0500 (EST) Message-ID: <389B2DBF.AB584899@bbn.com> Date: Fri, 04 Feb 2000 14:51:35 -0500 From: Steve Kent Reply-To: kent@bbn.com Organization: GTE Internetworking X-Mailer: Mozilla 4.61 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Phil Karn CC: ipsec@lists.tislabs.com Subject: Re: Bruce Schneier on IPsec References: <200002032119.NAA10359@servo.qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Phil, I'm puzzled by your commnets re the applicability of IPsec to the protection of e-mail. E-mail has ALWAYS been a staged delivery application and that's why S/MIME and OPGP are appropriate protocols for securing it. This is a not a new issue and IPsec has never been promoted as a substitute for e-mail security protocols. Yes, one can use IPsec for point-to-point protection of e-mail, but that is not a primary goal for this protocol. On a broader note, I think that we may be forgetting that encryption, per se, is probably not the most important feature of IPsec. Most IPsec users, certainly in the commercial sector, are more at risk from intrusions than from just passive wiretapping. Some amount of the complexity of IPsec arises because it embodies access controls, applied at both sender and receiver. One cannot remove these controls from IPsec without degrading the security they provide. The reason is that only within IPsec does a receiver know the SA with which the traffic is associated, and thus what access control checks are appropriate for the traffic exiting the SA. Thus, for example, removing these controls from IPsec (which have a lot to do with the differences in processing for tunnel vs. transport mode) and putting a packet filtering firewall behind an IPsec device does not provide the same access control capability. Another issue that has come up is the utility of authentication only services, either AH or auth-only ESP. These modes of operation are not present solely because of export controls. For example, one might use a tunnel SA with ESP from a mobile user to a security gateway at a corporate site, then employ and authentication-only transport SA, nested inside the tunnel, to get to a host on the corporate LAN. The latter use would allow a suitably configured firewall to examine the port fields of the inner packet, an ability many system security administrators may still require. Steve From owner-ipsec@lists.tislabs.com Fri Feb 4 23:47: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 XAA20087; Fri, 4 Feb 2000 23:47:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA20985 Sat, 5 Feb 2000 01:17:19 -0500 (EST) Message-ID: <389BC1A4.907A2FF8@cyphers.net> Date: Fri, 04 Feb 2000 22:22:30 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Proposal for new DH Groups 6, 7, and 8 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 BAA20982 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There was much discussion at the recent bakeoff regarding DH prime lengths. It was good to see that a number of people were implementing Group 5, and all but one vendor that I found anyway (who actually changed this during the bakeoff I believe) was doing at least Group 2. However, as was raised at the Wednesday meeting, even Group 5 can be considered too short -- especially as we forge ahead into 256 bit ciphers wherein it is painfully inadequate. I would like to propose three new DH Groups for IKE of 2048, 3072, and 4096 bits. This should adequately cover all foreseeable future needs. I have included documentation on the generation of these primes which were originally generated for PGPfone, and there is an interesting story about how they were generated at the end of this message. I know I should really write this up as a draft, but for now I just want to float this here to get any feedback. The generator is 2 for all of these primes. Group ID: 6 (Note this is not officially assigned yet) DH_2048bitPrime = { 0xF6, 0x42, 0x57, 0xB7, 0x08, 0x7F, 0x08, 0x17, 0x72, 0xA2, 0xBA, 0xD6, 0xA9, 0x42, 0xF3, 0x05, 0xE8, 0xF9, 0x53, 0x11, 0x39, 0x4F, 0xB6, 0xF1, 0x6E, 0xB9, 0x4B, 0x38, 0x20, 0xDA, 0x01, 0xA7, 0x56, 0xA3, 0x14, 0xE9, 0x8F, 0x40, 0x55, 0xF3, 0xD0, 0x07, 0xC6, 0xCB, 0x43, 0xA9, 0x94, 0xAD, 0xF7, 0x4C, 0x64, 0x86, 0x49, 0xF8, 0x0C, 0x83, 0xBD, 0x65, 0xE9, 0x17, 0xD4, 0xA1, 0xD3, 0x50, 0xF8, 0xF5, 0x59, 0x5F, 0xDC, 0x76, 0x52, 0x4F, 0x3D, 0x3D, 0x8D, 0xDB, 0xCE, 0x99, 0xE1, 0x57, 0x92, 0x59, 0xCD, 0xFD, 0xB8, 0xAE, 0x74, 0x4F, 0xC5, 0xFC, 0x76, 0xBC, 0x83, 0xC5, 0x47, 0x30, 0x61, 0xCE, 0x7C, 0xC9, 0x66, 0xFF, 0x15, 0xF9, 0xBB, 0xFD, 0x91, 0x5E, 0xC7, 0x01, 0xAA, 0xD3, 0x5B, 0x9E, 0x8D, 0xA0, 0xA5, 0x72, 0x3A, 0xD4, 0x1A, 0xF0, 0xBF, 0x46, 0x00, 0x58, 0x2B, 0xE5, 0xF4, 0x88, 0xFD, 0x58, 0x4E, 0x49, 0xDB, 0xCD, 0x20, 0xB4, 0x9D, 0xE4, 0x91, 0x07, 0x36, 0x6B, 0x33, 0x6C, 0x38, 0x0D, 0x45, 0x1D, 0x0F, 0x7C, 0x88, 0xB3, 0x1C, 0x7C, 0x5B, 0x2D, 0x8E, 0xF6, 0xF3, 0xC9, 0x23, 0xC0, 0x43, 0xF0, 0xA5, 0x5B, 0x18, 0x8D, 0x8E, 0xBB, 0x55, 0x8C, 0xB8, 0x5D, 0x38, 0xD3, 0x34, 0xFD, 0x7C, 0x17, 0x57, 0x43, 0xA3, 0x1D, 0x18, 0x6C, 0xDE, 0x33, 0x21, 0x2C, 0xB5, 0x2A, 0xFF, 0x3C, 0xE1, 0xB1, 0x29, 0x40, 0x18, 0x11, 0x8D, 0x7C, 0x84, 0xA7, 0x0A, 0x72, 0xD6, 0x86, 0xC4, 0x03, 0x19, 0xC8, 0x07, 0x29, 0x7A, 0xCA, 0x95, 0x0C, 0xD9, 0x96, 0x9F, 0xAB, 0xD0, 0x0A, 0x50, 0x9B, 0x02, 0x46, 0xD3, 0x08, 0x3D, 0x66, 0xA4, 0x5D, 0x41, 0x9F, 0x9C, 0x7C, 0xBD, 0x89, 0x4B, 0x22, 0x19, 0x26, 0xBA, 0xAB, 0xA2, 0x5E, 0xC3, 0x55, 0xE9, 0x32, 0x0B, 0x3B }; Group ID: 7 (Note this is not officially assigned yet) DH_3072bitPrime = { 0xCC, 0x1D, 0x77, 0x57, 0x24, 0x38, 0x4A, 0xE2, 0xC4, 0xF0, 0xE8, 0x8E, 0x13, 0x67, 0x97, 0x4E, 0x92, 0x13, 0x61, 0xF6, 0xDB, 0xEB, 0x25, 0x0E, 0x17, 0xFD, 0xF6, 0x98, 0xF7, 0xC8, 0x7C, 0x79, 0xB0, 0x72, 0x1D, 0x38, 0x75, 0xFB, 0xF6, 0xC1, 0x73, 0xC4, 0x83, 0x11, 0x26, 0x2B, 0x43, 0x60, 0xC3, 0xE3, 0xE8, 0xD6, 0x0A, 0xFD, 0xA1, 0x28, 0x26, 0x0B, 0xAE, 0xA9, 0xAE, 0xB3, 0x65, 0x0F, 0xA2, 0x00, 0x53, 0x01, 0xA0, 0x7C, 0xD6, 0xAB, 0xA3, 0x12, 0x1E, 0xFA, 0x0F, 0x2A, 0xCE, 0x1F, 0x74, 0x84, 0x4F, 0xCA, 0xF3, 0x17, 0xF3, 0xA4, 0x40, 0xE9, 0xD7, 0xD2, 0x77, 0xB6, 0x42, 0x2D, 0x02, 0x36, 0xC1, 0x26, 0xCB, 0x68, 0x5E, 0x9D, 0x7C, 0x98, 0x09, 0x0A, 0x8D, 0x7E, 0x2D, 0xED, 0xE4, 0x5D, 0x79, 0xF5, 0xD4, 0x92, 0x4F, 0x9B, 0x18, 0x8E, 0xFC, 0x2A, 0xA7, 0x4B, 0x7C, 0x32, 0xF6, 0x42, 0x57, 0xB7, 0x08, 0x7F, 0x08, 0x17, 0x72, 0xA2, 0xBA, 0xD6, 0xA9, 0x42, 0xF3, 0x05, 0xE8, 0xF9, 0x53, 0x11, 0x39, 0x4F, 0xB6, 0xF1, 0x6E, 0xB9, 0x4B, 0x38, 0x20, 0xDA, 0x01, 0xA7, 0x56, 0xA3, 0x14, 0xE9, 0x8F, 0x40, 0x55, 0xF3, 0xD0, 0x07, 0xC6, 0xCB, 0x43, 0xA9, 0x94, 0xAD, 0xF7, 0x4C, 0x64, 0x86, 0x49, 0xF8, 0x0C, 0x83, 0xBD, 0x65, 0xE9, 0x17, 0xD4, 0xA1, 0xD3, 0x50, 0xF8, 0xF5, 0x59, 0x5F, 0xDC, 0x76, 0x52, 0x4F, 0x3D, 0x3D, 0x8D, 0xDB, 0xCE, 0x99, 0xE1, 0x57, 0x92, 0x59, 0xCD, 0xFD, 0xB8, 0xAE, 0x74, 0x4F, 0xC5, 0xFC, 0x76, 0xBC, 0x83, 0xC5, 0x47, 0x30, 0x61, 0xCE, 0x7C, 0xC9, 0x66, 0xFF, 0x15, 0xF9, 0xBB, 0xFD, 0x91, 0x5E, 0xC7, 0x01, 0xAA, 0xD3, 0x5B, 0x9E, 0x8D, 0xA0, 0xA5, 0x72, 0x3A, 0xD4, 0x1A, 0xF0, 0xBF, 0x46, 0x00, 0x58, 0x2B, 0xE5, 0xF4, 0x88, 0xFD, 0x58, 0x4E, 0x49, 0xDB, 0xCD, 0x20, 0xB4, 0x9D, 0xE4, 0x91, 0x07, 0x36, 0x6B, 0x33, 0x6C, 0x38, 0x0D, 0x45, 0x1D, 0x0F, 0x7C, 0x88, 0xB3, 0x1C, 0x7C, 0x5B, 0x2D, 0x8E, 0xF6, 0xF3, 0xC9, 0x23, 0xC0, 0x43, 0xF0, 0xA5, 0x5B, 0x18, 0x8D, 0x8E, 0xBB, 0x55, 0x8C, 0xB8, 0x5D, 0x38, 0xD3, 0x34, 0xFD, 0x7C, 0x17, 0x57, 0x43, 0xA3, 0x1D, 0x18, 0x6C, 0xDE, 0x33, 0x21, 0x2C, 0xB5, 0x2A, 0xFF, 0x3C, 0xE1, 0xB1, 0x29, 0x40, 0x18, 0x11, 0x8D, 0x7C, 0x84, 0xA7, 0x0A, 0x72, 0xD6, 0x86, 0xC4, 0x03, 0x19, 0xC8, 0x07, 0x29, 0x7A, 0xCA, 0x95, 0x0C, 0xD9, 0x96, 0x9F, 0xAB, 0xD0, 0x0A, 0x50, 0x9B, 0x02, 0x46, 0xD3, 0x08, 0x3D, 0x66, 0xA4, 0x5D, 0x41, 0x9F, 0x9C, 0x7C, 0xBD, 0x89, 0x4B, 0x22, 0x19, 0x26, 0xBA, 0xAB, 0xA2, 0x5E, 0xC3, 0x55, 0xE9, 0x4C, 0x32, 0x6F }; Group ID: 8 (Note this is not officially assigned yet) DH_4096bitPrime = { 0xF9, 0x18, 0xA0, 0x7E, 0x5A, 0x06, 0x61, 0x7A, 0x43, 0x90, 0x95, 0xDC, 0x05, 0x6C, 0x87, 0x86, 0xEC, 0x61, 0xEC, 0xCD, 0x45, 0x1F, 0x0E, 0xD8, 0xE0, 0xA3, 0x79, 0xC6, 0xC9, 0xDC, 0x7A, 0x0B, 0xAC, 0xE4, 0x3F, 0xE3, 0x46, 0x94, 0xB6, 0x30, 0x4A, 0x53, 0xD7, 0x7C, 0x02, 0x16, 0x48, 0x80, 0xB5, 0x15, 0xE5, 0x29, 0x99, 0xA9, 0x9F, 0x07, 0x74, 0xD3, 0xFF, 0xE3, 0xA1, 0xC5, 0x96, 0x20, 0x4E, 0x98, 0x65, 0xB8, 0xD8, 0x0D, 0xEE, 0x10, 0x5D, 0xAB, 0xB6, 0x17, 0x1C, 0x51, 0xD8, 0x50, 0xCA, 0x22, 0x57, 0x43, 0x29, 0xBE, 0x95, 0xE8, 0x56, 0x2B, 0x38, 0x78, 0x5C, 0x0B, 0xDB, 0xF8, 0x4C, 0x4D, 0xD5, 0xE3, 0xAA, 0x46, 0xCC, 0xFB, 0xCE, 0x17, 0xE8, 0x2A, 0x9D, 0x14, 0x61, 0xE3, 0x84, 0xA9, 0x4F, 0xD1, 0x83, 0x84, 0xA8, 0x79, 0xB6, 0xEF, 0x8F, 0xA7, 0x43, 0x46, 0x08, 0xC6, 0xCC, 0x1D, 0x77, 0x57, 0x24, 0x38, 0x4A, 0xE2, 0xC4, 0xF0, 0xE8, 0x8E, 0x13, 0x67, 0x97, 0x4E, 0x92, 0x13, 0x61, 0xF6, 0xDB, 0xEB, 0x25, 0x0E, 0x17, 0xFD, 0xF6, 0x98, 0xF7, 0xC8, 0x7C, 0x79, 0xB0, 0x72, 0x1D, 0x38, 0x75, 0xFB, 0xF6, 0xC1, 0x73, 0xC4, 0x83, 0x11, 0x26, 0x2B, 0x43, 0x60, 0xC3, 0xE3, 0xE8, 0xD6, 0x0A, 0xFD, 0xA1, 0x28, 0x26, 0x0B, 0xAE, 0xA9, 0xAE, 0xB3, 0x65, 0x0F, 0xA2, 0x00, 0x53, 0x01, 0xA0, 0x7C, 0xD6, 0xAB, 0xA3, 0x12, 0x1E, 0xFA, 0x0F, 0x2A, 0xCE, 0x1F, 0x74, 0x84, 0x4F, 0xCA, 0xF3, 0x17, 0xF3, 0xA4, 0x40, 0xE9, 0xD7, 0xD2, 0x77, 0xB6, 0x42, 0x2D, 0x02, 0x36, 0xC1, 0x26, 0xCB, 0x68, 0x5E, 0x9D, 0x7C, 0x98, 0x09, 0x0A, 0x8D, 0x7E, 0x2D, 0xED, 0xE4, 0x5D, 0x79, 0xF5, 0xD4, 0x92, 0x4F, 0x9B, 0x18, 0x8E, 0xFC, 0x2A, 0xA7, 0x4B, 0x7C, 0x32, 0xF6, 0x42, 0x57, 0xB7, 0x08, 0x7F, 0x08, 0x17, 0x72, 0xA2, 0xBA, 0xD6, 0xA9, 0x42, 0xF3, 0x05, 0xE8, 0xF9, 0x53, 0x11, 0x39, 0x4F, 0xB6, 0xF1, 0x6E, 0xB9, 0x4B, 0x38, 0x20, 0xDA, 0x01, 0xA7, 0x56, 0xA3, 0x14, 0xE9, 0x8F, 0x40, 0x55, 0xF3, 0xD0, 0x07, 0xC6, 0xCB, 0x43, 0xA9, 0x94, 0xAD, 0xF7, 0x4C, 0x64, 0x86, 0x49, 0xF8, 0x0C, 0x83, 0xBD, 0x65, 0xE9, 0x17, 0xD4, 0xA1, 0xD3, 0x50, 0xF8, 0xF5, 0x59, 0x5F, 0xDC, 0x76, 0x52, 0x4F, 0x3D, 0x3D, 0x8D, 0xDB, 0xCE, 0x99, 0xE1, 0x57, 0x92, 0x59, 0xCD, 0xFD, 0xB8, 0xAE, 0x74, 0x4F, 0xC5, 0xFC, 0x76, 0xBC, 0x83, 0xC5, 0x47, 0x30, 0x61, 0xCE, 0x7C, 0xC9, 0x66, 0xFF, 0x15, 0xF9, 0xBB, 0xFD, 0x91, 0x5E, 0xC7, 0x01, 0xAA, 0xD3, 0x5B, 0x9E, 0x8D, 0xA0, 0xA5, 0x72, 0x3A, 0xD4, 0x1A, 0xF0, 0xBF, 0x46, 0x00, 0x58, 0x2B, 0xE5, 0xF4, 0x88, 0xFD, 0x58, 0x4E, 0x49, 0xDB, 0xCD, 0x20, 0xB4, 0x9D, 0xE4, 0x91, 0x07, 0x36, 0x6B, 0x33, 0x6C, 0x38, 0x0D, 0x45, 0x1D, 0x0F, 0x7C, 0x88, 0xB3, 0x1C, 0x7C, 0x5B, 0x2D, 0x8E, 0xF6, 0xF3, 0xC9, 0x23, 0xC0, 0x43, 0xF0, 0xA5, 0x5B, 0x18, 0x8D, 0x8E, 0xBB, 0x55, 0x8C, 0xB8, 0x5D, 0x38, 0xD3, 0x34, 0xFD, 0x7C, 0x17, 0x57, 0x43, 0xA3, 0x1D, 0x18, 0x6C, 0xDE, 0x33, 0x21, 0x2C, 0xB5, 0x2A, 0xFF, 0x3C, 0xE1, 0xB1, 0x29, 0x40, 0x18, 0x11, 0x8D, 0x7C, 0x84, 0xA7, 0x0A, 0x72, 0xD6, 0x86, 0xC4, 0x03, 0x19, 0xC8, 0x07, 0x29, 0x7A, 0xCA, 0x95, 0x0C, 0xD9, 0x96, 0x9F, 0xAB, 0xD0, 0x0A, 0x50, 0x9B, 0x02, 0x46, 0xD3, 0x08, 0x3D, 0x66, 0xA4, 0x5D, 0x41, 0x9F, 0x9C, 0x7C, 0xBD, 0x89, 0x4B, 0x22, 0x19, 0x26, 0xBA, 0xAB, 0xA2, 0x5E, 0xC3, 0x55, 0xEB, 0x3D, 0xD6, 0x17 }; The following section could use some editing. These primes are being proposed for IPsec, but I wanted to include documentation on the creation of the primes at this time, and said documentation already existed in the somewhat rough form below. ---------------------------- How PGPfone's DH Primes Were Derived This section written by Colin Plumb. PGPfone uses Diffie-Hellman key exchange to decide on a session key for communication. Diffie-Hellman requires a prime modulus to work with. (Note that this is unlike RSA, which uses a modulus which is the product of two primes.) This note explains how these primes are computed. "Kosherized" Primes The security of the Diffie-Hellman exponential key agreement depends on the difficulty of computing discrete logarithms. It has been suggested that it may be possible to contrive a prime modulus such that it is easier to compute discrete logs in that modulus’s field. This is one reason why some have suggested that rather than trust a prime generated by someone else, it is better to generate your own prime. This approach can lead to a massive proliferation of primes in use in a community of Diffie-Hellman users. But there are advantages in having everyone use a small common set of well-known public primes. It makes key management easier, and allows precomputation of the first phase of the Diffie-Hellman exchange, which speeds things up. The Diffie-Hellman primes used by PGPfone were derived in such a way that anyone may independently verify that the primes were not contrived to make it any easier to compute discrete logs. Thus, there is no reason why everyone can’t trust the prime numbers selected for PGPfone. We will describe here exactly how these primes were derived. The prime generation is a variant of the technique for DSS prime generation suggested by David Kravitz (of NSA, at that time) and recommended by NIST. It is based on SHA and an arbitrary seed. Kravitz calls this process "kosherizing the primes". SHA is the NIST standard Secure Hash Algorithm with a 160-bit output. It is widely believed in cryptographic circles that it is computationally infeasible to choose an input value for SHA that will produce some chosen output hash. We refer to the hash algorithm throughout this document as SHA, even though it is actually the NIST-revised SHA, known as SHA-1. Careful prime generation is significant to Diffie-Hellman because the security of Diffie-Hellman key exchange rests on the difficulty of the discrete log problem: given y, g and p, find x such that y = g^x mod p. This is, in general, very difficult. However, there are certain "cooked" primes p such that this is comparatively easy to solve. These "cooked" primes are very rare - given a random prime p, the chance that it is cooked is so small as to not be worth worrying about. So to choose a prime and be convinced that it is not cooked, it suffices to choose a prime from a given range in a manner that prevents anyone from forcing the choice to one of the rare "cooked" values. This is where SHA comes in. By using SHA to generate the primes, it is possible to show the impossibility of steering the prime-selection process to one of the rare "cooked" values, since it's not possible to steer the output of SHA. Since SHA generates 160-bit outputs, and we want larger primes (such as 2048 bits), we need to use SHA multiple times. The first invocation of SHA generates the low 160 bits of the number. The next invocation generates the next lowest 160 bits, and so on, until enough bits are available. For example, a number of up to 1024 bits can be generated as follows: ( SHA(seed1) + 2^160 * SHA(seed2) + 2^320 * SHA(seed3) + 2^480 * SHA(seed4) + 2^640 * SHA(seed6) + 2^800 * SHA(seed7) + 2^960 * SHA(seed8) ) mod 2^1024 The sum inside the parentheses generates a number 7*160 = 1120 bits long. The modulo operation throws away the extra 96 bits that aren't needed. The only thing needed here is 7 seed values. What the seed values are is unimportant, as long as they are published so that anyone may verify the fact that the number is generated by SHA. (The 20-byte SHA output is treated as a big-endian number for the purpose of these computations.) For PGPfone, the seed1 value is an ASCII string of a recognizable phrase. seed2 is created by incrementing the last byte of the phrase by 1. seed3 is created from seed2 by incrementing the byte again, et cetera. PGPfone uses 5 user-selectable primes derived from the seed, of different sizes: 512, 768, 1024, 1536, and 2048 bits. For the initial release of PGPfone, the seed phrase is an ASCII string containing a quote from Mahatma Gandhi: "Whatever you do will be insignificant, but it is very important that you do it." After the number is created, a few changes are made to it: - The most significant bit is set, to ensure that the number is really 1024 bits long (or however many bits are desired). - The second most significant bit is set to make the number larger. The effort of performing Diffie-Hellman computations depends almost exclusively on the number of significant bits in the number. There is no real difference between high 1024-bit numbers close to 2^1024-1 and low 1024-bit numbers close to 2^1023. The effort of solving the discrete log problem, however, depends more heavily on the value of the number, so picking primes from the high half of the 1024-bit range provides slightly better security at no cost. Then this number is used as a starting value for a sequential prime search. The first suitable prime greater than or equal to the starting number is the generated prime. "Suitable prime" is stronger than just "prime". For a prime p to be suitable, (p-1)/2 must also be prime. If this is true, then the generator g in the Diffie-Hellman computation can be chosen to be 2 without any loss of security. This choice speeds up computation with the prime, so as primes are generated rarely but used often, the extra effort taken to find a "suitable" prime is amply repaid. Comparison with Kravitz's technique David Kravitz originally designed his technique for generation of primes for the NIST Digital Signature Standard (DSS). DSS requires two primes, so seed1 and seed2 were used to generate the small prime, and the large prime was generated using seed3 and upwards. Since we only have one prime, we start with seed1. There was also a modular relationship required between the smaller and the larger prime, which Kravitz' technique enforced by decreasing the large prime to make the relationship hold. That does not apply to this operation and is omitted. The seed1, seed2, etc. generation using incrementing is exactly as in Kravitz's original design. Kravitz did not set the second highest bit. That is a simple modification to make things slightly more difficult for an attacker. The most significant difference is that Kravitz didn't generate a starting value and do a sequential search for a prime; his technique kept using more seed values to generate more random numbers, which were then tested for primality. His technique has some mathematical elegance advantages, in particular a sequential search produces some primes (those with a long gap between them and the previous suitable prime) more often than others (those which closely follow the previous suitable prime), but the change is quite minor, and definitely not significant for Diffie-Hellman primes. (Diffie-Hellman primes aren't secret, so it isn't important to pick as randomly as possible to make guessing difficult.) The advantage is that sequential numbers can be tested for primality much faster than random numbers. Prime generation is slow enough already; it doesn't need to be made any slower. Implementation details This section describes the implementation of the search, for those who wish to follow the supplied code and verify that it performs the operations described above. Generating the initial random number is straightforward enough. Searching for suitable primes, however, is the subject of a great deal of optimization. The prime search proceeds in two steps: sieving and testing. First note that we are looking for a prime p such that q = (p-1)/2 is prime. Thus, q must be odd and p must be congruent to 3 mod 4. Further, neither q nor p = 2*q+1 may be congruent to 0 modulo 3. The constraint on p means that q may not be congruent to 1 modulo 3, so q must be congruent to 2 modulo 3. Combining this with the fact that q must be odd implies that q must be congruent to 5 modulo 6. p must, therefore, be congruent to 11 modulo 12. The first step is to take the initial number s, find (s-1)/2, and round it up until it is congruent to 5 modulo 6. This number is n1. Searching for q proceeds in steps of 6 from this base. n2 = 2*n1+1 is the base for the search for p, which proceeds in steps of 12. To perform the sieving, a large bit array (65536 bits, or 8192 bytes) is allocated. Bit i of the array will be cleared if either of n1+6*i or n2+12*i have small divisors. The small divisor test is performed by initially setting the array to all ones, and then for each prime divisor d up to 65536 (since we are stepping by 6 = 2*3, 2 and 3 are excluded), n1 modulo d is computed, and the remainder used in a bit of computation to find the first index i such that n1+6*i is divisible by d. Then every dth bit from that point onwards in the array is cleared. Bits for which n2+12*i is divisible by d are cleared similarly. n2 modulo d can be computed from n1 modulo d, by doubling and adding 1, so the computation is very easy. After that, the bit array is walked through looking for set bits, which indicate possible primes q and p. At least, each candidate c1 has no small prime factors, and c2 = 2*c1+1 has no small prime factors. For each candidate pair, a Fermat test to the base 2 of c2 is performed. i.e. we check if 2^(c2-1) == 1 (mod c2). If not, a dot is printed and the next candidates are sought. If we reach the end of the array, the starting number n1 is increased by 6*65536 and the process repeats. The search never gives up. A slash (/) is printed when the bit array is exhausted like this. The exponentiation 2^x (mod m) is handled in specially optimized code that takes advantage of the simplifications allowed by using 2 as a base. If the first Fermat test is passed, a "+" or "-" is printed, depending on some slightly arcane mathematical property. (It's the sign of 2^c1 mod c2, which is +1 or -1 if the test is passed.) Then a second Fermat test is performed, this time on c1, to see if 2^(c1-1) == 1 (mod c1). If not, a dot is printed and the search resumes. If the second test is passed, we have found a suitable prime. An asterisk (*) is printed to indicate success. But since the primality tests have a (ridiculously low) chance of failing, some extra "confirmation" tests on both c1 and c2 are performed. An asterisk is printed after each of these is completed, too. Three confirmation tests are performed on each of c1 and c2, so a total of seven asterisks are printed. (In the case that a confirmation test fails, a dot is printed and the search is resumed, but this is not going to happen in your lifetime.) At the end of this, c2 is the suitable prime p that is sought. --------------------- The above section was written by Colin Plumb. -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. Direct (408)346-5906 Cell/VM (650)533-0399 From owner-ipsec@lists.tislabs.com Sun Feb 6 13:23: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 NAA01114; Sun, 6 Feb 2000 13:23:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25304 Sun, 6 Feb 2000 14:47:23 -0500 (EST) Date: Sun, 6 Feb 2000 21:52:29 +0200 (EET) Message-Id: <200002061952.VAA22875@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: wprice@cyphers.net Cc: ipsec@lists.tislabs.com Subject: Proposal for new DH Groups 6, 7, and 8 In-Reply-To: <389BC1A4.907A2FF8@cyphers.net> References: <389BC1A4.907A2FF8@cyphers.net> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 22 min X-Total-Time: 157 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Will Price writes: > I would like to propose three new DH Groups for IKE of 2048, 3072, and > 4096 bits. This should adequately cover all foreseeable future needs. I > have included documentation on the generation of these primes which were > originally generated for PGPfone, and there is an interesting story about > how they were generated at the end of this message. I think those primes should be generated in the same way the primes currently in the IKE are generated, i.e to have format of p = 2^n - 2^(n-64) - 1 + (floor(Pi*2^(n-130)) + t)*2^64, Also the primes must be verified to be really primes. Statistical methods are not enough (I think PGPfone only does statistical tests). 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 > ---------------------------------------------------------------------- All those primes have been verified to really be primes using ECPP program by Morain. At the end there are the primes on the same format that is used in the IKE rfc. To get more information about how these (and the the groups in the IKE rfc) are generated read RFC 2412 Appendix E. These primes are generated by me and Mika Kojo. ---------------------------------------------------------------------- 2048 bits: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 } FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF The generator is 2 (decimal) ---------------------------------------------------------------------- 3072 bits: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] + 1690314 } FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF The generator is 2 (decimal) ---------------------------------------------------------------------- 4096 bits: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] + 240904 } FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199 FFFFFFFF FFFFFFFF The generator is 2 (decimal) -- 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 Sun Feb 6 16:02: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 QAA02806; Sun, 6 Feb 2000 16:02:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25948 Sun, 6 Feb 2000 17:32:32 -0500 (EST) Message-Id: <4.2.1.20000206143613.00c54780@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Sun, 06 Feb 2000 14:37:51 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: Proposal for new DH Groups 6, 7, and 8 In-Reply-To: <389BC1A4.907A2FF8@cyphers.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:22 PM 2/4/00 -0800, Will Price wrote: >There was much discussion at the recent bakeoff regarding DH prime >lengths. It was good to see that a number of people were implementing >Group 5, and all but one vendor that I found anyway (who actually changed >this during the bakeoff I believe) was doing at least Group 2. You were lucky, then. Of the 41 companies who said they did certificates, only 15 said they did group 5. This is not to say that we don't need bigger DH groups, just that we shouldn't be smug about our current state of affairs. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Feb 7 02:19: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 CAA18522; Mon, 7 Feb 2000 02:19:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA27409 Mon, 7 Feb 2000 04:04:01 -0500 (EST) Message-ID: <389E8BB8.CDCC3FC1@cyphers.net> Date: Mon, 07 Feb 2000 01:09:11 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Paul Hoffman CC: ipsec@lists.tislabs.com Subject: Re: Proposal for new DH Groups 6, 7, and 8 References: <4.2.1.20000206143613.00c54780@mail.vpnc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman wrote: > > At 10:22 PM 2/4/00 -0800, Will Price wrote: > >There was much discussion at the recent bakeoff regarding DH prime > >lengths. It was good to see that a number of people were implementing > >Group 5, and all but one vendor that I found anyway (who actually changed > >this during the bakeoff I believe) was doing at least Group 2. > > You were lucky, then. Of the 41 companies who said they did certificates, > only 15 said they did group 5. 15 is "a number". It's certainly a lot more than were doing Group 5 at the May bakeoff. > This is not to say that we don't need bigger DH groups, just that we > shouldn't be smug about our current state of affairs. I'm trying to be on the glass is half full side of things to help encourage others to move up. Quite frankly, if it were not for compatibility reasons we would have removed all primes below 1536 bits awhile ago for security reasons (we would never release a product with group 1 of course, that was just too weak). Thus in anticipation of the happy day when we feel comfortable removing group 2, it's high time to get some larger primes agreed upon. -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. Direct (408)346-5906 Cell/VM (650)533-0399 From owner-ipsec@lists.tislabs.com Mon Feb 7 02:21: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 CAA18633; Mon, 7 Feb 2000 02:21:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA27377 Mon, 7 Feb 2000 03:55:47 -0500 (EST) Message-ID: <389E89C2.8670133F@cyphers.net> Date: Mon, 07 Feb 2000 01:00:49 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Tero Kivinen CC: ipsec@lists.tislabs.com Subject: Re: Proposal for new DH Groups 6, 7, and 8 References: <389BC1A4.907A2FF8@cyphers.net> <200002061952.VAA22875@torni.ssh.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sounds fine to me. I'm far more concerned with reaching agreement on larger primes and getting ID numbers assigned than in which primes get used. It was also pointed out off the list that there is an existing draft for 6, 7, 8, and 9 in the EC space. Thus, these DH primes should be 10, 11, and 12. So, let's move this forward. Do you want to write those primes up as a draft or can Dan include them in the next IKE-01 draft? Tero Kivinen wrote: > > Will Price writes: > > I would like to propose three new DH Groups for IKE of 2048, 3072, and > > 4096 bits. This should adequately cover all foreseeable future needs. I > > have included documentation on the generation of these primes which were > > originally generated for PGPfone, and there is an interesting story about > > how they were generated at the end of this message. > > I think those primes should be generated in the same way the primes > currently in the IKE are generated, i.e to have format of > [... alternate primes...] -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. Direct (408)346-5906 Cell/VM (650)533-0399 From owner-ipsec@lists.tislabs.com Mon Feb 7 06:57: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 GAA27155; Mon, 7 Feb 2000 06:57:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28304 Mon, 7 Feb 2000 08:36:03 -0500 (EST) Message-Id: <3.0.3.32.20000207104930.00a9f100@pop.datafellows.com> X-Sender: alexey@pop.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 07 Feb 2000 10:49:30 +0200 To: Tero Kivinen From: Alexey Kirichenko Subject: Re: Proposal for new DH Groups 6, 7, and 8 Cc: ipsec@lists.tislabs.com In-Reply-To: <200002061952.VAA22875@torni.ssh.fi> References: <389BC1A4.907A2FF8@cyphers.net> <389BC1A4.907A2FF8@cyphers.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 21:52 6.2.2000 +0200, Tero Kivinen wrote: >Will Price writes: >> I would like to propose three new DH Groups for IKE of 2048, 3072, and >> 4096 bits. This should adequately cover all foreseeable future needs. I >> have included documentation on the generation of these primes which were >> originally generated for PGPfone, and there is an interesting story about >> how they were generated at the end of this message. > >I think those primes should be generated in the same way the primes >currently in the IKE are generated, i.e to have format of > >p = 2^n - 2^(n-64) - 1 + (floor(Pi*2^(n-130)) + t)*2^64, What's so great about this format ? I'd love (but would be very surprised) to see any proofs/arguments of useful properties of primes generated in the specified way. References ? >Also the primes must be verified to be really primes. Statistical >methods are not enough (I think PGPfone only does statistical tests). True. As we have plenty of time for primality testing in this particular case, there is no reason for skipping EC-based primality testing. Alexey ------------- End Forwarded Message ------------- From owner-ipsec@lists.tislabs.com Mon Feb 7 06:59: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 GAA27219; Mon, 7 Feb 2000 06:59:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28313 Mon, 7 Feb 2000 08:37:03 -0500 (EST) Date: Sun, 06 Feb 2000 21:30:22 -0600 (MDT) From: sl531@cc.usu.edu Subject: draft-ietf-mobileip-ipv6-09 In-reply-to: <17191.932383872@coconut.itojun.org> To: itojun@iijlab.net Cc: Aaron Griggs , MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I know very little about IPv6 mobility and security issues so correct me if am wrong. Please UNICAST me your expert advice. 1> Draft mention that while transmitting packet if corresponding node's Binding cache has valid care_of_address entry for mobile node's home address then it replaces later by former and append routing header with later as last hop. Do the firewall entertain source routing ?? 2> Also encapsulated packets from home agent can invade foreign network's firewall. Is that acceptable ?? 3> While registering primary care_of_address with its home agent mobile node sends either an AH [9] or ESP [10] header providing sender authentication, data integrity protection, and replay protection, via Foreign Agent. Isn't that surrendering your secured data to foreign n/w ?? Thanks. Rajeeb Mishra From owner-ipsec@lists.tislabs.com Mon Feb 7 08:11: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 IAA28859; Mon, 7 Feb 2000 08:11:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28667 Mon, 7 Feb 2000 09:59:25 -0500 (EST) Date: Mon, 7 Feb 2000 17:04:36 +0200 (EET) Message-Id: <200002071504.RAA19305@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: wprice@cyphers.net Cc: ipsec@lists.tislabs.com Subject: Re: Proposal for new DH Groups 6, 7, and 8 In-Reply-To: <389E89C2.8670133F@cyphers.net> References: <389BC1A4.907A2FF8@cyphers.net> <200002061952.VAA22875@torni.ssh.fi> <389E89C2.8670133F@cyphers.net> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Will Price writes: > So, let's move this forward. Do you want to write those primes up as a > draft or can Dan include them in the next IKE-01 draft? I already sent the 2048 bit prime to Dan earlier (few months ago), but I don't know if he is going to include it to the IKE 01 draft. I think it would be better to keep all those primes together, i.e include them to the IKE draft. I can also make it separate draft if we cannot put them in to the IKE draft. -- 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 Feb 7 08:20: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 IAA29073; Mon, 7 Feb 2000 08:20:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28594 Mon, 7 Feb 2000 09:47:43 -0500 (EST) Message-ID: <389EDCC7.EB87E27F@certicom.com> Date: Mon, 07 Feb 2000 09:55:04 -0500 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Proposal for new DH Groups 6, 7, and 8 References: <17D0C5D3BC26E4A08525687E0034EE2D.0034EDEB8525687E@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Will Price wrote: > Sounds fine to me. I'm far more concerned with reaching agreement on > larger primes and getting ID numbers assigned than in which primes get > used. > > It was also pointed out off the list that there is an existing draft for > 6, 7, 8, and 9 in the EC space. Thus, these DH primes should be 10, 11, > and 12. > > So, let's move this forward. Do you want to write those primes up as a > draft or can Dan include them in the next IKE-01 draft? > > Tero Kivinen wrote: > > > > Will Price writes: > > > I would like to propose three new DH Groups for IKE of 2048, 3072, and > > > 4096 bits. This should adequately cover all foreseeable future needs. > I > > > have included documentation on the generation of these primes which > were > > > originally generated for PGPfone, and there is an interesting story > about > > > how they were generated at the end of this message. > > > > I think those primes should be generated in the same way the primes > > currently in the IKE are generated, i.e to have format of > > [... alternate primes...] > > -- > > Will Price, Director of Engineering > PGP Security, Inc. > a division of Network Associates, Inc. > Direct (408)346-5906 > Cell/VM (650)533-0399 Hi, Yes, there is an existing draft for EC groups labed #6, 7, 8, 9 - draft-ietf-ipsec-ike-ecc-groups-01.txt Dan, the above draft has been available for a while, and if there are no comments, we should proceed to publishing it as an RFC, or include the groups (along with the new proposed DH groups) in the next IKE draft. What does everyone else think? Thanks, Yuri Poeluev Certicom Corp. From owner-ipsec@lists.tislabs.com Mon Feb 7 08:24: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 IAA29208; Mon, 7 Feb 2000 08:24:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28650 Mon, 7 Feb 2000 09:57:38 -0500 (EST) Date: Mon, 7 Feb 2000 17:02:49 +0200 (EET) Message-Id: <200002071502.RAA25044@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Alexey Kirichenko Cc: ipsec@lists.tislabs.com Subject: Re: Proposal for new DH Groups 6, 7, and 8 In-Reply-To: <3.0.3.32.20000207104930.00a9f100@pop.datafellows.com> References: <389BC1A4.907A2FF8@cyphers.net> <200002061952.VAA22875@torni.ssh.fi> <3.0.3.32.20000207104930.00a9f100@pop.datafellows.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 0 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alexey Kirichenko writes: > At 21:52 6.2.2000 +0200, Tero Kivinen wrote: > >I think those primes should be generated in the same way the primes > >currently in the IKE are generated, i.e to have format of > > > >p = 2^n - 2^(n-64) - 1 + (floor(Pi*2^(n-130)) + t)*2^64, > > What's so great about this format ? I'd love (but would be very > surprised) to see any proofs/arguments of useful properties > of primes generated in the specified way. References ? The reason for that format is explained in the RFC 2412 Appendix E as I said in my previous email. Here is cut & paste of the relevant parts: ---------------------------------------------------------------------- Network Working Group H. Orman Request for Comments: 2412 Department of Computer Science Category: Informational University of Arizona November 1998 The OAKLEY Key Determination Protocol ... APPENDIX E The Well-Known Groups The group identifiers: 0 No group (used as a placeholder and for non-DH exchanges) 1 A modular exponentiation group with a 768 bit modulus 2 A modular exponentiation group with a 1024 bit modulus 3 A modular exponentiation group with a 1536 bit modulus (TBD) 4 An elliptic curve group over GF[2^155] 5 An elliptic curve group over GF[2^185] values 2^31 and higher are used for private group identifiers Richard Schroeppel performed all the mathematical and computational work for this appendix. Classical Diffie-Hellman Modular Exponentiation Groups The primes for groups 1 and 2 were selected to have certain properties. The high order 64 bits are forced to 1. This helps the classical remainder algorithm, because the trial quotient digit can always be taken as the high order word of the dividend, possibly +1. The low order 64 bits are forced to 1. This helps the Montgomery- style remainder algorithms, because the multiplier digit can always be taken to be the low order word of the dividend. The middle bits are taken from the binary expansion of pi. This guarantees that they are effectively random, while avoiding any suspicion that the primes have secretly been selected to be weak. Because both primes are based on pi, there is a large section of overlap in the hexadecimal representations of the two primes. The primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also prime), to have the maximum strength against the square-root attack on the discrete logarithm problem. The starting trial numbers were repeatedly incremented by 2^64 until suitable primes were located. Because these two primes are congruent to 7 (mod 8), 2 is a quadratic residue of each prime. All powers of 2 will also be quadratic residues. This prevents an opponent from learning the low order bit of the Diffie-Hellman exponent (AKA the subgroup confinement problem). Using 2 as a generator is efficient for some modular exponentiation algorithms. [Note that 2 is technically not a generator in the number theory sense, because it omits half of the possible residues mod P. From a cryptographic viewpoint, this is a virtue.] ... -- 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 Feb 7 09:03: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 JAA00235; Mon, 7 Feb 2000 09:03:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28914 Mon, 7 Feb 2000 10:54:56 -0500 (EST) Message-Id: <3.0.6.32.20000207075951.03a2e100@216.240.42.209> X-Sender: rodney@216.240.42.209 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 07 Feb 2000 07:59:51 -0800 To: Yuri Poeluev , ipsec@lists.tislabs.com From: Rodney Thayer Subject: Re: Proposal for new DH Groups 6, 7, and 8 Cc: kojo@ssh.fi In-Reply-To: <389EDCC7.EB87E27F@certicom.com> References: <17D0C5D3BC26E4A08525687E0034EE2D.0034EDEB8525687E@certicom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since there are, apparently, no known EC-based working implementations of IPsec, maybe we should make sure the folks who are thinking about this have some implementation experience. I would assume this means the usual suspects, like Certicom and SSH, could be asked how this stuff is working out. Throwing more magic numbers into a document set that's been discussed as too complex seems debatable, at least without feedback from implementors. Who out there has investigated EC with IPsec (and can talk about it?) I said 'investigated', not 'shipped' -- I realize this is essentially a research topic at this point. At 09:55 AM 2/7/00 -0500, Yuri Poeluev wrote: >Will Price wrote: > >> Sounds fine to me. I'm far more concerned with reaching agreement on >> larger primes and getting ID numbers assigned than in which primes get >> used. >> >> It was also pointed out off the list that there is an existing draft for >> 6, 7, 8, and 9 in the EC space. Thus, these DH primes should be 10, 11, >> and 12. >> >> So, let's move this forward. Do you want to write those primes up as a >> draft or can Dan include them in the next IKE-01 draft? >> >> Tero Kivinen wrote: >> > >> > Will Price writes: >> > > I would like to propose three new DH Groups for IKE of 2048, 3072, and >> > > 4096 bits. This should adequately cover all foreseeable future needs. >> I >> > > have included documentation on the generation of these primes which >> were >> > > originally generated for PGPfone, and there is an interesting story >> about >> > > how they were generated at the end of this message. >> > >> > I think those primes should be generated in the same way the primes >> > currently in the IKE are generated, i.e to have format of >> > [... alternate primes...] >> >> -- >> >> Will Price, Director of Engineering >> PGP Security, Inc. >> a division of Network Associates, Inc. >> Direct (408)346-5906 >> Cell/VM (650)533-0399 > >Hi, > >Yes, there is an existing draft for EC groups labed #6, 7, 8, 9 - draft-ietf-ipsec-ike-ecc-groups-01.txt >Dan, the above draft has been available for a while, and if there are no comments, >we should proceed to publishing it as an RFC, or include the groups >(along with the new proposed DH groups) in the next IKE draft. >What does everyone else think? > >Thanks, >Yuri Poeluev >Certicom Corp. > From owner-ipsec@lists.tislabs.com Mon Feb 7 09:03: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 JAA00258; Mon, 7 Feb 2000 09:03:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28892 Mon, 7 Feb 2000 10:52:46 -0500 (EST) Message-ID: <01E1D01C12D7D211AFC70090273D20B102A1CC04@sothmxs06.entrust.com> From: Greg Carter To: ipsec@lists.tislabs.com Subject: RE: Commit Bit and SPI? Date: Mon, 7 Feb 2000 10:57:26 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Add one 'vote' for - reply with one Notify only. SPIs not required, if there don't fail, support people who already put them there but processing is not required. - to keep things simple, reflect commit bit. No optional reflecting and what that might mean. Bye. Greg Carter Entrust Technologies - http://www.entrust.com http://www.ford-trucks.com/articles/buildup/dana60.html -----Original Message----- From: Dan Harkins [mailto:dharkins@network-alchemy.com] Sent: Friday, February 04, 2000 1:13 PM To: Will Fiveash Cc: ipsec@lists.tislabs.com Subject: Re: Commit Bit and SPI? Will, Something has to be said to clear this up, yes. But it's a decision of the WG. Do we send a notify for each SA pair containing the responder's SPI(s) or do we send a single notify with no SPIs? Can we not reflect the commit bit and if so what does that mean? Who can set the commit bit and where should that be allowed and prohibited? If we can get some consensus on this matter it'll go in the document but a unilateral decision by me will only result in conflict. From owner-ipsec@lists.tislabs.com Mon Feb 7 11:19: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 LAA03334; Mon, 7 Feb 2000 11:19:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29353 Mon, 7 Feb 2000 12:35:18 -0500 (EST) Message-ID: <01E1D01C12D7D211AFC70090273D20B102D4B4A8@sothmxs06.entrust.com> From: Joe MacLellan To: wprice@cyphers.net, Tero Kivinen Cc: ipsec mailling list Subject: RE: Proposal for new DH Groups 6, 7, and 8 Date: Mon, 7 Feb 2000 12:39:58 -0500 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 The DH well-known primes are listed in Appendix E of RFC 2412 (Oakley), not RFC 2409 (IKE). I don't think they should be going to Dan to include in the IKE doc, they should be added to 2412 with the rest. That is, once people have agreed as to what group numbers they will be assigned. :-) :Later -Joe Entrust Technologies "We Bring Trust to e-Business"(tm) Entrust Toolkit Development Phone:(613) 248-3208 Fax: (613) 247-3450 Email: joe.maclellan@entrust.com http://www.entrust.com Register now for Entrust SecureSummit 2000 http://www.securesummit.com May 1-4, 2000, Hyatt Regency at Reunion, Dallas, TX > ---------- > From: Tero Kivinen[SMTP:kivinen@ssh.fi] > Sent: Monday, February 07, 2000 10:04 AM > To: wprice@cyphers.net > Cc: ipsec@lists.tislabs.com > Subject: Re: Proposal for new DH Groups 6, 7, and 8 > > Will Price writes: > > So, let's move this forward. Do you want to write those primes up as a > > draft or can Dan include them in the next IKE-01 draft? > > I already sent the 2048 bit prime to Dan earlier (few months ago), but > I don't know if he is going to include it to the IKE 01 draft. I think > it would be better to keep all those primes together, i.e include them > to the IKE draft. I can also make it separate draft if we cannot put > them in to the IKE draft. > -- > 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 Feb 7 11:42: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 LAA03766; Mon, 7 Feb 2000 11:42:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29525 Mon, 7 Feb 2000 13:16:55 -0500 (EST) Message-Id: <4.2.1.20000207101935.00b3a480@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 07 Feb 2000 10:22:30 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: Proposal for new DH Groups 6, 7, and 8 In-Reply-To: <389EDCC7.EB87E27F@certicom.com> References: <17D0C5D3BC26E4A08525687E0034EE2D.0034EDEB8525687E@certicom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:55 AM 2/7/00 -0500, Yuri Poeluev wrote: >Yes, there is an existing draft for EC groups labed #6, 7, 8, 9 - >draft-ietf-ipsec-ike-ecc-groups-01.txt >Dan, the above draft has been available for a while, and if there are no >comments, >we should proceed to publishing it as an RFC, or include the groups >(along with the new proposed DH groups) in the next IKE draft. >What does everyone else think? We should be careful. When additional non-EC groups are proposed, many people from many different companies will probably bang on them (and hopefully report results, even if it is 'yup, that seemed fine'). When EC groups are proposed, the silence that is heard may be due to the fact that only one or two companies are working on them. Let's only standardize groups that have been tested by many people this WG trusts. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Feb 7 11:44: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 LAA03849; Mon, 7 Feb 2000 11:44:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29587 Mon, 7 Feb 2000 13:24:28 -0500 (EST) Date: Mon, 7 Feb 2000 13:29:37 -0500 Message-Id: <200002071829.NAA09213@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Joseph.Maclellan@entrust.com Cc: ipsec@lists.tislabs.com Subject: RE: Proposal for new DH Groups 6, 7, and 8 References: <01E1D01C12D7D211AFC70090273D20B102D4B4A8@sothmxs06.entrust.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Joe" == Joe MacLellan writes: Joe> The DH well-known primes are listed in Appendix E of RFC 2412 Joe> (Oakley), not RFC 2409 (IKE). I don't think they should be Joe> going to Dan to include in the IKE doc, they should be added to Joe> 2412 with the rest. That seems odd, because 2412 is "Informational". Things that affect how a protocol works or how it interoperates should be in standards track specs, I would think. I suppose the notion of a protocol spec (which 2412 seems to be) marked "informational" is a bit odd in general. paul From owner-ipsec@lists.tislabs.com Mon Feb 7 12:07: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 MAA04417; Mon, 7 Feb 2000 12:07:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29826 Mon, 7 Feb 2000 13:48:10 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B788F3A@md-exchange1.nai.com> From: "Mason, David" To: "'Tero Kivinen'" , Alexey Kirichenko Cc: ipsec@lists.tislabs.com Subject: RE: Proposal for new DH Groups 6, 7, and 8 Date: Mon, 7 Feb 2000 10:49:35 -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 Because of the likely increased use of processors with a larger word size, it might be a good idea to make the low/high order 128 bits (instead of 64 bits) forced to 1's on the new larger MODP DH groups. -dave -----Original Message----- From: Tero Kivinen [mailto:kivinen@ssh.fi] Sent: Monday, February 07, 2000 10:03 AM To: Alexey Kirichenko Cc: ipsec@lists.tislabs.com Subject: Re: Proposal for new DH Groups 6, 7, and 8 Alexey Kirichenko writes: > At 21:52 6.2.2000 +0200, Tero Kivinen wrote: > >I think those primes should be generated in the same way the primes > >currently in the IKE are generated, i.e to have format of > > > >p = 2^n - 2^(n-64) - 1 + (floor(Pi*2^(n-130)) + t)*2^64, > > What's so great about this format ? I'd love (but would be very > surprised) to see any proofs/arguments of useful properties > of primes generated in the specified way. References ? The reason for that format is explained in the RFC 2412 Appendix E as I said in my previous email. Here is cut & paste of the relevant parts: ---------------------------------------------------------------------- Network Working Group H. Orman Request for Comments: 2412 Department of Computer Science Category: Informational University of Arizona November 1998 The OAKLEY Key Determination Protocol ... APPENDIX E The Well-Known Groups The group identifiers: 0 No group (used as a placeholder and for non-DH exchanges) 1 A modular exponentiation group with a 768 bit modulus 2 A modular exponentiation group with a 1024 bit modulus 3 A modular exponentiation group with a 1536 bit modulus (TBD) 4 An elliptic curve group over GF[2^155] 5 An elliptic curve group over GF[2^185] values 2^31 and higher are used for private group identifiers Richard Schroeppel performed all the mathematical and computational work for this appendix. Classical Diffie-Hellman Modular Exponentiation Groups The primes for groups 1 and 2 were selected to have certain properties. The high order 64 bits are forced to 1. This helps the classical remainder algorithm, because the trial quotient digit can always be taken as the high order word of the dividend, possibly +1. The low order 64 bits are forced to 1. This helps the Montgomery- style remainder algorithms, because the multiplier digit can always be taken to be the low order word of the dividend. The middle bits are taken from the binary expansion of pi. This guarantees that they are effectively random, while avoiding any suspicion that the primes have secretly been selected to be weak. Because both primes are based on pi, there is a large section of overlap in the hexadecimal representations of the two primes. The primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also prime), to have the maximum strength against the square-root attack on the discrete logarithm problem. The starting trial numbers were repeatedly incremented by 2^64 until suitable primes were located. Because these two primes are congruent to 7 (mod 8), 2 is a quadratic residue of each prime. All powers of 2 will also be quadratic residues. This prevents an opponent from learning the low order bit of the Diffie-Hellman exponent (AKA the subgroup confinement problem). Using 2 as a generator is efficient for some modular exponentiation algorithms. [Note that 2 is technically not a generator in the number theory sense, because it omits half of the possible residues mod P. From a cryptographic viewpoint, this is a virtue.] ... -- 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 Feb 7 12:23: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 MAA04767; Mon, 7 Feb 2000 12:23:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29456 Mon, 7 Feb 2000 13:09:18 -0500 (EST) Message-Id: <200002071812.KAA18487@potassium.network-alchemy.com> To: Yuri Poeluev cc: ipsec@lists.tislabs.com Subject: Re: Proposal for new DH Groups 6, 7, and 8 In-reply-to: Your message of "Mon, 07 Feb 2000 09:55:04 EST." <389EDCC7.EB87E27F@certicom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18484.949947126.1@network-alchemy.com> Date: Mon, 07 Feb 2000 10:12:06 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk RFC2409 instructs IANA to assign new numbers to new groups if a standards-track or Informational RFC exists. So drafts shouldn't just claim parts of a numberspace that is reserved to IANA (i.e. groups 6-9). This is from section 11.4 of RFC2409: Values of the Group Description Class identify a group to use in a Diffie-Hellman exchange. Values of the Group Type Class define the type of group. Requests for assignment of new groups must be accompanied by a reference to a standards-track or Informational RFC which describes this group. Requests for assignment of new group types must be accompanied by a reference to a standards-track or Informational RFC or by a reference to published cryptographic or mathmatical literature which describes the new type. Also, section 4 of draft-ietf-ipsec-ike-ecc-groups-01.txt is troubling, at least for me. Why can't you define safe curves which don't require buying a license from Certicom? Or at least do what Entrust did with their PKIX patent (provide a world-wide, royalty-free license)? Dan. On Mon, 07 Feb 2000 09:55:04 EST you wrote > > Yes, there is an existing draft for EC groups labed #6, 7, 8, 9 - draft-ietf- >ipsec-ike-ecc-groups-01.txt > Dan, the above draft has been available for a while, and if there are no comm >ents, > we should proceed to publishing it as an RFC, or include the groups > (along with the new proposed DH groups) in the next IKE draft. > What does everyone else think? > > Thanks, > Yuri Poeluev > Certicom Corp. > From owner-ipsec@lists.tislabs.com Mon Feb 7 13:43: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 NAA06615; Mon, 7 Feb 2000 13:43:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00255 Mon, 7 Feb 2000 15:20:34 -0500 (EST) Message-ID: <01E1D01C12D7D211AFC70090273D20B102D4B4F2@sothmxs06.entrust.com> From: Joe MacLellan To: Joe MacLellan , Paul Koning Cc: ipsec mailling list Subject: RE: Proposal for new DH Groups 6, 7, and 8 Date: Mon, 7 Feb 2000 15:25:11 -0500 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 Doh! My mistake. When I was looking for Group 5 I found it was not listed in IKE, only groups 1-4 are at least in the "Big book of IPSec RFCs", I found that in 2412. Sorry about that. > ---------- > From: Paul Koning[SMTP:pkoning@xedia.com] > Sent: Monday, February 07, 2000 1:29 PM > To: Joseph.Maclellan@entrust.com > Cc: ipsec@lists.tislabs.com > Subject: RE: Proposal for new DH Groups 6, 7, and 8 > > >>>>> "Joe" == Joe MacLellan writes: > > Joe> The DH well-known primes are listed in Appendix E of RFC 2412 > Joe> (Oakley), not RFC 2409 (IKE). I don't think they should be > Joe> going to Dan to include in the IKE doc, they should be added to > Joe> 2412 with the rest. > > That seems odd, because 2412 is "Informational". Things that affect > how a protocol works or how it interoperates should be in standards > track specs, I would think. > > I suppose the notion of a protocol spec (which 2412 seems to be) > marked "informational" is a bit odd in general. > > paul > From owner-ipsec@lists.tislabs.com Mon Feb 7 16:42: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 QAA10407; Mon, 7 Feb 2000 16:42:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00718 Mon, 7 Feb 2000 18:03:59 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "John Harleman" To: Dan Harkins cc: ipsec@lists.tislabs.com, "Simon Blake-Wilson" , "Prakash Panjwani" , "Yuri Poeluev" Message-ID: <8525687E.007EC027.00@domino2.certicom.com> Date: Mon, 7 Feb 2000 15:07:46 -0800 Subject: Re: Proposal for new DH Groups 6, 7, and 8 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Dan: >Also, section 4 of draft-ietf-ipsec-ike-ecc-groups-01.txt is troubling, at >least for me. Why can't you define safe curves which don't require buying >a license from Certicom? Or at least do what Entrust did with their PKIX >patent (provide a world-wide, royalty-free license)? To the best of my knowledge Certicom has stated many times that we do not have IP with regards to specific curves, but to implementation techniques. So as I understand it, regardless of what type of curve you implement, you are no more or less likely to infringe on our IP. That said, doesn't it make sense to not use vulnerable curves that NIST has identified as suspect and if so, why not use the NIST ones? Certicom simply does not want to be put in the situation of having to ship breakable crypto. FYI, I am aware of at least two vendors who have implemented the NIST curves and others who are examing them. Cheers - John From owner-ipsec@lists.tislabs.com Tue Feb 8 05:13: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 FAA07083; Tue, 8 Feb 2000 05:13:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA02909 Tue, 8 Feb 2000 06:36:21 -0500 (EST) Message-Id: <200002081131.GAA13567@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ippcp@external.cisco.com, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shacham-ippcp-rfc2393bis-04.txt Date: Tue, 08 Feb 2000 06:31:35 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Payload Compression Protocol (IPComp) Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas Filename : draft-shacham-ippcp-rfc2393bis-04.txt Pages : 10 Date : 07-Feb-00 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-04.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-shacham-ippcp-rfc2393bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000207125534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-shacham-ippcp-rfc2393bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125534.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Feb 8 06:09: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 GAA08077; Tue, 8 Feb 2000 06:09:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03196 Tue, 8 Feb 2000 07:48:42 -0500 (EST) Date: Tue, 8 Feb 2000 04:53:22 -0800 (PST) From: Abraham Shacham To: ippcp@external.cisco.com cc: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-shacham-ippcp-rfc2393bis-04.txt In-Reply-To: <200002081131.GAA13567@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The draft reflects the discussions in the VPN bakeoff in San Diego last month. The content changes are in section 4.1. Use of IKE, as the attached diff provides. avram 347,370c347,356 < Identifiers. < < The following attributes are applicable to IPComp proposals: < < Encapsulation Mode < < To suggest a non-default Encapsulation Mode (such as Tunnel < Mode), an IPComp proposal MUST include an Encapsulation Mode < attribute. If the Encapsulation Mode is unspecified, the < default value of Transport Mode is assumed. < < Lifetime < < An IPComp proposal uses the Life Duration and Life Type < attributes to suggest life duration to the IPCA. < < When IPComp is negotiated as part of a Protection Suite, all the < logically related offers must be consistent. However, an IPComp < proposal SHOULD NOT include attributes that are not applicable to < IPComp. An IPComp proposal MUST NOT be rejected because it does not < include attributes of other protocols in the Protection Suite that < are not relevant to IPComp. When an IPComp proposal includes such < attributes, those attributes MUST be ignored when setting the IPCA, < and therefore ignored in the operation of IPComp. --- > Identifiers. To suggest a non-default Encapsulation Mode (such as > Tunnel Mode), an IPComp proposal MUST include an Encapsulation Mode > attribute. If the Encapsulation Mode is unspecified, the default > value of Transport Mode is assumed. When IPComp is negotiated as > part of a Protection Suite, and when the negotiation protocol > requires that all the logically related offers must be consistent, > the IPComp proposals MUST include all the attributes of every > transform being negotiated, but those attributes not relevant to > IPComp MUST be ignored when setting the IPCA and therefore ignored in > the operation of IPComp. On Tue, 8 Feb 2000 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IP Payload Compression Protocol (IPComp) > Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas > Filename : draft-shacham-ippcp-rfc2393bis-04.txt > Pages : 10 > Date : 07-Feb-00 > From owner-ipsec@lists.tislabs.com Tue Feb 8 07:45: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 HAA10305; Tue, 8 Feb 2000 07:45:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03524 Tue, 8 Feb 2000 09:13:59 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF01171CF5@exchange> From: Tim Jenkins To: ipsec@lists.tislabs.com Subject: Latest Re-keying Draft Date: Tue, 8 Feb 2000 09:19:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk All, The latest version of the re-keying document was submitted in early January. I didn't see a posting from Internet-Drafts@ietf.org, so I'm posting a reminder now. It's available at . I have received only a couple comments privately. If there are more, I'd like to get them soon, as I want to get this finished up as an informational RFC soon. The major change with this version is the removal of the "continuous channel" model for phase 1 SAs. (Some discussion on over-lapping phase 1 SAs remains, however.) Thanks in advance, Tim --- Tim Jenkins Newbridge Networks Corporation tjenkins@timestep.com http://www.timestep.com timj@newbridge.com http://www.newbridge.com (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec@lists.tislabs.com Tue Feb 8 08:00: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 IAA10734; Tue, 8 Feb 2000 08:00:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03729 Tue, 8 Feb 2000 09:46:01 -0500 (EST) Message-ID: <38A02DE9.C9B8170@certicom.com> Date: Tue, 08 Feb 2000 09:53:30 -0500 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Proposal for new DH Groups 6, 7, and 8 References: <77947CF8767F79F28525687E006908CB.00693C6C8525687E@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I agree with Paul that RFC 2412 isn't the most appropriate place for the new groups. A developer shouldn't use RFC 2412 as a base, but rather RFC2409 (IKE). I think the IKE document must cover all "well-known" groups for Phase 1 and Phase 2. All other groups must fall into the new group mode. However, "well-known" groups must have reasonable security level. We have to let a developer decide which groups to use in Phase 1. Many implementations might not have PFS, so they will not perform KE in Phase 2, in this case they will be forced to use only groups defined in IKE. Then, we'd better provide more flexibility for Phase 1 by including more groups into RFC2409 (IKE), such as recently proposed new ECDH and DH groups. Because the existing RFC2409(IKE) EC curves have questionable security level and not aligned with the other standards such as ANSI and NIST, we have proposed new EC curves. Groups 6-9 proposed in draft-ietf-ipsec-ike-ecc-groups-01.txt are designed to provide secure elliptic curve groups. This draft is particularly relevant now since the existing elliptic curve groups in IKE have recently been broken by Gaudry, Hess, and Smart (http://www.hpl.hp.com/news/ecc.html). We warned over a year ago about the security of the existing IKE ECC groups and unfortunately nothing has yet been done. An additional feature of the the new groups proposed is that they align ECC in IPSec with ECC in ANSI and NIST. I think it's important to add these groups to IKE both in order encourage implementors to use ECC which is increasingly recognized by researchers as offering superior security to regular Diffie-Hellman and in order to make use of these groups easily available to implementors in Phase 1 without having to resort to the new group mode. If adding the groups to IKE is impossible, then I think the draft should become an informational RFC. Going forward surely we want to offer public-key security comparable to AES strength in IPSec. Following Lenstra and Verhuel's paper (www.cryptosavvy.com) and NIST's recommendations, this means: 128-bit AES approx= 256-bit ECC approx= 3072-bit RSA/DH 192-bit AES approx= 384-bit ECC approx= 7680-bit RSA/DH 256-bit AES approx= 512-bit ECC approx= 15360-bit RSA/DH Best regards, Yuri Poeluev Certicom Corp. Paul Koning wrote: > >>>>> "Joe" == Joe MacLellan writes: > > Joe> The DH well-known primes are listed in Appendix E of RFC 2412 > Joe> (Oakley), not RFC 2409 (IKE). I don't think they should be > Joe> going to Dan to include in the IKE doc, they should be added to > Joe> 2412 with the rest. > > That seems odd, because 2412 is "Informational". Things that affect > how a protocol works or how it interoperates should be in standards > track specs, I would think. > > I suppose the notion of a protocol spec (which 2412 seems to be) > marked "informational" is a bit odd in general. > > paul From owner-ipsec@lists.tislabs.com Tue Feb 8 08:34: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 IAA11814; Tue, 8 Feb 2000 08:34:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03897 Tue, 8 Feb 2000 10:17:18 -0500 (EST) Message-Id: <200002081522.JAA15529@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Tim Jenkins cc: ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: Latest Re-keying Draft In-reply-to: Your message of "Tue, 08 Feb 2000 09:19:53 EST." <319A1C5F94C8D11192DE00805FBBADDF01171CF5@exchange> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Feb 2000 09:22:32 -0600 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A couple of thing related to rekeying that I must have missed elsewhere in the drafts/RFC related to rekeying in regards to Kilobyte Lifetimes. If the phase 2 SA's have unlimited time lifetime and fixed KB lifetime, it is very easy to run into key proliferation problems where old key's never go away. In order to prevent key proliferation it appears that the implementation must: 1) Use all keys until they hard expire. Reason: Otherwise after a new key pair negotiated because the soft lifetime was hit and the new key pair is used, the old keys never hit their hard limit and go away. 2) Make sure to use every key pair negotiated Reason: Due to QM collisions extra key pairs can be negotiated. 3) Expire keys in pairs. Reason: Because keys are negotiated in pairs, and traffic across a VPN can be very asymetrical (witness large FTP's), and if 1 and 2 are implemented the queue of key pairs can grow very large. Is there an easier way to avoid key proliferation with KB lifetimes without adding the implementation complexity detailed above? Regards, Michael Carney From owner-ipsec@lists.tislabs.com Tue Feb 8 09:28: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 JAA13438; Tue, 8 Feb 2000 09:28:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04162 Tue, 8 Feb 2000 11:04:56 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF01171DC4@exchange> From: Tim Jenkins To: Mike Carney Cc: ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: RE: Latest Re-keying Draft Date: Tue, 8 Feb 2000 11:12:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Mike, I'm not sure if you would like to see these addressed in the document, so I'll comment as though you don't, since the original intent of the phase 2 part of the document was really how to transfer traffic from the old to the new SA. It was not intended to handle SA management as a whole, although it does touch on some of those issues. Comments below. Tim > -----Original Message----- > From: Mike Carney [mailto:carney@securecomputing.com] > Sent: February 8, 2000 10:23 AM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com; carney@jumpsrv.stp.securecomputing.com > Subject: Re: Latest Re-keying Draft > > > A couple of thing related to rekeying that I must have missed > elsewhere in > the drafts/RFC related to rekeying in regards to Kilobyte Lifetimes. > > If the phase 2 SA's have unlimited time lifetime and fixed KB > lifetime, > it is very easy to run into key proliferation problems where old key's > never go away. > > In order to prevent key proliferation it appears that the > implementation must: > 1) Use all keys until they hard expire. > Reason: Otherwise after a new key pair negotiated because > the soft lifetime > was hit and the new key pair is used, the old > keys never hit their > hard limit and go away. In the re-keying document this is covered by the requirement that a re-keyed SA have its lifetime set to 30 seconds after the new SA is up (unless it will already expire sooner than that). > 2) Make sure to use every key pair negotiated > Reason: Due to QM collisions extra key pairs can be negotiated. I assume you're talking about a case where you get two pairs of SAs with traffic lifetimes only. In this case, if the endpoints behave the same, they will likely end up using different pairs for transmission. What I means is that if SA pairs A and B are created, one end will use A for outbound traffic and the other will use B. This means that one half of the two key pairs gets used. Then, use your rule three below. However, if this doesn't happen, it does look like proliferation of the SAs could be possible, but only if re-keying again happens simultaneously. Obviously, things like inactivity detection can help mitigate this situation. > 3) Expire keys in pairs. > Reason: Because keys are negotiated in pairs, and traffic > across a VPN > can be very asymetrical (witness large FTP's), and > if 1 and 2 are > implemented the queue of key pairs can grow very large. I think this is normal practise anyway. IKE negotiates a pair, so I think they're normally deleted in pairs. Our implementation does this anyway. > > Is there an easier way to avoid key proliferation with KB > lifetimes without > adding the implementation complexity detailed above? > > Regards, > Michael Carney > > Tim From owner-ipsec@lists.tislabs.com Tue Feb 8 11: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 LAA16719; Tue, 8 Feb 2000 11:11:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04450 Tue, 8 Feb 2000 12:47:39 -0500 (EST) Message-Id: <4.2.1.20000208094754.00a55d10@mail.imc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Tue, 08 Feb 2000 09:53:29 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Fwd: I-D ACTION:draft-hoffman-ipsec-testing-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. Michael Richardson and I put together this draft to help make interoperability testing and verification faster. One thing that I saw many times at the Santa Barbara and San Diego bakeoffs was people spinning their wheels on testing when it turns out they didn't have the right addresses built into their systems and so on. Following the steps in this draft will certainly help prevent those situations. This is a first draft, and it is likely that some of you can think of things we did wrong or other things we need to add. There are also some questions about what we should and should not register with IANA. Your comments are invited. >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-hoffman-ipsec-testing-00.txt >Date: Tue, 08 Feb 2000 06:32:21 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Steps for IPsec Interoperability Testing > Author(s) : P. Hoffman, M. Richardson > Filename : draft-hoffman-ipsec-testing-00.txt > Pages : 6 > Date : 07-Feb-00 > >Interoperability testing between systems from different vendors is >often a difficult process. In the case of IPsec implementations, >interoperability testing is made more difficult by the fact that there >are two protocols, IKE and IPsec, that both must work together. This >document defines an ordered set of steps for testing two systems >efficiently. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hoffman-ipsec-testing-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-hoffman-ipsec-testing-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-hoffman-ipsec-testing-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. >Content-Type: text/plain >Content-ID: <20000207125640.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-hoffman-ipsec-testing-00.txt > > From owner-ipsec@lists.tislabs.com Tue Feb 8 20:36: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 UAA09249; Tue, 8 Feb 2000 20:36:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA06170 Tue, 8 Feb 2000 20:16:11 -0500 (EST) Message-ID: <01E1D01C12D7D211AFC70090273D20B102A1CC1C@sothmxs06.entrust.com> From: Greg Carter To: ipsec@lists.tislabs.com Subject: ??????????????? Date: Tue, 8 Feb 2000 20:20:50 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul I could easily spin each of your observations into something positive, point out the places where you are wrong, and drag this into a 1000 post thread. But instead I'll just ask, what were you thinking? I mean even if you really believe the VPN-PKI world is askew is this the best way for a consortium to encourage adoption of its technology? I know Entrust is not a member, so I guess I missed the meeting where you explained how bad press helps. Not to mention bakeoff etiquette. Now this has me mystified? NETWORK WORLD FUSION FOCUS: PAUL HOFFMAN on SECURITY Today's Focus: Lack of agreement on PKI bodes ill for VPN users 02/08/00 Today's Focus: Lack of agreement on PKI bodes ill for VPN users --------------------------------------------------------------- By Paul Hoffman, guest columnist If you're deploying a public-key infrastructure and expect your mission-critical applications, such as virtual private networks, to connect instantly, think again. Lack of a clear focus for PKI, coupled with a lack of interoperability across all PKI-using systems, will cause untold delays in getting products to work together. A few weeks ago, I conducted an informal survey at a VPN interoperability bakeoff in San Diego. The purpose of the survey was to let certificate authority vendors know what VPN vendors are implementing and to let VPN vendors know what the others are doing so they can reach agreement on how to proceed with certificate authentication in IP Security. The results were depressing. There was no general agreement on enrollment, the mechanism by which a VPN gets its own certificate, usually when you install the system. About 80% of the vendors surveyed support manual or Web-based enrollment using a fairly standard request format; unfortunately, they were almost evenly split regarding the format for the response they expect from the certificate authority. In a stunning rebuke of the standards process, only a handful of vendors used the IETF's Certificate Management Protocol (CMP) standard. The fledgling Simple Certificate Enrollment Protocol, which was cobbled together outside the IETF and made public only last month, had more users, despite its obvious technical problems. The good news is a solid majority of VPNs check the revocation status of the certificates they receive. This is particularly important for VPNs used in extranets and in corporate networks that assume if a user got in through a VPN, he should have wide access to resources on the net. The bad news is there was no agreement on how to find revocation information. No common methods (checking revocation information given with certificates; manual checking with Lightweight Directory Access Protocol or HTTP; checking at locations listed in a certificate) were supported by more than half the implementers. Even though all VPN systems are online, none of the implementers was using the IETF's Online Certificate Status Protocol standard. Perhaps the most depressing discovery was that almost one-third of the VPN vendors didn't support chains of certificates: They required all incoming certificates to be signed directly by a trusted root. No one ever said that verifying a path of certificates from the one you are given to one you trust is easy, but it is pretty much a requirement if we expect PKI to scale beyond today's small number of users. The blame for this mess can't be laid solely on VPN vendors. Certificate authority vendors have been slow to roll out support for CMP and have often pooh-poohed the need for good revocation checking. And the IETF has not made certificate path validation easy (the PKI X.509 Working Group is now considering a major clarification to the rules). The result is not pretty for the VPN industry and bodes poorly for other markets that rely on certificates, as well. About the author: ------------------------- Paul Hoffman is director of the VPN Consortium and the Internet Mail Consortium. He can be reached at paul.hoffman@vpnc.org. Copyright Network World, Inc., 2000 From owner-ipsec@lists.tislabs.com Tue Feb 8 22:47: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 WAA13971; Tue, 8 Feb 2000 22:47:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA06836 Wed, 9 Feb 2000 00:10:23 -0500 (EST) Message-Id: <4.2.1.20000208204513.00ca09e0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Tue, 08 Feb 2000 21:16:11 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: ??????????????? In-Reply-To: <01E1D01C12D7D211AFC70090273D20B102A1CC1C@sothmxs06.entrust .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:20 PM 2/8/00 -0500, Greg Carter wrote: >Paul I could easily spin each of your observations into something positive, >point out the places where you are wrong, and drag this into a 1000 post >thread. Thanks for starting it this way. :-) > But instead I'll just ask, what were you thinking? Of telling the readers who assume that their VPN box from vendor A will automatically be able to work with their CA software from vendor B that the truth is actually "it might work, it might not". People like to know these things, and they understand that they aren't going to hear it from individual vendors for obvious reasons. > I mean even if >you really believe the VPN-PKI world is askew is this the best way for a >consortium to encourage adoption of its technology? Yes. It brings pressure on VPN vendors and CA vendors to work harder at interoperability in this very important area. It also shows where we have had success so far. If you can think of a better way to get VPN vendors and CAs to follow the standards better, by all means act on it. As we all saw at San Diego, the problems in the VPN-PKI area are widespread but by no means universal. > I know Entrust is not a >member, so I guess I missed the meeting where you explained how bad press >helps. It's not bad press. No one is going to decide not to buy a VPN or a CA because of the article. They may shop harder or postpone until their preferred vendor adds needed interoperability; both those actions lead directly to happier customers. Also, VPNC had a meeting on Tuesday night of the bakeoff which was open to all bakeoff companies, members and non-members alike. There were plenty of non-members there, many taking notes. >Not to mention bakeoff etiquette. Um, I don't see where I've even gotten close there. I mentioned no companies by name, not even hinting. No one reading the article could even start to determine which CAs or which VPN vendors did what, or will do what in the future. The numbers could easily have been done by polling just VPNC members or implementors on this list. In short, no one is helped by hiding general industry lack of interoperability as long as there is something customers can do about it (like choosing carefully). It is always a good idea to be honest with customers about potential problems before they buy sets of products so that the customers get what works for them. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Feb 8 23:26: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 XAA16018; Tue, 8 Feb 2000 23:26:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07018 Wed, 9 Feb 2000 01:17:46 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Paul Hoffman Cc: ipsec@lists.tislabs.com Subject: Re: ??????????????? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Feb 2000 01:22:54 -0500 Message-Id: <20000209062300.43ADDACAE2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At NANOG yesterday, I had to get up and explain to folks just why IPSEC products didn't really interoperate all that well yet. I think that on this group, we know the answers -- and yes, certificate issues are near the top of the list. --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Feb 9 01:50: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 BAA20482; Wed, 9 Feb 2000 01:50:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA07315 Wed, 9 Feb 2000 03:24:04 -0500 (EST) Message-ID: <38A12558.6313A41B@sec.nl> Date: Wed, 09 Feb 2000 09:29:12 +0100 From: Jac Kloots Organization: SURFnet ExpertiseCentrum bv X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,nl MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: DNSSEC and IPsec References: <20000209062300.43ADDACAE2@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi There, I was reading some notes about the NANOG meeting from last week and noticed something about BIND9 and it's full implementation of DNSSEC. As I remember well from reading about DNSSEC, it included some authentication information for hosts. My question to this group is, Are there any IPsec implementations which use the DNSSEC information for authentication? Please correct me if I'm wrong about the authentication information in DNSSEC. Regards, Jac Kloots -- Jac Kloots SURFnet ExpertiseCentrum bv The Netherlands From owner-ipsec@lists.tislabs.com Wed Feb 9 02:41: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 CAA21805; Wed, 9 Feb 2000 02:41:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA07557 Wed, 9 Feb 2000 04:32:18 -0500 (EST) Message-ID: <38A13580.CDEE6BEC@checkpoint.com> Date: Wed, 09 Feb 2000 11:38:08 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <319A1C5F94C8D11192DE00805FBBADDF011712B4@exchange> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk While Main Mode and Base Mode provide some protection against DoS attacks through the cookies mechanism, no protection is provided whenever the attacker is on the path between the responder and the spoofed initiator. In such a case the responder is still susceptible to cookie crumb attacks or to modular exponentiations attacks. Let me propose a method to ward off modular exponentiations attacks. The method is as follows: If a responder detects that it being attacked (let say by the fact that it has more than X simultaneous Phase 1 negotiations, where X is configurable) it will do the following: 1. Generate a 128 bit random number A. 2. Compute MD5(A). 3. Send a special ISAKMP payload to the initiator that contains - I. MD5(A). II. The first B bits of A, where B is configurable. Upon receipt of this payload, the initiator will be asked to compute A (using brute force methods) and send it back to the responder. This computation is possible with the aid of the first B bits of A. The responder will then proceed to do the modular exponentiations computations only if it got A from the initiator. Using these methods (and assuming that there is no efficient method to invert the MD5 function given MD5(A) and the first B bits of A) DoS attacks become very difficult. Notes: 1. Any other cryptographic hash function can be used. 2. If B is too small the initiator can refuse to carry out the exchange (so as not to spend to much resources). 3. This theoretically opens up another attack in which the attacker attacks the initiator (and not the responder) by sending him this payload. This in my mind is not such a serious problem, since in scenarios that allow this kind of attack, the DoS attacker instead of mounting this attack can simply pretend to be the responder making the initiator to do the modular exponentiations. Regards, Tamir. From owner-ipsec@lists.tislabs.com Wed Feb 9 04: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 EAA25707; Wed, 9 Feb 2000 04:29:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA07705 Wed, 9 Feb 2000 06:13:27 -0500 (EST) Message-ID: <38A14CDB.D5EA32ED@helios.iihe.ac.be> Date: Wed, 09 Feb 2000 12:17:47 +0100 From: Alain Jourez X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tamir Zegman CC: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <319A1C5F94C8D11192DE00805FBBADDF011712B4@exchange> <38A13580.CDEE6BEC@checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tamir Zegman wrote: > While Main Mode and Base Mode provide some protection against DoS attacks > through the cookies mechanism, no protection is provided whenever the attacker > is on the path between the responder and the spoofed initiator. > In such a case the responder is still susceptible to cookie crumb attacks or to > modular exponentiations attacks. > > Let me propose a method to ward off modular exponentiations attacks. > The method is as follows: > If a responder detects that it being attacked (let say by the fact that it has > more than X simultaneous Phase 1 negotiations, where X is configurable) it will > do the following: > 1. Generate a 128 bit random number A. > 2. Compute MD5(A). > 3. Send a special ISAKMP payload to the initiator that contains - > I. MD5(A). > II. The first B bits of A, where B is configurable. > > Upon receipt of this payload, the initiator will be asked to compute A (using > brute force methods) and send it back to the responder. > This computation is possible with the aid of the first B bits of A. > The responder will then proceed to do the modular exponentiations computations > only if it got A from the initiator. > > Using these methods (and assuming that there is no efficient method to invert > the MD5 function given MD5(A) and the first B bits of A) DoS attacks become very > difficult. > > Notes: > 1. Any other cryptographic hash function can be used. > 2. If B is too small the initiator can refuse to carry out the exchange (so as > not to spend to much resources). > 3. This theoretically opens up another attack in which the attacker attacks the > initiator (and not the responder) by sending him this payload. This in my mind > is not such a serious problem, since in scenarios that allow this kind of > attack, the DoS attacker instead of mounting this attack can simply pretend to > be the responder making the initiator to do the modular exponentiations. > > Regards, > Tamir. Well, maybe I'm missing something here, but I don't get the point. You're assuming an active attacker on the path between the initiator and the responder. You propose to generate a random number, sending its MD5 and first bits to the initiator. The initiator then must use brute force to get back the initial number. Here are my reamarks : 1. If the initiator can brute-force to get back the number, so does the attacker. The latter can then still force the responder to do the modular exponentiation --at additionnal cost but it depends on the number of bits received, to see wich one is more costly isn't easy. 2. Someone spoofing on the path still can intercept the packet and block the transmissions. (this is still DoS in my point of view.) He can also transmit the packet to the real initiator, waiting for his response, avoiding himself to get into heavy computational task. Still he can re-initiate a spofing negotiation with the responder. 3. It puts a computational overhead on both the initiator and responder. Both of them still has to maintain the cookies states. How should we handle that ? 4. What security offers the addition of the MD5 calculation, since anyone still has to brute-force to guess the number ? Your construct tacitly assumes that there is less computational overhead to brute-force the number than to do the modular exponentiation. Do you have an idea on the size required to get that property on MD5 ? What happens if there exist a collision ? 5. IMHO this doesn't prevent the attack by someone on the path between both entities as you assume. Again, I admit I may be wrong, but I don't get the added value of your construct in terms of security. Best regards. Alain Jourez From owner-ipsec@lists.tislabs.com Wed Feb 9 05:25: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 FAA26242; Wed, 9 Feb 2000 05:25:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07932 Wed, 9 Feb 2000 07:15:27 -0500 (EST) Message-Id: <10002091222.AA03071@Ichiko.imailab.iis.u-tokyo.ac.jp> From: Kanta Matsuura Date: Wed, 09 Feb 2000 21:22:59 +0900 To: Tamir Zegman Cc: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing In-Reply-To: <38A13580.CDEE6BEC@checkpoint.com> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A quite similar idea was proposed in K. Matsuura and H. Imai. ``Protection of Authenticated Key-Agreement Protocol against a Denial-of-Service Attack''. Proceedings of 1998 International Symposium on Information Theory and Its Applications (ISITA'98), pp. 466-470, Oct. 1998. and K. Matsuura and H. Imai. ``Protection of Authenticated Key-Agreement Protocol against a Denial-of-Service Attack''. Cientifica, Vol.2, No.11, pp.15-19, 1999. as ``falling-together strategy.'' This is used in http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt and discourages DoS attackers from exhausting CPU resource of the target; CPU-exhaustion DoS attack imposes expensive computation on the attackers themselves. The main differences between your proposal and mine are: (1) Yours can control the cost on the attacker while mine cannot. (2) Mine does not require any additional "quiz" but makes use of a random material which appears in signature-verification procedure (which is anyway required if authenticated by signature). Related articles can be obtained at http://imailab-www.iis.u-tokyo.ac.jp/Members/kanta-bib-e.html Regards, Tamir Zegman wrote: >>While Main Mode and Base Mode provide some protection against DoS attacks >>through the cookies mechanism, no protection is provided whenever the attacker >>is on the path between the responder and the spoofed initiator. >>In such a case the responder is still susceptible to cookie crumb attacks or to >>modular exponentiations attacks. >> >>Let me propose a method to ward off modular exponentiations attacks. >>The method is as follows: >>If a responder detects that it being attacked (let say by the fact that it has >>more than X simultaneous Phase 1 negotiations, where X is configurable) it will >>do the following: >>1. Generate a 128 bit random number A. >>2. Compute MD5(A). >>3. Send a special ISAKMP payload to the initiator that contains - >> I. MD5(A). >> II. The first B bits of A, where B is configurable. >> >>Upon receipt of this payload, the initiator will be asked to compute A (using >>brute force methods) and send it back to the responder. >>This computation is possible with the aid of the first B bits of A. >>The responder will then proceed to do the modular exponentiations computations >>only if it got A from the initiator. >> >>Using these methods (and assuming that there is no efficient method to invert >>the MD5 function given MD5(A) and the first B bits of A) DoS attacks become very >>difficult. >> >>Notes: >>1. Any other cryptographic hash function can be used. >>2. If B is too small the initiator can refuse to carry out the exchange (so as >>not to spend to much resources). >>3. This theoretically opens up another attack in which the attacker attacks the >>initiator (and not the responder) by sending him this payload. This in my mind >>is not such a serious problem, since in scenarios that allow this kind of >>attack, the DoS attacker instead of mounting this attack can simply pretend to >>be the responder making the initiator to do the modular exponentiations. >> >>Regards, >>Tamir. >> >> --^^-- Kanta From owner-ipsec@lists.tislabs.com Wed Feb 9 05:29: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 FAA26301; Wed, 9 Feb 2000 05:29:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07966 Wed, 9 Feb 2000 07:30:34 -0500 (EST) Message-ID: <38A15F20.F9006522@storm.ca> Date: Wed, 09 Feb 2000 07:35:44 -0500 From: Sandy Harris X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jac Kloots CC: ipsec@lists.tislabs.com Subject: Re: DNSSEC and IPsec References: <20000209062300.43ADDACAE2@smb.research.att.com> <38A12558.6313A41B@sec.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jac Kloots wrote: > I was reading some notes about the NANOG meeting from last week and > noticed something about BIND9 and it's full implementation of DNSSEC. As > I remember well from reading about DNSSEC, it included some > authentication information for hosts. > > My question to this group is, Are there any IPsec implementations which > use the DNSSEC information for authentication? We don't do it in the current release, but that is certainly on the agenda, and a fairly high priority, for FreeS/WAN. http://www.freeswan.org From owner-ipsec@lists.tislabs.com Wed Feb 9 07:37: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 HAA28239; Wed, 9 Feb 2000 07:37:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08239 Wed, 9 Feb 2000 09:03:49 -0500 (EST) Message-ID: <38A17518.E9B59D11@checkpoint.com> Date: Wed, 09 Feb 2000 16:09:29 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Kanta Matsuura CC: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <10002091222.AA03071@Ichiko.imailab.iis.u-tokyo.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Kanta Matsuura wrote: > A quite similar idea was proposed in > Yes I agree. I must say that your draft made me think of the problem and possible solutions to it. My proposal has some advantages at least from an engineering point of view: 1. It adds only 2 payloads. 2. It is orthogonal to the authentication method you choose to employ and the key derivation mechanism. 3. It's simpler. 4. As you already mentioned - one can control the amount of computations performed by the initiator. Regards, Tamir. > K. Matsuura and H. Imai. ``Protection of Authenticated Key-Agreement Protocol > against a Denial-of-Service Attack''. Proceedings of 1998 > International Symposium on Information Theory and Its Applications > (ISITA'98), pp. 466-470, Oct. 1998. > > and > > K. Matsuura and H. Imai. ``Protection of Authenticated Key-Agreement Protocol > against a Denial-of-Service Attack''. Cientifica, Vol.2, > No.11, pp.15-19, 1999. > > as ``falling-together strategy.'' > This is used in > http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt > and > discourages DoS attackers from exhausting CPU resource of the target; > CPU-exhaustion DoS attack imposes expensive computation > on the attackers themselves. > > The main differences between your proposal and mine are: > (1) Yours can control the cost on the attacker while mine cannot. > (2) Mine does not require any additional "quiz" but makes use of > a random material which appears in signature-verification procedure > (which is anyway required if authenticated by signature). > > Related articles can be obtained at > http://imailab-www.iis.u-tokyo.ac.jp/Members/kanta-bib-e.html > > Regards, > > Tamir Zegman wrote: > >>While Main Mode and Base Mode provide some protection against DoS attacks > >>through the cookies mechanism, no protection is provided whenever the > attacker > >>is on the path between the responder and the spoofed initiator. > >>In such a case the responder is still susceptible to cookie crumb attacks or > to > >>modular exponentiations attacks. > >> > >>Let me propose a method to ward off modular exponentiations attacks. > >>The method is as follows: > >>If a responder detects that it being attacked (let say by the fact that it > has > >>more than X simultaneous Phase 1 negotiations, where X is configurable) it > will > >>do the following: > >>1. Generate a 128 bit random number A. > >>2. Compute MD5(A). > >>3. Send a special ISAKMP payload to the initiator that contains - > >> I. MD5(A). > >> II. The first B bits of A, where B is configurable. > >> > >>Upon receipt of this payload, the initiator will be asked to compute A > (using > >>brute force methods) and send it back to the responder. > >>This computation is possible with the aid of the first B bits of A. > >>The responder will then proceed to do the modular exponentiations > computations > >>only if it got A from the initiator. > >> > >>Using these methods (and assuming that there is no efficient method to > invert > >>the MD5 function given MD5(A) and the first B bits of A) DoS attacks become > very > >>difficult. > >> > >>Notes: > >>1. Any other cryptographic hash function can be used. > >>2. If B is too small the initiator can refuse to carry out the exchange (so > as > >>not to spend to much resources). > >>3. This theoretically opens up another attack in which the attacker attacks > the > >>initiator (and not the responder) by sending him this payload. This in my > mind > >>is not such a serious problem, since in scenarios that allow this kind of > >>attack, the DoS attacker instead of mounting this attack can simply pretend > to > >>be the responder making the initiator to do the modular exponentiations. > >> > >>Regards, > >>Tamir. > >> > >> > > --^^-- > Kanta -- ========================================================================= This message may contain confidential and/or proprietary information, and is intended only for the person / entity to whom it was originally addressed. The content of this message may contain private views and opinions which do not constitute a formal disclosure or commitment unless specifically stated. From owner-ipsec@lists.tislabs.com Wed Feb 9 09:21: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 JAA00299; Wed, 9 Feb 2000 09:21:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08631 Wed, 9 Feb 2000 10:40:25 -0500 (EST) Message-ID: <01E1D01C12D7D211AFC70090273D20B102A1CC21@sothmxs06.entrust.com> From: Greg Carter To: ipsec@lists.tislabs.com Subject: RE: ??????????????? Date: Wed, 9 Feb 2000 10:45:09 -0500 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 OK then reality check. We issued certs to every vendor who asked, with out looking I think at least 15 to 20 vendors, with 3 or 4 different protocols, with off the shelf products. Vendors using our toolkits verified certs from other PKI vendors as well. Is that not interop? If a VPN vendor can't get a cert from each of the PKI vendors at the bakeoff its because they are incompetent, nothing more nothing less. I think you would hear the same thing from the other PKI vendors. Sure you didn't mention vendor names. But hell you made broad sweeping statements about two industries in general. From what I can see mostly for effect. As far as etiquette, well you published bakeoff results. There is no line to cross, its binary. If you would have come to those conclusions some other way I wouldn't have posted this here. You know people have been known to bring code to bakeoffs that isn't exactly release candidate. They don't send every developer working on the product, ever think maybe the ones who seemed a bit clueless left the developers who had a clue about certs were back at the office? I have been issuing certs to vendors since the second bakeoff in Boston in early '97. The only problem I have run into in the last year is implementers expecting to use certs without reading a single spec. Its the same questions over and over, where do I put the ip address, how do I generate a PKCS10 request, how do I send a cert in IKE, how do I get a CRL and on and on, RTF specs. Then without reading the specs they talk to people like you and insist on how hard its, well its not. I didn't attempt to write an IKE engine without reading ISAKMP, IKE, OAKLEY, and DOI. Why do people think they can use certs without reading X.509 and PKIX? Can a Cisco router not get a cert from every PKI vendor? can Checkpoint firewall not get a cert from every PKI vendor? etc.. etc.., do the two not inteorp? I can remember back to the Ottawa bakeoff where we issued certs to a Cisco router using SCEP, issued certs to a Raptor Firewall using the Entrust precursor to CMP and guess what? They setup a tunnel, then we revoked the routers cert and guess what? The tunnel came down at the next IKE exchange. Unless there has been some huge incompetence at either of those companies in the last 2.5 years my guess is that will still work today with off the shelf products. Greg Carter Entrust Technologies - http://www.entrust.com -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Wednesday, February 09, 2000 12:16 AM To: ipsec@lists.tislabs.com Subject: Re: ??????????????? At 08:20 PM 2/8/00 -0500, Greg Carter wrote: >Paul I could easily spin each of your observations into something positive, >point out the places where you are wrong, and drag this into a 1000 post >thread. Thanks for starting it this way. :-) > But instead I'll just ask, what were you thinking? Of telling the readers who assume that their VPN box from vendor A will automatically be able to work with their CA software from vendor B that the truth is actually "it might work, it might not". People like to know these things, and they understand that they aren't going to hear it from individual vendors for obvious reasons. > I mean even if >you really believe the VPN-PKI world is askew is this the best way for a >consortium to encourage adoption of its technology? Yes. It brings pressure on VPN vendors and CA vendors to work harder at interoperability in this very important area. It also shows where we have had success so far. If you can think of a better way to get VPN vendors and CAs to follow the standards better, by all means act on it. As we all saw at San Diego, the problems in the VPN-PKI area are widespread but by no means universal. > I know Entrust is not a >member, so I guess I missed the meeting where you explained how bad press >helps. It's not bad press. No one is going to decide not to buy a VPN or a CA because of the article. They may shop harder or postpone until their preferred vendor adds needed interoperability; both those actions lead directly to happier customers. Also, VPNC had a meeting on Tuesday night of the bakeoff which was open to all bakeoff companies, members and non-members alike. There were plenty of non-members there, many taking notes. >Not to mention bakeoff etiquette. Um, I don't see where I've even gotten close there. I mentioned no companies by name, not even hinting. No one reading the article could even start to determine which CAs or which VPN vendors did what, or will do what in the future. The numbers could easily have been done by polling just VPNC members or implementors on this list. In short, no one is helped by hiding general industry lack of interoperability as long as there is something customers can do about it (like choosing carefully). It is always a good idea to be honest with customers about potential problems before they buy sets of products so that the customers get what works for them. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Feb 9 09:53: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 JAA00715; Wed, 9 Feb 2000 09:53:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08824 Wed, 9 Feb 2000 11:35:25 -0500 (EST) Date: Wed, 9 Feb 2000 11:40:32 -0500 Message-Id: <200002091640.LAA02265@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: greg.carter@entrust.com Cc: ipsec@lists.tislabs.com Subject: RE: ??????????????? References: <01E1D01C12D7D211AFC70090273D20B102A1CC21@sothmxs06.entrust.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Greg" == Greg Carter writes: Greg> OK then reality check. We issued certs to every vendor who Greg> asked, with out looking I think at least 15 to 20 vendors, with Greg> 3 or 4 different protocols, with off the shelf products. Greg> Vendors using our toolkits verified certs from other PKI Greg> vendors as well. Is that not interop? If a VPN vendor can't Greg> get a cert from each of the PKI vendors at the bakeoff its Greg> because they are incompetent, nothing more nothing less. I'm not sure it's constructive to insult your customers. You might consider the possibility that (a) showing up at a bakeoff with a bug in your code doesn't necessarily mean you're incompetent, (b) as with most protocol specs these days, conformance does not imply interoperability (nor vice versa), (c) there might even be a remote possibility that there are some bugs at the PKI side of the house rather than just at the VPN side. Let him who is without bugs cast the first invective. paul From owner-ipsec@lists.tislabs.com Wed Feb 9 13:29: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 NAA04899; Wed, 9 Feb 2000 13:29:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10541 Wed, 9 Feb 2000 14:46:59 -0500 (EST) Message-Id: <200002091949.LAA07400@potassium.network-alchemy.com> To: Paul Koning cc: greg.carter@entrust.com, ipsec@lists.tislabs.com Subject: Re: ??????????????? In-reply-to: Your message of "Wed, 09 Feb 2000 11:40:32 EST." <200002091640.LAA02265@tonga.xedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7397.950125778.1@network-alchemy.com> Date: Wed, 09 Feb 2000 11:49:38 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK, I'll 'fess up as one of the incompetents (and I'm not taking Greg's comments as an insult). I'm not the cert guy here but I have to use the code. And I don't read X.509 and have not read all the PKIX docs because I don't have the time and I'm not the cert guy anyway. So I was giving Greg a PKCS#10 and he was dutifully giving me back a PKCS#7 which I was trying to read as a raw DER (or is it BER-- see!) encoded cert. I tracked Greg down and he pointed out the little check box on the web page I should've read but didn't. Complete operator error. I wouldn't be surprised if this was repeated over and over at the bakeoff. Hence the frustration about how certs just don't work when, in fact, they do once you do things correctly. I tend to agree with Greg on this. And I have to thank him for not telling me to RTF-web-page and RTF-specs which he would've been well within his rights to say. Dan. On Wed, 09 Feb 2000 11:40:32 EST you wrote > >>>>> "Greg" == Greg Carter writes: > > Greg> OK then reality check. We issued certs to every vendor who > Greg> asked, with out looking I think at least 15 to 20 vendors, with > Greg> 3 or 4 different protocols, with off the shelf products. > Greg> Vendors using our toolkits verified certs from other PKI > Greg> vendors as well. Is that not interop? If a VPN vendor can't > Greg> get a cert from each of the PKI vendors at the bakeoff its > Greg> because they are incompetent, nothing more nothing less. > > I'm not sure it's constructive to insult your customers. You might > consider the possibility that (a) showing up at a bakeoff with a bug > in your code doesn't necessarily mean you're incompetent, (b) as with > most protocol specs these days, conformance does not imply > interoperability (nor vice versa), (c) there might even be a remote > possibility that there are some bugs at the PKI side of the house > rather than just at the VPN side. Let him who is without bugs cast > the first invective. > > paul From owner-ipsec@lists.tislabs.com Thu Feb 10 02:57: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 CAA24958; Thu, 10 Feb 2000 02:57:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA13150 Thu, 10 Feb 2000 04:20:56 -0500 (EST) Message-Id: <200002100926.MAA18503@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: Tamir Zegman Date: Thu, 10 Feb 2000 12:25:24 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing CC: ipsec@lists.tislabs.com In-reply-to: <38A13580.CDEE6BEC@checkpoint.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 9 Feb 00, at 11:38, Tamir Zegman wrote: Hi, Tamir, please, see some comments below. First of all, a very similar idea was described in http://search.ietf.org/internet-drafts/draft-moskowitz-hip-01.txt But in both cases I'm puzzled what benefits will this approach lead to? In my understanding the way to defend responder against DoS attacks lies in lowering responder's resource consumption (both in memory and CPU) _while performing peer authentication_. The last addition is important. And, for example, stateless cookies do meet this requirement - they perform a weak peer authentication with minimum resource consumption. In this case responder's credo is "OK, I will talk to you if you proof that you're alive". It makes sense to me, because "to be alive" is some part of authentication. But what is responder's credo in your case? With your approach responder requires initiator to perform costly operation that doesn't add any bit to initiator authentication. Responder says: "OK, I will talk to you if you proof that you're alive and have substantial CPU power". Does it make any sense? In my understanding good DoS attack defending technique should protect responder from attacker _while still allowing legitimate initiator to perform connection_ (at least with some probability). Your approach deliberately prevents poor legitimate peers to connect when responder feels it is under attack. It is not DoS attack defending, it is a real DoS (Denial of Service) for such peers, so an attacker may celebrate... In this case I would prefer a simple "random drop" technique - at least it is more democratic :-) Best regards, Valera. > While Main Mode and Base Mode provide some protection against DoS attacks > through the cookies mechanism, no protection is provided whenever the attacker > is on the path between the responder and the spoofed initiator. > In such a case the responder is still susceptible to cookie crumb attacks or to > modular exponentiations attacks. > > Let me propose a method to ward off modular exponentiations attacks. > The method is as follows: > If a responder detects that it being attacked (let say by the fact that it has > more than X simultaneous Phase 1 negotiations, where X is configurable) it will > do the following: > 1. Generate a 128 bit random number A. > 2. Compute MD5(A). > 3. Send a special ISAKMP payload to the initiator that contains - > I. MD5(A). > II. The first B bits of A, where B is configurable. > > Upon receipt of this payload, the initiator will be asked to compute A (using > brute force methods) and send it back to the responder. > This computation is possible with the aid of the first B bits of A. > The responder will then proceed to do the modular exponentiations computations > only if it got A from the initiator. > > Using these methods (and assuming that there is no efficient method to invert > the MD5 function given MD5(A) and the first B bits of A) DoS attacks become very > difficult. > > Notes: > 1. Any other cryptographic hash function can be used. > 2. If B is too small the initiator can refuse to carry out the exchange (so as > not to spend to much resources). > 3. This theoretically opens up another attack in which the attacker attacks the > initiator (and not the responder) by sending him this payload. This in my mind > is not such a serious problem, since in scenarios that allow this kind of > attack, the DoS attacker instead of mounting this attack can simply pretend to > be the responder making the initiator to do the modular exponentiations. > > Regards, > Tamir. > > From owner-ipsec@lists.tislabs.com Thu Feb 10 02:57: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 CAA24959; Thu, 10 Feb 2000 02:57:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA13129 Thu, 10 Feb 2000 04:11:44 -0500 (EST) From: klaus.gross@web2cad.de Message-ID: X-Mailer: XFMail 1.4.0 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 10 Feb 2000 10:17:58 +0100 (CET) Reply-To: klaus.gross@web2cad.de Organization: Genius CAD Software GmbH & Co.KG. To: ipsec@lists.tislabs.com Subject: More than one VPN-Connection from a gateway Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello all, I'm new in configuring a VPN and I have the following question: How can I configure more than one VPN - Connections from a gateway, without using more than one device? Example: Host1 has a tunnel to Host2 configured as ipsec0=eth0 in ipsec.conf This works well. Now I want Host1 has also a tunnel to Host3 I tried more possibilities e.g. a second IP-Adress for eth0 with ipsec0=eth0:0 or a ipsec1=eth0 in the ipsec.conf Using a second decive, e.g. ippp0 configured as ipsec0=eth0 ipsec1=ippp0 I can build a tunnel to Host2 and Host3. Now I'm a little adviceless - I can't believe, that I need for each tunnel from Host1 an own physical device. For any idea I will oblige Klaus. ---------------------------------- E-Mail: klaus.gross@web2cad.de Date: 10-Feb-00 Time: 09:28:18 From owner-ipsec@lists.tislabs.com Thu Feb 10 05:21: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 FAA29623; Thu, 10 Feb 2000 05:21:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA13467 Thu, 10 Feb 2000 07:02:57 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D0386@baltimore.com> From: Chris Trobridge To: ipsec@lists.tislabs.com Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Date: Thu, 10 Feb 2000 12:08: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 defence lowers the responder's resource consumption /relative/ to the attacker's, by raising the cost to the attacker. I do share your concerns about the effects on the initiator, although moving the initial burden to the initiator does make sense in that it's probably a lot harder to spoof a target into initiating a connection than responding to one. Given that this is a defence against 'in the path' attackers, I think it leaves the initiator open to attacks too. eg Modifying the challenge so it is more difficult (or impossible!), or spoofing challenges where none was requested. I don't think the argument that initiator's are already open to this type of attack is particularly compelling. There's also an (Tamir) assumption about the relative costs of operations - if you have modular maths hardware then the effect of brute forcing an hash search could be far greater on other aspects of performance. It is also much harder to make a task moderately tasking enough to deter a foe but not inconvenience a legitimate initiator, given the way that processing power is increasing. I think people should consider Ted's (Theodore) comments (philosophy?) about defending against DOS. The main concerns appear to about resource attacks on the IPSEC machine by an active attacker who is on the path between the legitimate parties. As stated it's very hard to defend this attack other than making it hard for the attacker to conceal their location. Chris > -----Original Message----- > From: Valery Smyslov [mailto:svan@trustworks.com] > Sent: 10 February 2000 09:25 > To: Tamir Zegman > Cc: ipsec@lists.tislabs.com > Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs > Addressing > > > On 9 Feb 00, at 11:38, Tamir Zegman wrote: > > Hi, Tamir, > > please, see some comments below. > > First of all, a very similar idea was described in > http://search.ietf.org/internet-drafts/draft-moskowitz-hip-01.txt > > But in both cases I'm puzzled what benefits will this approach lead > to? In my understanding the way to defend responder against DoS > attacks lies in lowering responder's resource consumption (both in > memory and CPU) _while performing peer authentication_. The last > addition is important. > > And, for example, stateless cookies do meet this requirement - they > perform a weak peer authentication with minimum resource consumption. > In this case responder's credo is "OK, I will talk to you if you > proof that you're alive". It makes sense to me, because "to be alive" > is some part of authentication. But what is responder's credo in your > case? With your approach responder requires initiator to perform > costly operation that doesn't add any bit to initiator > authentication. Responder says: "OK, I will talk to you if you proof > that you're alive and have substantial CPU power". Does it make any > sense? > > In my understanding good DoS attack defending technique should > protect responder from attacker _while still allowing legitimate > initiator to perform connection_ (at least with some probability). > Your approach deliberately prevents poor legitimate peers to connect > when responder feels it is under attack. It is not DoS attack > defending, it is a real DoS (Denial of Service) for such peers, so an > attacker may celebrate... In this case I would prefer a simple > "random drop" technique - at least it is more democratic :-) > > Best regards, > Valera. From owner-ipsec@lists.tislabs.com Thu Feb 10 05: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 FAA01404; Thu, 10 Feb 2000 05:56:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA13595 Thu, 10 Feb 2000 07:52:40 -0500 (EST) Message-ID: <38A2B5F1.360CD38C@checkpoint.com> Date: Thu, 10 Feb 2000 14:58:25 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Valery Smyslov CC: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <200002100926.MAA18503@relay1.trustworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Valery Smyslov wrote: > On 9 Feb 00, at 11:38, Tamir Zegman wrote: > > Hi, Tamir, > > please, see some comments below. > > First of all, a very similar idea was described in > http://search.ietf.org/internet-drafts/draft-moskowitz-hip-01.txt > > But in both cases I'm puzzled what benefits will this approach lead > to? In my understanding the way to defend responder against DoS > attacks lies in lowering responder's resource consumption (both in > memory and CPU) _while performing peer authentication_. The last > addition is important. > > And, for example, stateless cookies do meet this requirement - they > perform a weak peer authentication with minimum resource consumption. > In this case responder's credo is "OK, I will talk to you if you > proof that you're alive". It makes sense to me, because "to be alive" > is some part of authentication. But what is responder's credo in your > case? With your approach responder requires initiator to perform > costly operation that doesn't add any bit to initiator > authentication. Responder says: "OK, I will talk to you if you proof > that you're alive and have substantial CPU power". Does it make any > sense? > In order to carry an effective DoS, an attacker needs to initiate a several (I'd say hundreds) of simultaneous negotiations with the responder. By using the method I propose, and assuming that the attacker computational power is limited, only few negotiations will reach the stage in which the responder is needed to perform the costly modular exponentiations. Note that my proposal does not prevent an honest peer from performing the key exchange - First of all the "Please reverse the hash function" challenge is only sent when the responder suspects that it is being attacked. Second, an honest initiator will only need to answer one of these challenges - a task that it can no doubt perform - whereas an attacker will need to respond to several hundreds in order for his attack to succeed. > > In my understanding good DoS attack defending technique should > protect responder from attacker _while still allowing legitimate > initiator to perform connection_ (at least with some probability). > Your approach deliberately prevents poor legitimate peers to connect > when responder feels it is under attack. This is a matter of configuration. If the challenge is as such that the number of cpu cycles needed to answer it is in the order of let say the cpu cycles needed to perform one modular exponentiation, then even poor legitimate peers would be able to respond, whereas an attacker will need to invest at least a 100 times more cpu power in order to succeed. > It is not DoS attack > defending, it is a real DoS (Denial of Service) for such peers, so an > attacker may celebrate... In this case I would prefer a simple > "random drop" technique - at least it is more democratic :-) > > Best regards, > Valera. > > > While Main Mode and Base Mode provide some protection against DoS attacks > > through the cookies mechanism, no protection is provided whenever the attacker > > is on the path between the responder and the spoofed initiator. > > In such a case the responder is still susceptible to cookie crumb attacks or to > > modular exponentiations attacks. > > > > Let me propose a method to ward off modular exponentiations attacks. > > The method is as follows: > > If a responder detects that it being attacked (let say by the fact that it has > > more than X simultaneous Phase 1 negotiations, where X is configurable) it will > > do the following: > > 1. Generate a 128 bit random number A. > > 2. Compute MD5(A). > > 3. Send a special ISAKMP payload to the initiator that contains - > > I. MD5(A). > > II. The first B bits of A, where B is configurable. > > > > Upon receipt of this payload, the initiator will be asked to compute A (using > > brute force methods) and send it back to the responder. > > This computation is possible with the aid of the first B bits of A. > > The responder will then proceed to do the modular exponentiations computations > > only if it got A from the initiator. > > > > Using these methods (and assuming that there is no efficient method to invert > > the MD5 function given MD5(A) and the first B bits of A) DoS attacks become very > > difficult. > > > > Notes: > > 1. Any other cryptographic hash function can be used. > > 2. If B is too small the initiator can refuse to carry out the exchange (so as > > not to spend to much resources). > > 3. This theoretically opens up another attack in which the attacker attacks the > > initiator (and not the responder) by sending him this payload. This in my mind > > is not such a serious problem, since in scenarios that allow this kind of > > attack, the DoS attacker instead of mounting this attack can simply pretend to > > be the responder making the initiator to do the modular exponentiations. > > > > Regards, > > Tamir. > > > > Regards, Tamir. From owner-ipsec@lists.tislabs.com Thu Feb 10 06:42: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 GAA02678; Thu, 10 Feb 2000 06:42:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13832 Thu, 10 Feb 2000 08:33:28 -0500 (EST) Message-ID: <38A2BF7E.9DF3AD59@checkpoint.com> Date: Thu, 10 Feb 2000 15:39:11 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Chris Trobridge CC: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <1FD60AE4DB6CD2118C420008C74C27B81D0386@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chris Trobridge wrote: > The defence lowers the responder's resource consumption /relative/ to the > attacker's, by raising the cost to the attacker. > > I do share your concerns about the effects on the initiator, although moving > the initial burden to the initiator does make sense in that it's probably a > lot harder to spoof a target into initiating a connection than responding to > one. Given that this is a defence against 'in the path' attackers, I think > it leaves the initiator open to attacks too. eg Modifying the challenge so > it is more difficult (or impossible!), or spoofing challenges where none was > requested. As I stated in my suggestion, an Initiator must not reply to any challenge it gets back, only challenges that do not take too much computational resources (The threshold should be configurable on the initiator). There is a trade-off between the level of security that the responder gets and the burden on the initiator. > I don't think the argument that initiator's are already open to > this type of attack is particularly compelling. What I was referring to was the fact that an attacker that can change packets can cause negotiations to fail. I agree that if an attacker has this ability and my suggestion is used, then an attacker can steal some more cpu cycles from the initiator (but it is still limited by the number of negotiations that the initiator is conducting). This kind of attack is considerably less effective than attacks on the responder. > > There's also an (Tamir) assumption about the relative costs of operations - > if you have modular maths hardware then the effect of brute forcing an hash > search could be far greater on other aspects of performance. It is also > much harder to make a task moderately tasking enough to deter a foe but not > inconvenience a legitimate initiator, given the way that processing power is > increasing. > > I think people should consider Ted's (Theodore) comments (philosophy?) about > defending against DOS. > > The main concerns appear to about resource attacks on the IPSEC machine by > an active attacker who is on the path between the legitimate parties. As > stated it's very hard to defend this attack other than making it hard for > the attacker to conceal their location. > > Chris > > > -----Original Message----- > > From: Valery Smyslov [mailto:svan@trustworks.com] > > Sent: 10 February 2000 09:25 > > To: Tamir Zegman > > Cc: ipsec@lists.tislabs.com > > Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs > > Addressing > > > > > > On 9 Feb 00, at 11:38, Tamir Zegman wrote: > > > > Hi, Tamir, > > > > please, see some comments below. > > > > First of all, a very similar idea was described in > > http://search.ietf.org/internet-drafts/draft-moskowitz-hip-01.txt > > > > But in both cases I'm puzzled what benefits will this approach lead > > to? In my understanding the way to defend responder against DoS > > attacks lies in lowering responder's resource consumption (both in > > memory and CPU) _while performing peer authentication_. The last > > addition is important. > > > > And, for example, stateless cookies do meet this requirement - they > > perform a weak peer authentication with minimum resource consumption. > > In this case responder's credo is "OK, I will talk to you if you > > proof that you're alive". It makes sense to me, because "to be alive" > > is some part of authentication. But what is responder's credo in your > > case? With your approach responder requires initiator to perform > > costly operation that doesn't add any bit to initiator > > authentication. Responder says: "OK, I will talk to you if you proof > > that you're alive and have substantial CPU power". Does it make any > > sense? > > > > In my understanding good DoS attack defending technique should > > protect responder from attacker _while still allowing legitimate > > initiator to perform connection_ (at least with some probability). > > Your approach deliberately prevents poor legitimate peers to connect > > when responder feels it is under attack. It is not DoS attack > > defending, it is a real DoS (Denial of Service) for such peers, so an > > attacker may celebrate... In this case I would prefer a simple > > "random drop" technique - at least it is more democratic :-) > > > > Best regards, > > Valera. Best Regards, Tamir. From owner-ipsec@lists.tislabs.com Thu Feb 10 07:18: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 HAA03170; Thu, 10 Feb 2000 07:18:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13946 Thu, 10 Feb 2000 09:04:12 -0500 (EST) Message-Id: <200002101409.RAA04921@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: Tamir Zegman Date: Thu, 10 Feb 2000 17:08:32 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing CC: ipsec@lists.tislabs.com In-reply-to: <38A2B5F1.360CD38C@checkpoint.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 10 Feb 00, at 14:58, Tamir Zegman wrote: Hi, Tamir, > Valery Smyslov wrote: > > > On 9 Feb 00, at 11:38, Tamir Zegman wrote: > > > > Hi, Tamir, > > > > please, see some comments below. > > > > First of all, a very similar idea was described in > > http://search.ietf.org/internet-drafts/draft-moskowitz-hip-01.txt > > > > But in both cases I'm puzzled what benefits will this approach lead > > to? In my understanding the way to defend responder against DoS > > attacks lies in lowering responder's resource consumption (both in > > memory and CPU) _while performing peer authentication_. The last > > addition is important. > > > > And, for example, stateless cookies do meet this requirement - they > > perform a weak peer authentication with minimum resource consumption. > > In this case responder's credo is "OK, I will talk to you if you > > proof that you're alive". It makes sense to me, because "to be alive" > > is some part of authentication. But what is responder's credo in your > > case? With your approach responder requires initiator to perform > > costly operation that doesn't add any bit to initiator > > authentication. Responder says: "OK, I will talk to you if you proof > > that you're alive and have substantial CPU power". Does it make any > > sense? > > > > In order to carry an effective DoS, an attacker needs to initiate a several (I'd say > hundreds) of simultaneous negotiations with the responder. > By using the method I propose, and assuming that the attacker computational power is > limited, only few negotiations will reach the stage in which the responder is needed > to perform the costly modular exponentiations. > Note that my proposal does not prevent an honest peer from performing the key exchange Yes, it may prevent. Simple example. An attacker initiates a lot of simultaneous negotiations so that responder decides he is "under attack". It begins to reply with your challenge setting B to very small value. At that time legitimate peer tries to connect, but gives up, because his CPU power is not high enough to be wasted for such a difficult task. He has got a real "Denial of Service". Even if he tried, a responer's state may get expired by the time he had finished. The same result. You just put "CPU power threshold" for everybody who want to connect to responder. > - > First of all the "Please reverse the hash function" challenge is only sent when the > responder suspects that it is being attacked. > Second, an honest initiator will only need to answer one of these challenges - a task > that it can no doubt perform - whereas an attacker will need to respond to several > hundreds in order for his attack to succeed. It depends on which attack he is trying to perform. You think that his goal is to exhaust responder's CPU power. I think, that his goal is to prevent legitimate peer to connect to responder. No doubt, your proposal saves responder from exhausting his CPU resources, but, in my opinion, doesn't prevent attacker from performing DoS attack against legitimate clients with low CPU power - he only needs to force responder suspect that he is being attacked. > > In my understanding good DoS attack defending technique should > > protect responder from attacker _while still allowing legitimate > > initiator to perform connection_ (at least with some probability). > > Your approach deliberately prevents poor legitimate peers to connect > > when responder feels it is under attack. > > This is a matter of configuration. If the challenge is as such that the number of cpu > cycles needed to answer it is in the order of let say the cpu cycles needed to perform > one modular exponentiation, then even poor legitimate peers would be able to respond, > whereas an attacker will need to invest at least a 100 times more cpu power in order > to succeed. Your approach lies in trying to offload responder and to distribute load among all the initiators, both honest and malicious. The problem is that responder gains no knowledge about initiator that successfully solved his challenge besides "he is powerful enough". In this light Kanta Matsuura's proposal seems to be more interesting, because it allows responder to simultaneously perform peer authentication. Best regards, Valera. > > It is not DoS attack > > defending, it is a real DoS (Denial of Service) for such peers, so an > > attacker may celebrate... In this case I would prefer a simple > > "random drop" technique - at least it is more democratic :-) > > > > Best regards, > > Valera. > > [...] > Regards, > Tamir. > > From owner-ipsec@lists.tislabs.com Thu Feb 10 07:20: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 HAA03200; Thu, 10 Feb 2000 07:20:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13984 Thu, 10 Feb 2000 09:11:09 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D0389@baltimore.com> From: Chris Trobridge To: ipsec@lists.tislabs.com Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Date: Thu, 10 Feb 2000 14:16:20 -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 > As I stated in my suggestion, an Initiator must not reply to > any challenge it gets back, only challenges that do not take too much computational > resources (The threshold should be configurable on the initiator). > There is a trade-off between the level of security that the > responder gets and the burden on the initiator. So the initiator needs to tell the responder how difficult a challenge it is prepared to accept and the responder needs to decide whether this is acceptable or not. Given the range of processing resource available to network devices and the rate of technological advance, it would be hard to pick the difficulty level. Also consider that the attacker could hand off this processing to a device(s) with far greater CPU resource, eg a compromised server. Now the responder could raise the difficulty level until it could keep up with the request level. Still, I think the benefits of this protection need to be considered against the perceived level of the threat, and the disruption and complexity added to the protocol - particularly relative to the alternative methods, eg random drop. Chris From owner-ipsec@lists.tislabs.com Thu Feb 10 17:52: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 RAA20675; Thu, 10 Feb 2000 17:52:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA16553 Thu, 10 Feb 2000 19:30:30 -0500 (EST) Date: Thu, 10 Feb 2000 18:35:25 -0600 From: Will Fiveash To: ipsec@lists.tislabs.com Subject: Re: Commit Bit and SPI? Message-ID: <20000210183525.A39074@austin.ibm.com> Mail-Followup-To: ipsec@lists.tislabs.com References: <01E1D01C12D7D211AFC70090273D20B102A1CC04@sothmxs06.entrust.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <01E1D01C12D7D211AFC70090273D20B102A1CC04@sothmxs06.entrust.com>; from greg.carter@entrust.com on Mon, Feb 07, 2000 at 10:57:26AM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Feb 07, 2000 at 10:57:26AM -0500, Greg Carter wrote: > Add one 'vote' for > - reply with one Notify only. SPIs not required, if there don't fail, > support people who already put them there but processing is not required. What does it mean if the SPI they send doesn't match any in the P2 SA bundle associated with the quick mode exchange? I think it would be best if the SPI is not sent but if it is then it must be associated with the P2 SA otherwise the negotiation should fail. > - to keep things simple, reflect commit bit. No optional reflecting and > what that might mean. Since I've already implemented CB I'm okay with this. -- Will Fiveash IBM AIX System Development From owner-ipsec@lists.tislabs.com Thu Feb 10 18:10: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 SAA21510; Thu, 10 Feb 2000 18:10:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16745 Thu, 10 Feb 2000 20:12:10 -0500 (EST) Date: Thu, 10 Feb 2000 19:17:27 -0600 From: Will Fiveash To: IETF IPSec Subject: Re: Commit Bit and SPI? Message-ID: <20000210191727.B39074@austin.ibm.com> Mail-Followup-To: IETF IPSec References: <20000203113740.B64112@austin.ibm.com> <200002041812.KAA08252@potassium.network-alchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <200002041812.KAA08252@potassium.network-alchemy.com>; from dharkins@Network-Alchemy.COM on Fri, Feb 04, 2000 at 10:12:33AM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, Feb 04, 2000 at 10:12:33AM -0800, Dan Harkins wrote: > The other issue is do you have to reflect back the bit if the peer sets > it or can you "negotiate" this capability? Well if you could choose to > reflect it what if the initiator sets it in Quick Mode message #3? Then we should restrict the initiator to turning on the bit in the first QM msg. The responder can turn it on in the second QM msg. If a implementation honors the CB then it should reflect it otherwise it does not. > Something has to be said to clear this up, yes. But it's a decision of > the WG. Do we send a notify for each SA pair containing the responder's > SPI(s) or do we send a single notify with no SPIs? Can we not reflect the > commit bit and if so what does that mean? Who can set the commit bit and > where should that be allowed and prohibited? If we can get some consensus > on this matter it'll go in the document but a unilateral decision by me > will only result in conflict. I understand your point which is why I brought this up on the mail-list. > I'm sorry you are disappointed in my lack of attention to this but the > IETF does not pay and consequently gets put in my queue at the appropriate > place. I'm trying but these are crazy times. Sorry about my snide comment. I guess I'm a little frustrated with the way some of the protocol details seem to get left up in the air (by the WG). -- Will Fiveash IBM AIX System Development From owner-ipsec@lists.tislabs.com Thu Feb 10 22:06: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 WAA02909; Thu, 10 Feb 2000 22:06:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17228 Thu, 10 Feb 2000 23:38:43 -0500 (EST) Date: Thu, 10 Feb 2000 23:26:47 -0500 (EST) From: Henry Spencer To: klaus.gross@web2cad.de cc: ipsec@lists.tislabs.com Subject: Re: More than one VPN-Connection from a gateway 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, 10 Feb 2000 klaus.gross@web2cad.de wrote: > I'm new in configuring a VPN and I > have the following question... You probably want to ask this question on a different mailing list, one specific to the particular software involved. This list is for technical discussion of the protocols themselves. (From some of the technical details you mention, you're almost certainly using Linux FreeS/WAN. See the documentation for the location, and details of how to join, the linux-ipsec mailing list.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Feb 10 22:07: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 WAA02932; Thu, 10 Feb 2000 22:07:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17242 Thu, 10 Feb 2000 23:41:25 -0500 (EST) To: sl531@cc.usu.edu Cc: itojun@iijlab.net, Aaron Griggs , MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipsec@lists.tislabs.com, ipng@sunroof.eng.sun.com In-Reply-To: Your message of "Sun, 06 Feb 2000 21:30:22 CST" From: Dave Johnson Reply-To: Dave Johnson Subject: Re: draft-ietf-mobileip-ipv6-09 Date: Thu, 10 Feb 2000 23:50:24 -0500 Message-ID: <19700.950244624@maredsous.monarch.cs.cmu.edu> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Hi, >I know very little about IPv6 mobility and security issues so correct me >if am wrong. Please UNICAST me your expert advice. > >1> Draft mention that while transmitting packet if corresponding node's >Binding cache has valid care_of_address entry for mobile node's home >address then it replaces later by former and append routing header with >later as last hop. Do the firewall entertain source routing ?? Firewalls *can* do anything they want to (unfortunately) but there is no reason that it should block packets containing such a routing header. >2> Also encapsulated packets from home agent can invade foreign network's >firewall. Is that acceptable ?? Again, there is no reason that a firewall should block such packets. >3> While registering primary care_of_address with its home agent mobile >node sends either an AH [9] or ESP [10] header providing sender >authentication, data integrity protection, and replay protection, via >Foreign Agent. Isn't that surrendering your secured data to foreign n/w ?? There are no foreign agents in Mobile IPv6 (they were optional in Mobile IPv4, but in Mobile IPv6, this is a simple IPv6 router). Also, the Binding Update is sent from the mobile node to the home agent using standard IPsec. I'm not sure what you mean by "surrendering your secured data" here, but the authentication (and optional encryption) is done directly between the mobile node and the home agent. Nothing is shared with the router or anyone else in the foreign network. >Thanks. > >Rajeeb Mishra Dave From owner-ipsec@lists.tislabs.com Fri Feb 11 10:30: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 KAA19667; Fri, 11 Feb 2000 10:30:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19327 Fri, 11 Feb 2000 12:18:05 -0500 (EST) From: tisc-pc@corecom.com Message-ID: <20000211172358.450.qmail@kiki.netreach.net> To: ipsec@lists.tislabs.com Subject: TISC April 24-28 2000 San Jose Date: Fri, 11 Feb 2000 17:23:58 GMT Mime-version: 1.0 Content-type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Fourth Internet Security Conference will be held April 24-28, 2000 in San Jose, CA, at the Fairmont Hotel. TISC is an educational forum for security professionals and practitioners. The TISC Security Symposium is an opportunity for individuals to share their expertise and practical experience with others involved in the design, implementation and deployment of networked security systems. To register, or to learn more about TISC workshops and symposium sessions, visit http://tisc.corecom.com One symposium track is dedicated to VPNs, where many topics related to IPSec will be discussed. We invite you to subscribe to the TISC bi-weekly newsletter, Insight, by visiting http://tisc.corecom.com/insight.html We hope to see you in San Jose! Regards, The TISC Advisory Board From owner-ipsec@lists.tislabs.com Fri Feb 11 10:36: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 KAA19743; Fri, 11 Feb 2000 10:36:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19257 Fri, 11 Feb 2000 11:54:34 -0500 (EST) Date: Fri, 11 Feb 2000 10:59:47 -0600 From: Will Fiveash To: Jan Vilhuber Cc: IETF IPSec Subject: Re: Commit Bit and SPI? Message-ID: <20000211105947.A39080@austin.ibm.com> Mail-Followup-To: Jan Vilhuber , IETF IPSec References: <20000210191727.B39074@austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: ; from vilhuber@cisco.com on Thu, Feb 10, 2000 at 06:30:36PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Feb 10, 2000 at 06:30:36PM -0800, Jan Vilhuber wrote: > On Thu, 10 Feb 2000, Will Fiveash wrote: > > Then we should restrict the initiator to turning on the bit in the first QM > > msg. The responder can turn it on in the second QM msg. If a > > implementation honors the CB then it should reflect it otherwise it does > > not. > > > I thought CB was a MUST, so everyone should be honoring it, or they're not > 'compliant' (whatever that means).. At the last bakeoff several vendors, including SSH, said they did not support Commit Bit or they supported the RFC2408 version (AS/400, 3Com). Of course if those who don't support the draft version of commit bit are willing to handle customer support when the finger pointing starts then please disregard my statements concerning the reflected negotiation of the CB. -- Will Fiveash From owner-ipsec@lists.tislabs.com Sun Feb 13 01:43: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 BAA28800; Sun, 13 Feb 2000 01:43:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25631 Sun, 13 Feb 2000 03:05:38 -0500 (EST) Message-ID: <38A6672D.20D13DD7@checkpoint.com> Date: Sun, 13 Feb 2000 10:11:25 +0200 From: Tamir Zegman Organization: Check Point X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Chris Trobridge CC: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <1FD60AE4DB6CD2118C420008C74C27B81D0389@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The following paper describes a similar approach. http://www.rsasecurity.com/rsalabs/staff/ajuels/papers/clientpuzzles.pdf Chris Trobridge wrote: > > As I stated in my suggestion, an Initiator must not reply to > > any challenge it gets back, only challenges that do not take too much > computational > > resources (The threshold should be configurable on the initiator). > > There is a trade-off between the level of security that the > > responder gets and the burden on the initiator. > > So the initiator needs to tell the responder how difficult a challenge it is > prepared to accept and the responder needs to decide whether this is > acceptable or not. > > Given the range of processing resource available to network devices and the > rate of technological advance, it would be hard to pick the difficulty > level. Also consider that the attacker could hand off this processing to a > device(s) with far greater CPU resource, eg a compromised server. > > Now the responder could raise the difficulty level until it could keep up > with the request level. Still, I think the benefits of this protection need > to be considered against the perceived level of the threat, and the > disruption and complexity added to the protocol - particularly relative to > the alternative methods, eg random drop. > > Chris From owner-ipsec@lists.tislabs.com Mon Feb 14 03:59: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 DAA03263; Mon, 14 Feb 2000 03:58:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA29025 Mon, 14 Feb 2000 05:27:02 -0500 (EST) Message-ID: <38A7D9B6.9D4FC12@sec.nl> Date: Mon, 14 Feb 2000 11:32:22 +0100 From: Jac Kloots Organization: SURFnet ExpertiseCentrum bv X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,nl MIME-Version: 1.0 To: Sandy Harris CC: ipsec@lists.tislabs.com Subject: Re: DNSSEC and IPsec References: <20000209062300.43ADDACAE2@smb.research.att.com> <38A12558.6313A41B@sec.nl> <38A15F20.F9006522@storm.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sandy Harris wrote: > > Jac Kloots wrote: > > > My question to this group is, Are there any IPsec implementations which > > use the DNSSEC information for authentication? > > We don't do it in the current release, but that is certainly on the > agenda, and a fairly high priority, for FreeS/WAN. > > http://www.freeswan.org Any idea how long this will take before I can take a look at this? Jac -- Jac Kloots SURFnet ExpertiseCentrum bv The Netherlands From owner-ipsec@lists.tislabs.com Mon Feb 14 10:37: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 KAA15715; Mon, 14 Feb 2000 10:37:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00286 Mon, 14 Feb 2000 12:07:43 -0500 (EST) Date: Fri, 11 Feb 2000 13:29:01 -0600 (CST) From: Tina Bird X-Sender: tbird@kuspy.phsx.ukans.edu To: Henry Spencer cc: klaus.gross@web2cad.de, ipsec@lists.tislabs.com Subject: Re: More than one VPN-Connection from a gateway In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry -- I'm forwarding your question to the VPN User's group list, vpn@securityfocus.com. To subscribe, send the message subscribe vpn your-e-mail-=address Lastname, Firstname to listserv@securityfocus.com. It's a vendor neutral list aimed at implementers and users of VPNs rather than developers. cheers -- Tina Bird VPN list moderator On Thu, 10 Feb 2000, Henry Spencer wrote: > Date: Thu, 10 Feb 2000 23:26:47 -0500 (EST) > From: Henry Spencer > To: klaus.gross@web2cad.de > Cc: ipsec@lists.tislabs.com > Subject: Re: More than one VPN-Connection from a gateway > > On Thu, 10 Feb 2000 klaus.gross@web2cad.de wrote: > > I'm new in configuring a VPN and I > > have the following question... > > You probably want to ask this question on a different mailing list, one > specific to the particular software involved. This list is for technical > discussion of the protocols themselves. > > (From some of the technical details you mention, you're almost certainly > using Linux FreeS/WAN. See the documentation for the location, and > details of how to join, the linux-ipsec mailing list.) > > Henry Spencer > henry@spsystems.net > "Doubt is an uncomfortable situation, but certainty is an absurd one." -- Voltaire From owner-ipsec@lists.tislabs.com Mon Feb 14 10:37: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 KAA15727; Mon, 14 Feb 2000 10:37:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00294 Mon, 14 Feb 2000 12:08:46 -0500 (EST) Message-ID: <20000214120702.10633.qmail@web1703.mail.yahoo.com> Date: Mon, 14 Feb 2000 04:07:02 -0800 (PST) From: Nishant Mishra Subject: Crypto API To: 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 studying various kinds of Crypto-APIs one can use to invoke cryptographic services from IPSec (BITS implementation), whole idea is to make cryptographic functionality of IPSec independent from actual IPSec implementation. I have following choices… 1. Simple crypto API (RFC 2628) 2. Microsoft crypto API 3. Common data secuirty architecture (CDSA) 4. GSS-API 5. PKCS #11 (Cryptoki) 6. RSA/Bsafe API May I know what is commonly used crypto API on Windows or Unix Platform for the purpose of Ipsec implementation? Also pl. mention if you are using a proprietary crypto APIs. Thanks in advance. Nishant __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-ipsec@lists.tislabs.com Mon Feb 14 12:40: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 MAA21183; Mon, 14 Feb 2000 12:40:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00895 Mon, 14 Feb 2000 14:02:54 -0500 (EST) Message-ID: <25D0C66E6D25D311B2AC0008C7913EE0494B0A@tdmail2.teledesic.com> From: "jay@TELEDESIC.COM" To: "'ipsec@lists.tislabs.com'" Date: Mon, 14 Feb 2000 10:58: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 From owner-ipsec@lists.tislabs.com Tue Feb 15 21:01: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 VAA15818; Tue, 15 Feb 2000 21:01:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA08089 Tue, 15 Feb 2000 20:16:08 -0500 (EST) Date: Tue, 15 Feb 2000 17:21:28 -0800 From: Skye Poier To: ipsec@lists.tislabs.com Subject: IPSec Complexity Message-ID: <20000215172128.B91663@ffwd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-URL: http://www.ffwd.com/ Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I just finished reading Niels Ferguson and Bruce Schneier's paper "A Cryptographic Evaluation of IPSec". They raise some interesting points, especially with regards to the complexity of the IPSec specification. I am working on a plan to integrate IPSec with our product line and the major hurdle seems to be supporting the different modes (tunnel vs transport) and protocols (AH vs ESP). In conclusion the paper recommends adopting ESP/tunnel mode with mandatory authentication and dropping the rest. This certainly appeals to me as we were already pondering the idea of using tunnel mode everywhere (host-host, host-sg, sg-sg) for simplicity. Has this topic already been discussed? What is the current status of the IPSec specification? Is it an evolving standard? I can't find any disadvantages to using tunnels mode everywhere, except for a slight increase in bandwidth usage. Comments? 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 Feb 16 11:59: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 LAA10940; Wed, 16 Feb 2000 11:59:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13198 Wed, 16 Feb 2000 13:08:29 -0500 (EST) Message-Id: <4.2.1.20000216101314.00bcd6f0@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 16 Feb 2000 10:15:32 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: IPSec Complexity In-Reply-To: <20000215172128.B91663@ffwd.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 2/15/00 -0800, Skye Poier wrote: >Has this topic already been discussed? In gory detail. See the archives at or , or , among other places. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Feb 17 08:21: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 IAA26127; Thu, 17 Feb 2000 08:21:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20042 Thu, 17 Feb 2000 09:47:20 -0500 (EST) Mime-Version: 1.0 X-Sender: macg@pop-server.austin.apc.slb.com (Unverified) Message-Id: In-Reply-To: <20000215172128.B91663@ffwd.com> References: <20000215172128.B91663@ffwd.com> Disposition-Notification-To: Date: Thu, 17 Feb 2000 08:52:43 -0600 To: ipsec@lists.tislabs.com From: "William I. MacGregor" Subject: Re: IPSec Complexity Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >In conclusion the paper recommends adopting ESP/tunnel mode with >mandatory authentication and dropping the rest. This certainly >appeals to me as we were already pondering the idea of using tunnel >mode everywhere (host-host, host-sg, sg-sg) for simplicity. > That has been my conclusion and recommendation in my own company, too, after more than a little testing. It was interesting to hear the Intel take on this at the RSA Conference. They suggested that transport mode is valuable on the LAN (i.e., not transiting firewalls) and tunnel mode in the WAN. Maybe (of course, they're selling IPSEC NICs). The Microsoft IPSEC-with-L2TP mode introduces another twist. Does IPSEC-with-L2TP pass through port forwarding NAT OK? This continues to be a major, major headache for us, and may be the make-or-break issue for the deployment of IPSEC in general use. There are lots of gateways doing Port Address Translation, and more all the time. Does IPSEC-with-L2TP make this easier, harder, neutral? Will it pass through devices like the Linksys box? We're going to see lots of these on broadband connects at home. Some of our guys have been testing IPSEC on portables on customers' LANs. To do this, they have to persuade the customer to allow the IPSEC services through the firewall. This is challenge enough, but if the customer is using PAT, it get *really* tough. "Uh, excuse me, would you mind renumbering your network, or changing the gateway to use realm specific addressing, please?" - Bill "At the end of the day, this is an ant farm with beepers." - Dennis Miller William I. MacGregor Schlumberger, 8311 North RR 620, P.O. Box 200015, Austin, TX 78720-0015 phone +1 512 331 3733, fax +1 512 331 3760 From owner-ipsec@lists.tislabs.com Thu Feb 17 09:35: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 JAA27718; Thu, 17 Feb 2000 09:35:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20752 Thu, 17 Feb 2000 11:26:10 -0500 (EST) Message-ID: <4148FEAAD879D311AC5700A0C969E8901CBFD6@orsmsx35.jf.intel.com> From: "Iyer, Prakash" To: "'William I. MacGregor'" , ipsec@lists.tislabs.com Subject: RE: IPSec Complexity Date: Thu, 17 Feb 2000 08:31:27 -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 L2TP over IPsec will break going thru' traditional NAT. Of course 1 IPsec tunnel can be support thru' NAT at a time by implementing a hack in NAT. But for a more generic solution, consider RSIP. -Prakash -----Original Message----- From: William I. MacGregor [mailto:macgregor@austin.apc.slb.com] Sent: Thursday, February 17, 2000 6:53 AM To: ipsec@lists.tislabs.com Subject: Re: IPSec Complexity >In conclusion the paper recommends adopting ESP/tunnel mode with >mandatory authentication and dropping the rest. This certainly >appeals to me as we were already pondering the idea of using tunnel >mode everywhere (host-host, host-sg, sg-sg) for simplicity. > That has been my conclusion and recommendation in my own company, too, after more than a little testing. It was interesting to hear the Intel take on this at the RSA Conference. They suggested that transport mode is valuable on the LAN (i.e., not transiting firewalls) and tunnel mode in the WAN. Maybe (of course, they're selling IPSEC NICs). The Microsoft IPSEC-with-L2TP mode introduces another twist. Does IPSEC-with-L2TP pass through port forwarding NAT OK? This continues to be a major, major headache for us, and may be the make-or-break issue for the deployment of IPSEC in general use. There are lots of gateways doing Port Address Translation, and more all the time. Does IPSEC-with-L2TP make this easier, harder, neutral? Will it pass through devices like the Linksys box? We're going to see lots of these on broadband connects at home. Some of our guys have been testing IPSEC on portables on customers' LANs. To do this, they have to persuade the customer to allow the IPSEC services through the firewall. This is challenge enough, but if the customer is using PAT, it get *really* tough. "Uh, excuse me, would you mind renumbering your network, or changing the gateway to use realm specific addressing, please?" - Bill "At the end of the day, this is an ant farm with beepers." - Dennis Miller William I. MacGregor Schlumberger, 8311 North RR 620, P.O. Box 200015, Austin, TX 78720-0015 phone +1 512 331 3733, fax +1 512 331 3760 From owner-ipsec@lists.tislabs.com Thu Feb 17 09:48: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 JAA28035; Thu, 17 Feb 2000 09:48:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20740 Thu, 17 Feb 2000 11:25:07 -0500 (EST) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE934C@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Skye Poier'" Cc: ipsec@lists.tislabs.com Subject: RE: IPSec Complexity Date: Thu, 17 Feb 2000 07:50:03 -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 Skye, Tunnel mode versus transport mode is one question I've changed my mind over the years and now disagree with Bruce. Elsewhere in his paper he says that complexity is the enemy of security. My feeling is that tunnel mode introduces lots of complexity into IPsec. Encapsulation/decapsulation per se is not the problem; tuunel and transport mode encapsulation/decpasulation can differ by a few tens of lines of code if you know what you're doing. The problem is the extra support infrastructure needed to make a tunneling protocol work. Generally this extra infrastructure won't be available unless you happen to build routers. A tunneling protocol alters the network topology, and doing this usually means the tunneling protocol has to interact with the underlying routing fabric somehow, or the whole system breaks. We see this today in the debate over whether to use DHCP or Config Payload to assign an IP address to a remote access client. This address assignment is only needed because we are tunneling, and it is not evident how this has anything to do with the security of the system, so should fall way outside the scope of the working group. On the other hand, a system based on tunneling really won't work without something like these mechanisms, so our architectural choice of tunneling has forced us to introduce seemingly gratuitous functionality. How does this help the security of the overall system? It doesn't. What seems to make more sense, at least to me, is to abolish tunnel mode and rely exclusively on transport mode. If someone wants or needs to tunnel, let her run her favorite tunneling protocol (GRE, HTTP, L2TP, etc.) over IPsec transport. My experience (but maybe no one else's) is that this always seems to lead to much simpler deployments. Steve Kent and others have argued against this strategy for years, as it throws away the access control mechanisms tunnel mode affords. Maybe the tunneling school is right, and it is a big mistake to try to separate tunneling from IPsec, just as it was a mistake in the original IPsec design to separate AH's functionality from ESP. But maybe a separation of tunneling from IPsec is feasible; maybe all we need to do to address their concern is to define a standard access control mechanism for tunneling protocols generally. I don't have a good answer to this question. Jesse Walker -----Original Message----- From: Skye Poier [mailto:skye@ffwd.com] Sent: Tuesday, February 15, 2000 5:21 PM To: ipsec@lists.tislabs.com Subject: IPSec Complexity Hello, I just finished reading Niels Ferguson and Bruce Schneier's paper "A Cryptographic Evaluation of IPSec". They raise some interesting points, especially with regards to the complexity of the IPSec specification. I am working on a plan to integrate IPSec with our product line and the major hurdle seems to be supporting the different modes (tunnel vs transport) and protocols (AH vs ESP). In conclusion the paper recommends adopting ESP/tunnel mode with mandatory authentication and dropping the rest. This certainly appeals to me as we were already pondering the idea of using tunnel mode everywhere (host-host, host-sg, sg-sg) for simplicity. Has this topic already been discussed? What is the current status of the IPSec specification? Is it an evolving standard? I can't find any disadvantages to using tunnels mode everywhere, except for a slight increase in bandwidth usage. Comments? 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 Thu Feb 17 10:24: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 KAA29335; Thu, 17 Feb 2000 10:24:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21211 Thu, 17 Feb 2000 12:23:23 -0500 (EST) Date: Thu, 17 Feb 2000 12:28:29 -0500 Message-Id: <200002171728.MAA21694@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: zegman@checkpoint.com Cc: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <1FD60AE4DB6CD2118C420008C74C27B81D0389@baltimore.com> <38A6672D.20D13DD7@checkpoint.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a concern about this notion of using puzzles as a way of addressing the DoS problem. It seems that there is an implied assumption in this approach: that the client is connecting to only one, or at most only a few, servers. In that case, the puzzles approach seems plausible because the client can afford the cost of solving a few puzzles as part of connection setup. On the other hand, what if your "client" is the hub of a hub & spoke topology VPN, and is initiating many IKE requests concurrently? We already have seen some topologies of this kind, where scaling is a concern. The cost of regular IKE exchanges (two DH operations plus typically some public key stuff) is already high enough to generate an interest in PKI accelerators. If the initiator is trying to initiate several hundred IKE exchanges, and in the process is hammered with several hundred puzzles, life is suddenly very unpleasant indeed. Note that the puzzles proposed so far aren't things you can accelerate with available "crypto hardware assist" devices. Let's be sure to keep this scenario in mind when analyzing proposed approaches. paul From owner-ipsec@lists.tislabs.com Thu Feb 17 11:57: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 LAA01640; Thu, 17 Feb 2000 11:57:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21689 Thu, 17 Feb 2000 13:47:23 -0500 (EST) Message-ID: <38AC432C.2BDB484F@mitel.com> Date: Thu, 17 Feb 2000 13:51:24 -0500 From: Dave Perks Organization: Mitel Corporation X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <1FD60AE4DB6CD2118C420008C74C27B81D0389@baltimore.com> <38A6672D.20D13DD7@checkpoint.com> <200002171728.MAA21694@tonga.xedia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > > I have a concern about this notion of using puzzles as a way of > addressing the DoS problem. For that matter, the recent much-publicized distributed DoS attacks on e-commerce servers point out that a similar attack on an IPsec server would have no problem overcoming a puzzle-based defence. The multitude of "zombie" attackers collectively has much more CPU power than any attacked system. -- The opinions expressed in this message are my personal opinion and in no way reflect the views of my employer. Søren Kierkegaard says "Life can only be understood backwards; but it must be lived forwards." From owner-ipsec@lists.tislabs.com Thu Feb 17 13:38: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 NAA03010; Thu, 17 Feb 2000 13:38:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22107 Thu, 17 Feb 2000 15:16:48 -0500 (EST) Date: Thu, 17 Feb 2000 15:22:06 -0500 From: "Michael H. Warfield" To: Dave Perks Cc: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Message-ID: <20000217152206.A2058@alcove.wittsend.com> References: <1FD60AE4DB6CD2118C420008C74C27B81D0389@baltimore.com> <38A6672D.20D13DD7@checkpoint.com> <200002171728.MAA21694@tonga.xedia.com> <38AC432C.2BDB484F@mitel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.2i In-Reply-To: <38AC432C.2BDB484F@mitel.com>; from Dave_Perks@mitel.com on Thu, Feb 17, 2000 at 01:51:24PM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, Feb 17, 2000 at 01:51:24PM -0500, Dave Perks wrote: > Paul Koning wrote: > > I have a concern about this notion of using puzzles as a way of > > addressing the DoS problem. > For that matter, the recent much-publicized distributed DoS attacks on > e-commerce servers point out that a similar attack on an IPsec server > would have no problem overcoming a puzzle-based defence. The multitude > of "zombie" attackers collectively has much more CPU power than any > attacked system. Actually, that reflects one of my worst nightmares. Have one of these kiddies marry a "cookie-crumbs" option into something like TFN2K and then take out some major coporation's VPN by doing in its ability to rekey. > -- > The opinions expressed in this message are my personal > opinion and in no way reflect the views of my employer. > Søren Kierkegaard says > "Life can only be understood backwards; but it must be lived forwards." -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Thu Feb 17 15:34: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 PAA04907; Thu, 17 Feb 2000 15:34:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22955 Thu, 17 Feb 2000 17:26:51 -0500 (EST) Message-ID: <38AC772E.282FB1A7@storm.ca> Date: Thu, 17 Feb 2000 17:33:18 -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: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <1FD60AE4DB6CD2118C420008C74C27B81D0389@baltimore.com> <38A6672D.20D13DD7@checkpoint.com> <200002171728.MAA21694@tonga.xedia.com> <38AC432C.2BDB484F@mitel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dave Perks wrote: > Paul Koning wrote: > > > > I have a concern about this notion of using puzzles as a way of > > addressing the DoS problem. Imposing extra overheads on the initiator as a way of reducing the risk of a DoS attack makes the attack more costly, but not less effective. As Paul poimts out, it also makes legitimate connections more costly. I don't think that problem is as serious as he suggests, but it is clearly a problem. > For that matter, the recent much-publicized distributed DoS attacks on > e-commerce servers point out that a similar attack on an IPsec server > would have no problem overcoming a puzzle-based defence. The multitude > of "zombie" attackers collectively has much more CPU power than any > attacked system. So the questions are: How to limit the responder's commitment of resources, both memory and CPU, on receipt of bogus connection requests, bogus ESP or AH packets, bogus anything the protocol specifies, and how to recover resources on discovering bogosity. I'm not certain there's much we can do to defend against bogus IPSEC packets. If the attacker can see some of our legitmate packets or knows who our partners are, then they can produce forged packets that we cannot reject until we've done the authentication, so an attacker can always force us to do authentication. If they can throw packets at us faster than we can test them, then they can always bog us down at least temporarily. I think this is a strong argument for rejecting Schneier and Ferguson's advice on one point. They argue that we should be authenticating plaintext instead of ciphertext, but if we did that, then we'd have to decrypt packets before we could authenticate and the overheads a DoS attacker could require of us would go way up. If they're right and we should be authenticating plaintext, then we need to do that as well as, not instead of, authenticating the encrypted packets. It is also, I think, an argument for leaving some "headroom" in your capacity planning for gateway servers. If you're specifying a gateway, it becomes a requirement that your IPSEC implementation be able to authenticate packets faster than your connection can deliver them. If you're building an implementation, you should test that it survives this attack and can recover to normal operation. As for bogus connection requests, making them expensive for the initiator doesn't solve the problem. We need to limit resource commitment in the responder, at least until we see the second packet from the initiator. We need to time out and recover resources if the second packet does not arrive. Finally, we need some form of 'cookie' that makes constructing a bogus second packet extremely difficult for an attacker who has not received our reply to the first. The attacker can likely get UDP 500 packets to us, and can construct packets of the appropriate types in sequence, but if we make this hard, he has a problem. As I read Simpson's lament, the main technical issue he raises is that IKE does not limit the responder's resource commitment appropriately. Can someone please give me a pointer to a refutation of that notion? Failing that, is there a solution to this problem? From owner-ipsec@lists.tislabs.com Thu Feb 17 15:36: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 PAA04940; Thu, 17 Feb 2000 15:36:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22954 Thu, 17 Feb 2000 17:26:50 -0500 (EST) From: Joe Touch Date: Thu, 17 Feb 2000 14:32:10 -0800 (PST) Message-Id: <200002172232.OAA27551@rum.isi.edu> To: ipsec@lists.tislabs.com, skye@ffwd.com Subject: Re: IPSec Complexity Cc: touch@ISI.EDU X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From owner-ipsec@lists.tislabs.com Tue Feb 15 17:44:09 2000 > Date: Tue, 15 Feb 2000 17:21:28 -0800 > From: Skye Poier > To: ipsec@lists.tislabs.com > Subject: IPSec Complexity > > Hello, > > I just finished reading Niels Ferguson and Bruce Schneier's paper > "A Cryptographic Evaluation of IPSec". They raise some interesting > points, especially with regards to the complexity of the IPSec > specification. I am working on a plan to integrate IPSec with our > product line and the major hurdle seems to be supporting the > different modes (tunnel vs transport) and protocols (AH vs ESP). > > In conclusion the paper recommends adopting ESP/tunnel mode with > mandatory authentication and dropping the rest. This certainly > appeals to me as we were already pondering the idea of using tunnel > mode everywhere (host-host, host-sg, sg-sg) for simplicity. ... > I can't find any disadvantages to using tunnels mode everywhere, except > for a slight increase in bandwidth usage. Comments? Yipe. I've already found that I need to use transport mode subsequent to vanilla tunneling (IP in IP) to allow dynamic routing to run inside an IPSEC'd overlay (VPN, if you prefer). The packets end up looking similar - just that vanilla_tunnel+transport IPSEC keys on the tunnel header, where transport keys on the inner header. This is how we got around the problem of integrating tunneling with routing. We let regular routing determine which vanilla tunnel to use, and the key rules remain static. Otherwise, we'd have to tie the key rules to the dynamic routing daemon, which is a pain. Has anyone else stumbled on this, and/or found this solution? (I can provide more detail if useful) Joe From owner-ipsec@lists.tislabs.com Thu Feb 17 21:51: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 VAA27127; Thu, 17 Feb 2000 21:51:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA24243 Thu, 17 Feb 2000 23:21:42 -0500 (EST) Date: Thu, 17 Feb 2000 23:25:38 -0500 (EST) From: Skip Booth To: Joe Touch cc: ipsec@lists.tislabs.com, skye@ffwd.com Subject: Re: IPSec Complexity In-Reply-To: <200002172232.OAA27551@rum.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 17 Feb 2000, Joe Touch wrote: > > From owner-ipsec@lists.tislabs.com Tue Feb 15 17:44:09 2000 > > Date: Tue, 15 Feb 2000 17:21:28 -0800 > > From: Skye Poier > > To: ipsec@lists.tislabs.com > > Subject: IPSec Complexity > > > > Hello, > > > > I just finished reading Niels Ferguson and Bruce Schneier's paper > > "A Cryptographic Evaluation of IPSec". They raise some interesting > > points, especially with regards to the complexity of the IPSec > > specification. I am working on a plan to integrate IPSec with our > > product line and the major hurdle seems to be supporting the > > different modes (tunnel vs transport) and protocols (AH vs ESP). > > > > In conclusion the paper recommends adopting ESP/tunnel mode with > > mandatory authentication and dropping the rest. This certainly > > appeals to me as we were already pondering the idea of using tunnel > > mode everywhere (host-host, host-sg, sg-sg) for simplicity. > > ... > > > I can't find any disadvantages to using tunnels mode everywhere, except > > for a slight increase in bandwidth usage. Comments? > > Yipe. I've already found that I need to use transport mode subsequent > to vanilla tunneling (IP in IP) to allow dynamic routing to run > inside an IPSEC'd overlay (VPN, if you prefer). I agree. One very nice thing about L2TP+IPSEC is that it looks like a network interface with security features versus a IPSEC in tunnel mode which is a layer 3 security transport. Since there is a PPP interface on top of L2TP, all the of the interface specific stuff runs transparent to IPSEC. There are no Routing protocol issues and standardized, well deployed MIBs are available for the interface. PPP and L2TP also give you built-in keepalives for interface maintenance. If we were to get rid of one mode for IPSEC, I certainly would cast my vote for getting rid of Tunnel Mode. I think this is probably a moot point though, since there are just too many implementations out there with tunnel mode. -Skip > > The packets end up looking similar - just that > vanilla_tunnel+transport IPSEC > keys on the tunnel header, where transport keys on the inner header. > > This is how we got around the problem of integrating tunneling with > routing. We let regular routing determine which vanilla tunnel > to use, and the key rules remain static. Otherwise, we'd have > to tie the key rules to the dynamic routing daemon, which is a pain. > > Has anyone else stumbled on this, and/or found this solution? > > (I can provide more detail if useful) > > Joe > > From owner-ipsec@lists.tislabs.com Fri Feb 18 03:58: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 DAA13619; Fri, 18 Feb 2000 03:58:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA26087 Fri, 18 Feb 2000 05:43:02 -0500 (EST) Message-ID: <38AD2338.8980131C@cisco.com> Date: Fri, 18 Feb 2000 11:47:20 +0100 From: Frederic Detienne Reply-To: fd@cisco.com Organization: Cisco Systems, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Skip Booth CC: Joe Touch , ipsec@lists.tislabs.com, skye@ffwd.com Subject: Re: IPSec Complexity References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Skip Booth wrote: > > On Thu, 17 Feb 2000, Joe Touch wrote: > > > > From owner-ipsec@lists.tislabs.com Tue Feb 15 17:44:09 2000 > > > Date: Tue, 15 Feb 2000 17:21:28 -0800 > > > From: Skye Poier > > > To: ipsec@lists.tislabs.com > > > Subject: IPSec Complexity > > > > > > Hello, > > > > > > I just finished reading Niels Ferguson and Bruce Schneier's paper > > > "A Cryptographic Evaluation of IPSec". They raise some interesting > > > points, especially with regards to the complexity of the IPSec > > > specification. I am working on a plan to integrate IPSec with our > > > product line and the major hurdle seems to be supporting the > > > different modes (tunnel vs transport) and protocols (AH vs ESP). > > > > > > In conclusion the paper recommends adopting ESP/tunnel mode with > > > mandatory authentication and dropping the rest. This certainly > > > appeals to me as we were already pondering the idea of using tunnel > > > mode everywhere (host-host, host-sg, sg-sg) for simplicity. > > > > ... > > > > > I can't find any disadvantages to using tunnels mode everywhere, except > > > for a slight increase in bandwidth usage. Comments? > > > > Yipe. I've already found that I need to use transport mode subsequent > > to vanilla tunneling (IP in IP) to allow dynamic routing to run > > inside an IPSEC'd overlay (VPN, if you prefer). > > I agree. One very nice thing about L2TP+IPSEC is that it looks like a network > interface with security features versus a IPSEC in tunnel mode which is a layer > 3 security transport. Since there is a PPP interface on top of L2TP, all the of > the interface specific stuff runs transparent to IPSEC. There are no Routing > protocol issues and standardized, well deployed MIBs are available for the > interface. PPP and L2TP also give you built-in keepalives for interface > maintenance. I think the presence of an IPSec tunnel interface is a matter of implementation. Nothing prevents you a priori from having such an interface and you could very well have the traffic run independent of the IPSec thing. But I agree L2TP has some advantages; it would help in not re-inventing the wheel with IPSec (thinking here of mode config). L2TP however does not have an inherent "configuration" advantage over an IPSec tunnel. > If we were to get rid of one mode for IPSEC, I certainly would cast my vote for > getting rid of Tunnel Mode. I think this is probably a moot point though, since > there are just too many implementations out there with tunnel mode. Yes. Though Transport mode has some drawbacks too. Especially when it comes to TCP. Look at an IPSec'ed TCP packet: IP ESP[transport] TCP payload Remember the TCP checksum is also calculated over a pseudo IP header. What now, if the packet is NATed ? The ip header is changed but the TCP checksum can not be recomputed since the NAT device may not have access to the TCP payload (or may not be able to recompute the authentication). This of course is only valid for end to end communication only. Notice I did not use AH since the AH authentication carries on a pseudo IP header too => inherently incompatible with NAT. In a tunnel, you do not have that problem: IP ESP[tunnel] IP TCP payload In this case, only the outmost IP header would be NATed and that would not harm the TCP checksum calculation. If you get rid of Tunnel mode, you have to use an other tunnel type (e.g. pptp or GRE or ...) and the packet would look like IP ESP[transport] GRE IP TCP payload In this case, things are still fine but you lose some bandwidth. (extra header). fred From owner-ipsec@lists.tislabs.com Fri Feb 18 06:16: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 GAA17111; Fri, 18 Feb 2000 06:16:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26797 Fri, 18 Feb 2000 07:59:59 -0500 (EST) From: Peter_Maricle@ne.3com.com X-Lotus-FromDomain: 3COM To: Joe Touch cc: ipsec@lists.tislabs.com Message-ID: <85256889.0047D6AD.00@usboxmta.ne.3com.com> Date: Fri, 18 Feb 2000 08:08:32 -0500 Subject: Re: IPSec Complexity Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can you please elaborate on your comment below? Especially your paragraph "The packets end up looking similar - just that ....". Joe Touch on 02/17/2000 05:32:10 PM Sent by: Joe Touch To: ipsec@lists.tislabs.com, skye@ffwd.com cc: touch@ISI.EDU (Peter Maricle/US/3Com) Subject: Re: IPSec Complexity > From owner-ipsec@lists.tislabs.com Tue Feb 15 17:44:09 2000 > Date: Tue, 15 Feb 2000 17:21:28 -0800 > From: Skye Poier > To: ipsec@lists.tislabs.com > Subject: IPSec Complexity > > Hello, > > I just finished reading Niels Ferguson and Bruce Schneier's paper > "A Cryptographic Evaluation of IPSec". They raise some interesting > points, especially with regards to the complexity of the IPSec > specification. I am working on a plan to integrate IPSec with our > product line and the major hurdle seems to be supporting the > different modes (tunnel vs transport) and protocols (AH vs ESP). > > In conclusion the paper recommends adopting ESP/tunnel mode with > mandatory authentication and dropping the rest. This certainly > appeals to me as we were already pondering the idea of using tunnel > mode everywhere (host-host, host-sg, sg-sg) for simplicity. ... > I can't find any disadvantages to using tunnels mode everywhere, except > for a slight increase in bandwidth usage. Comments? Yipe. I've already found that I need to use transport mode subsequent to vanilla tunneling (IP in IP) to allow dynamic routing to run inside an IPSEC'd overlay (VPN, if you prefer). The packets end up looking similar - just that vanilla_tunnel+transport IPSEC keys on the tunnel header, where transport keys on the inner header. This is how we got around the problem of integrating tunneling with routing. We let regular routing determine which vanilla tunnel to use, and the key rules remain static. Otherwise, we'd have to tie the key rules to the dynamic routing daemon, which is a pain. Has anyone else stumbled on this, and/or found this solution? (I can provide more detail if useful) Joe From owner-ipsec@lists.tislabs.com Fri Feb 18 07:41: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 HAA20280; Fri, 18 Feb 2000 07:41:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27138 Fri, 18 Feb 2000 09:28:45 -0500 (EST) Date: Fri, 18 Feb 2000 09:33:09 -0500 (EST) From: Skip Booth To: Frederic Detienne cc: Joe Touch , ipsec@lists.tislabs.com, skye@ffwd.com Subject: Re: IPSec Complexity In-Reply-To: <38AD2338.8980131C@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 18 Feb 2000, Frederic Detienne wrote: > Skip Booth wrote: > > > > On Thu, 17 Feb 2000, Joe Touch wrote: > > > > > > From owner-ipsec@lists.tislabs.com Tue Feb 15 17:44:09 2000 > > > > Date: Tue, 15 Feb 2000 17:21:28 -0800 > > > > From: Skye Poier > > > > To: ipsec@lists.tislabs.com > > > > Subject: IPSec Complexity > > > > > > > > Hello, > > > > > > > > I just finished reading Niels Ferguson and Bruce Schneier's paper > > > > "A Cryptographic Evaluation of IPSec". They raise some interesting > > > > points, especially with regards to the complexity of the IPSec > > > > specification. I am working on a plan to integrate IPSec with our > > > > product line and the major hurdle seems to be supporting the > > > > different modes (tunnel vs transport) and protocols (AH vs ESP). > > > > > > > > In conclusion the paper recommends adopting ESP/tunnel mode with > > > > mandatory authentication and dropping the rest. This certainly > > > > appeals to me as we were already pondering the idea of using tunnel > > > > mode everywhere (host-host, host-sg, sg-sg) for simplicity. > > > > > > ... > > > > > > > I can't find any disadvantages to using tunnels mode everywhere, except > > > > for a slight increase in bandwidth usage. Comments? > > > > > > Yipe. I've already found that I need to use transport mode subsequent > > > to vanilla tunneling (IP in IP) to allow dynamic routing to run > > > inside an IPSEC'd overlay (VPN, if you prefer). > > > > I agree. One very nice thing about L2TP+IPSEC is that it looks like a network > > interface with security features versus a IPSEC in tunnel mode which is a layer > > 3 security transport. Since there is a PPP interface on top of L2TP, all the of > > the interface specific stuff runs transparent to IPSEC. There are no Routing > > protocol issues and standardized, well deployed MIBs are available for the > > interface. PPP and L2TP also give you built-in keepalives for interface > > maintenance. > > I think the presence of an IPSec tunnel interface is a matter of > implementation. Nothing prevents you a priori from having such an interface > and you could very well have the traffic run independent of the IPSec thing. I agree to some degree. You certainly can implement a IPSEC tunnel interface. Not sure how many SA's you have to set up though. Would you negotiate a new SA for every new route you learned?. This would be very cumbersome for mesh connectivity as it would lead to a huge set of SA's. On the other hand I guess you could set your filters to encompass all traffic. You also cannot assume at this point that your peer also implements a IPSEC Tunnel interface design. There certainly is nothing in the current set of standards which addresses this issue. With L2TP + IPSEC you know that both peers have a PPP interface which is standardized so there are no interoperability issues here. > > But I agree L2TP has some advantages; it would help in not re-inventing the > wheel with IPSec (thinking here of mode config). L2TP however does not have > an inherent "configuration" advantage over an IPSec tunnel. Not sure what you mean here. PPP supports a very robust negotiation protocol for it's link layer characteristics (LCP), and it's network protocols (NCPs). IPCP is the control protocol which PPP uses to set up IP. IPCP already supports address, DNS, WINS, and Gateway assignment. > > > If we were to get rid of one mode for IPSEC, I certainly would cast my vote for > > getting rid of Tunnel Mode. I think this is probably a moot point though, since > > there are just too many implementations out there with tunnel mode. > > Yes. Though Transport mode has some drawbacks too. Especially when it comes > to TCP. Look at an IPSec'ed TCP packet: > > IP ESP[transport] TCP payload > > Remember the TCP checksum is also calculated over a pseudo IP header. What > now, if the packet is NATed ? The ip header is changed but the TCP checksum > can not be recomputed since the NAT device may not have access to the TCP > payload (or may not be able to recompute the authentication). > > This of course is only valid for end to end communication only. > > Notice I did not use AH since the AH authentication carries on a pseudo IP > header too => inherently incompatible with NAT. > > > In a tunnel, you do not have that problem: > > IP ESP[tunnel] IP TCP payload > > In this case, only the outmost IP header would be NATed and that would not > harm the TCP checksum calculation. > > If you get rid of Tunnel mode, you have to use an other tunnel type (e.g. > pptp or GRE or ...) and the packet would look like > > IP ESP[transport] GRE IP TCP payload > > In this case, things are still fine but you lose some bandwidth. (extra header). Very little difference depending on the header compression you use for the tunneling protocol. -Skip > > > fred > From owner-ipsec@lists.tislabs.com Fri Feb 18 08:34: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 IAA23206; Fri, 18 Feb 2000 08:34:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27340 Fri, 18 Feb 2000 10:07:05 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 18 Feb 2000 10:10:08 -0500 To: Skip Booth From: Stephen Kent Subject: Re: IPSec Complexity Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Skip, Unfortunately, IPsec over L2TP looses many of the access control features of IPsec, because the receiver no longer examines the inner IP header to see if it matches the selectors for the SA via which the packet arrived. Since the SA binding is lost as soon as the packet leaves the IPsec processing, no later filtering can provide the same sort of checks. Steve From owner-ipsec@lists.tislabs.com Fri Feb 18 09:00: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 JAA23728; Fri, 18 Feb 2000 09:00:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27487 Fri, 18 Feb 2000 10:31:22 -0500 (EST) Date: Fri, 18 Feb 2000 10:36:17 -0500 (EST) From: Skip Booth To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: IPSec Complexity 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 Fri, 18 Feb 2000, Stephen Kent wrote: > Skip, > > Unfortunately, IPsec over L2TP looses many of the access control > features of IPsec, because the receiver no longer examines the inner > IP header to see if it matches the selectors for the SA via which the > packet arrived. Since the SA binding is lost as soon as the packet > leaves the IPsec processing, no later filtering can provide the same > sort of checks. This argument has been made many at time so I doubt I am going to shed very much new information on it. However, my perception is that the only loss incurred is the ability to provide different levels of security for different traffic between two peers. For instance the ability to say, FTP traffic gets 3DES and SHA with lifetimes of 10 min and Telnet gets DES and MD5 with as lifetime of 15 minutes. Since the traffic is hidden underneath the PPP header for L2TP you lose this ability. In terms of pure access control, the filters can be applied to the PPP interface and achieve the same result as if they were applied to the IPSEC tunnel. Again the only loss is that the PPP interface can not tell which SA the packet arrived on, but it does know that they packet was at least secured with the appropriate L2TP security policy. I am not sure how many customers are really going to worry whether there FTP traffic has different security parameters than their telnet traffic. I think for the most part, they will have one security policy for their VPN, and in this case, L2TP should do just fine. The simplicity argument will most likely prevail in this case. -Skip > > Steve > > From owner-ipsec@lists.tislabs.com Fri Feb 18 09:04: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 JAA23831; Fri, 18 Feb 2000 09:04:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27593 Fri, 18 Feb 2000 10:46:57 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 18 Feb 2000 10:52:12 -0500 To: Skip Booth From: Stephen Kent Subject: Re: IPSec Complexity Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Skip, I think the problem is much worse than your example suggests. If a site has SAs to multiple other sites or multiple dialup users, then once the traffic pops out of an SA, the rest of the receiver system does not know which SA the traffic came from (assuming modular layering of the pieces of the receiver system). Thus any filtering that is applied to the inner header can determine only if ANY legitimate source is allowed to send traffic of a specific form, not whether the sender in question was allowed to send the traffic in question. Thus any source can spoof traffic that would be acceptable if it came from any other source with which the receiver is willing to communicate. In the worst case, the scope of this spoofing applies to sources irrespective of whether such sources have SAs in place at the time the traffic arrives. This is the sort of problem I was referring to as a side effect of disassociating access control filtering from IPsec. Steve From owner-ipsec@lists.tislabs.com Fri Feb 18 09:44: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 JAA24706; Fri, 18 Feb 2000 09:44:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27726 Fri, 18 Feb 2000 11:28:33 -0500 (EST) Date: Fri, 18 Feb 2000 11:33:54 -0500 Message-Id: <200002181633.LAA05059@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fd@cisco.com Cc: ebooth@cisco.com, touch@ISI.EDU, ipsec@lists.tislabs.com, skye@ffwd.com Subject: Re: IPSec Complexity References: <38AD2338.8980131C@cisco.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Frederic" == Frederic Detienne writes: Frederic> Skip Booth wrote: >> On Thu, 17 Feb 2000, Joe Touch wrote: >> > > Yipe. I've already found that I need to use transport mode subsequent > > to vanilla tunneling (IP in IP) to allow dynamic routing to run > > inside an IPSEC'd overlay (VPN, if you prefer). > > I agree. One very nice thing about L2TP+IPSEC is that it looks like a network > interface with security features versus a IPSEC in tunnel mode which is a layer > 3 security transport. Since there is a PPP interface on top of L2TP, all the of > the interface specific stuff runs transparent to IPSEC. There are no Routing > protocol issues and standardized, well deployed MIBs are available for the > interface. PPP and L2TP also give you built-in keepalives for interface > maintenance. Frederic> I think the presence of an IPSec tunnel interface is a Frederic> matter of implementation. Nothing prevents you a priori Frederic> from having such an interface and you could very well have Frederic> the traffic run independent of the IPSec thing. Agreed. We're running routing protocols over IPsec tunnels without any trouble. There's nothing I know of that requires you to use L2TP or other extraneous protocols. Look at it another way: if tunnel protocol X is suitable, why not tunnel protocol Y? paul From owner-ipsec@lists.tislabs.com Fri Feb 18 10:21: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 KAA25733; Fri, 18 Feb 2000 10:21:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27813 Fri, 18 Feb 2000 11:55:20 -0500 (EST) Message-ID: <38AD7A8C.DD010D8B@cisco.com> Date: Fri, 18 Feb 2000 11:59:56 -0500 From: "W. Mark Townsley" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Stephen Kent CC: Skip Booth , ipsec@lists.tislabs.com Subject: Re: IPSec Complexity References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > Skip, > > I think the problem is much worse than your example suggests. If a > site has SAs to multiple other sites or multiple dialup users, then > once the traffic pops out of an SA, the rest of the receiver system > does not know which SA the traffic came from (assuming modular The receiver system does in fact know which SA the traffic came from, albeit indirectly. The filters that Skip is referring to are applied on a per user basis, based upon the authenticated PPP user. There is, in turn, a direct linkage between this PPP user, L2TP, and ultimately the IPsec SA. IPsec of course ensures that only L2TP data can arrive on that particular SA. > layering of the pieces of the receiver system). Thus any filtering > that is applied to the inner header can determine only if ANY Again, the filtering that is applied on the inner header is applied only to a single PPP data stream, which arrives over single L2TP session that is associated with a single IPsec SA. > legitimate source is allowed to send traffic of a specific form, not > whether the sender in question was allowed to send the traffic in > question. Thus any source can spoof traffic that would be acceptable > if it came from any other source with which the receiver is willing > to communicate. In the worst case, the scope of this spoofing applies > to sources irrespective of whether such sources have SAs in place at > the time the traffic arrives. This is the sort of problem I was > referring to as a side effect of disassociating access control > filtering from IPsec. This is a side effect only if your filters are applied globally to all data coming from IPsec. > > Steve From owner-ipsec@lists.tislabs.com Fri Feb 18 10:37: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 KAA26284; Fri, 18 Feb 2000 10:37:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27904 Fri, 18 Feb 2000 12:06:00 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D044A@baltimore.com> From: Chris Trobridge To: ipsec@lists.tislabs.com Subject: RE: IPSec Complexity Date: Fri, 18 Feb 2000 17:11:20 -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 trouble is that Transport mode isn't adequate for Security Gateways (which is why it's only allowed for end to end, I guess). The only way around this would be, as I think someone's already said, is to perform IP in IP tunneling first and then use Transport mode. Chris > -----Original Message----- > From: Skip Booth [mailto:ebooth@cisco.com] > Sent: 18 February 2000 04:26 > To: Joe Touch > Cc: ipsec@lists.tislabs.com; skye@ffwd.com > Subject: Re: IPSec Complexity > If we were to get rid of one mode for IPSEC, I certainly > would cast my vote for > getting rid of Tunnel Mode. I think this is probably a moot > point though, since > there are just too many implementations out there with tunnel mode. > > -Skip From owner-ipsec@lists.tislabs.com Fri Feb 18 10:38: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 KAA26314; Fri, 18 Feb 2000 10:38:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28024 Fri, 18 Feb 2000 12:26:53 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <1FD60AE4DB6CD2118C420008C74C27B81D044A@baltimore.com> References: <1FD60AE4DB6CD2118C420008C74C27B81D044A@baltimore.com> Date: Fri, 18 Feb 2000 12:29:16 -0500 To: Chris Trobridge From: Stephen Kent Subject: RE: IPSec Complexity Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chris, If you do IP in IP tunneling, and then apply transport mode, you will suffer the access control problems I described earlier, because transport mode IPsec looks only at the outer IP header, not the inner one. Also, you will not be complaint with the IPsec Architecture as defined in RFC 2401. Steve From owner-ipsec@lists.tislabs.com Fri Feb 18 11:02: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 LAA27449; Fri, 18 Feb 2000 11:02:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28196 Fri, 18 Feb 2000 12:44:04 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D044B@baltimore.com> From: Chris Trobridge To: ipsec@lists.tislabs.com Subject: RE: IPSec Complexity Date: Fri, 18 Feb 2000 17:49:22 -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: Stephen Kent [mailto:kent@bbn.com] > Sent: 18 February 2000 17:29 > To: Chris Trobridge > Cc: ipsec@lists.tislabs.com > Subject: RE: IPSec Complexity > > > Chris, > > If you do IP in IP tunneling, and then apply transport mode, you > will suffer the access control problems I described earlier, because > transport mode IPsec looks only at the outer IP header, not the inner > one. Also, you will not be complaint with the IPsec Architecture as > defined in RFC 2401. > > Steve I agree - I think we need tunneling. If you regard IP tunnelling as a separate 'module' then the datagrams are being sent end to end and I think transport mode would then be compliant (ie the datagrams are already tunneled before they reach IPSEC). However, this means that the whole tunneling process is outside of the control of IPSEC and you can impose IPSEC policy on the traffic carried hence the access control problem. Chris From owner-ipsec@lists.tislabs.com Fri Feb 18 11:12: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 LAA27793; Fri, 18 Feb 2000 11:12:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28281 Fri, 18 Feb 2000 12:56:38 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <38AD7A8C.DD010D8B@cisco.com> References: <38AD7A8C.DD010D8B@cisco.com> Date: Fri, 18 Feb 2000 12:53:25 -0500 To: "W. Mark Townsley" From: Stephen Kent Subject: Re: IPSec Complexity Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk mark, The description you provide for filtering seems plausible, but is not in any standard. It implies a linkage between PPP, L2TP, and IPsec that is not defined in any of those standards. Also, in other than the dialup user case, e.g., in extranets and intranets based on IPsec, it is not clear that the same linkages will occur. So, I guess I'm willing to believe that a vendor could create an implementation that maintained the SA linkages you describe, but it would appear that such linkages would be outside the scope of all the relevant standards. Not being a fan of relying on vendor-specific implementation conventions to achieve security, I can't be too enthusiastic about this approach. Steve From owner-ipsec@lists.tislabs.com Fri Feb 18 11: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 LAA27944; Fri, 18 Feb 2000 11:16:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28326 Fri, 18 Feb 2000 12:59:46 -0500 (EST) Message-Id: <200002181802.KAA05507@potassium.network-alchemy.com> To: Skip Booth cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: IPSec Complexity In-reply-to: Your message of "Fri, 18 Feb 2000 10:36:17 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5500.950896963.1@network-alchemy.com> Date: Fri, 18 Feb 2000 10:02:43 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's not just deciding whether to protect a certain flow with 3DES and SHA and the other with DES and MD5 (your example). A selector can also specify an action of "drop". If you tunnel something through UDP and do IPSec protection on the UDP traffic then you're opening up your entire network to whatever the peer decides to put in the tunnel. You're right that most people won't really care that much whether FTP and telnet have different algorithms applied to protect them but they would probably care if putting a protect selector for L2TP, e.g. "10.10.10.1 udp <---> 172.16.2.1 udp 1701 protect" would implicitly make a bypass selector for everything, e.g. "any <--> any allow" Dan. On Fri, 18 Feb 2000 10:36:17 EST you wrote > > On Fri, 18 Feb 2000, Stephen Kent wrote: > > > Skip, > > > > Unfortunately, IPsec over L2TP looses many of the access control > > features of IPsec, because the receiver no longer examines the inner > > IP header to see if it matches the selectors for the SA via which the > > packet arrived. Since the SA binding is lost as soon as the packet > > leaves the IPsec processing, no later filtering can provide the same > > sort of checks. > > This argument has been made many at time so I doubt I am going to shed very m >uch > new information on it. However, my perception is that the only loss incurred > is > the ability to provide different levels of security for different traffic > between two peers. For instance the ability to say, FTP traffic gets 3DES an >d > SHA with lifetimes of 10 min and Telnet gets DES and MD5 with as lifetime of >15 > minutes. Since the traffic is hidden underneath the PPP header for L2TP you > lose this ability. > > In terms of pure access control, the filters can be applied to the PPP interf >ace > and achieve the same result as if they were applied to the IPSEC tunnel. Aga >in > the only loss is that the PPP interface can not tell which SA the packet arri >ved > on, but it does know that they packet was at least secured with the appropria >te > L2TP security policy. > > I am not sure how many customers are really going to worry whether there FTP > traffic has different security parameters than their telnet traffic. I think > for the most part, they will have one security policy for their VPN, and in t >his > case, L2TP should do just fine. The simplicity argument will most likely > prevail in this case. > > -Skip > > > > > Steve > > > > > From owner-ipsec@lists.tislabs.com Fri Feb 18 11:48: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 LAA29151; Fri, 18 Feb 2000 11:48:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28524 Fri, 18 Feb 2000 13:25:20 -0500 (EST) Date: Fri, 18 Feb 2000 20:30:30 +0200 (EET) From: Markku Savela Message-Id: <200002181830.UAA07963@anise.tte.vtt.fi> To: CTrobridge@baltimore.com CC: ipsec@lists.tislabs.com In-reply-to: <1FD60AE4DB6CD2118C420008C74C27B81D044A@baltimore.com> (message from Chris Trobridge on Fri, 18 Feb 2000 17:11:20 -0000) Subject: RE: IPSec Complexity Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Chris Trobridge The only way around > this would be, as I think someone's already said, is to perform IP > in IP tunneling first and then use Transport mode. On the wire the tunnel mode is *exactly* same as transport mode applied to IPIP tunnel. Bitstreams are identical. One end could be applying IPSEC transport mode to IPIP tunnel, and other end could be doing IPSEC in tunnel mode, and they can communicate quite okay. I still cannot see any complexity in the basic kernel IPSEC implementation (although AH interactions with Mobile IP in IPv6 is scaring me a bit, but we shall see when I get that far...) -- msa From owner-ipsec@lists.tislabs.com Fri Feb 18 12:00: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 MAA29608; Fri, 18 Feb 2000 12:00:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28643 Fri, 18 Feb 2000 13:41:30 -0500 (EST) Date: Fri, 18 Feb 2000 13:46:24 -0500 (EST) From: Skip Booth To: Dan Harkins cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: IPSec Complexity In-Reply-To: <200002181802.KAA05507@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 18 Feb 2000, Dan Harkins wrote: > It's not just deciding whether to protect a certain flow with 3DES and > SHA and the other with DES and MD5 (your example). A selector can also > specify an action of "drop". If you tunnel something through UDP and > do IPSec protection on the UDP traffic then you're opening up your entire > network to whatever the peer decides to put in the tunnel. > > You're right that most people won't really care that much whether FTP > and telnet have different algorithms applied to protect them but they > would probably care if putting a protect selector for L2TP, e.g. > "10.10.10.1 udp <---> 172.16.2.1 udp 1701 protect" > would implicitly make a bypass selector for everything, e.g. > "any <--> any allow" The default filter in the SPD MUST be discard. So I don't think you are talking about the non-L2TP traffic since unless there are explicit pass statements in the SPD for the non-L2TP traffic the packets will be dropped. I assume you are talking about the traffic within the L2TP+IPSEC tunnel. You are right that without additional filters on the PPP interfaces associated with the secure tunnel, all traffic is permitted as long as it arrived on the SA bundle protecting L2TP. On the other hand, if only FTP and Telnet traffic is permitted to servers X, Y, and Z, these filters could be defined on the PPP interface. This configuration moves very transparently in this case, since in many cases you are essentially replacing a leased/dialup line running PPP with a virtual PPP interface running on top of secure IP. -Skip > > Dan. > > On Fri, 18 Feb 2000 10:36:17 EST you wrote > > > > On Fri, 18 Feb 2000, Stephen Kent wrote: > > > > > Skip, > > > > > > Unfortunately, IPsec over L2TP looses many of the access control > > > features of IPsec, because the receiver no longer examines the inner > > > IP header to see if it matches the selectors for the SA via which the > > > packet arrived. Since the SA binding is lost as soon as the packet > > > leaves the IPsec processing, no later filtering can provide the same > > > sort of checks. > > > > This argument has been made many at time so I doubt I am going to shed very m > >uch > > new information on it. However, my perception is that the only loss incurred > > is > > the ability to provide different levels of security for different traffic > > between two peers. For instance the ability to say, FTP traffic gets 3DES an > >d > > SHA with lifetimes of 10 min and Telnet gets DES and MD5 with as lifetime of > >15 > > minutes. Since the traffic is hidden underneath the PPP header for L2TP you > > lose this ability. > > > > In terms of pure access control, the filters can be applied to the PPP interf > >ace > > and achieve the same result as if they were applied to the IPSEC tunnel. Aga > >in > > the only loss is that the PPP interface can not tell which SA the packet arri > >ved > > on, but it does know that they packet was at least secured with the appropria > >te > > L2TP security policy. > > > > I am not sure how many customers are really going to worry whether there FTP > > traffic has different security parameters than their telnet traffic. I think > > for the most part, they will have one security policy for their VPN, and in t > >his > > case, L2TP should do just fine. The simplicity argument will most likely > > prevail in this case. > > > > -Skip > > > > > > > > Steve > > > > > > > > > > From owner-ipsec@lists.tislabs.com Fri Feb 18 12:01: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 MAA29668; Fri, 18 Feb 2000 12:01:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28602 Fri, 18 Feb 2000 13:37:47 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200002181830.UAA07963@anise.tte.vtt.fi> References: <200002181830.UAA07963@anise.tte.vtt.fi> Date: Fri, 18 Feb 2000 13:37:13 -0500 To: msa@hemuli.tte.vtt.fi (Markku Savela) From: Stephen Kent Subject: RE: IPSec Complexity Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markku, Protocols are not defined ONLY by the bits on the wire. They also are defined by the processing that each end applies to the packets. Since the IPsec processing applied by a receiver differs for a transport mode vs. tunnel mode packet, the two protocols are not the same, even if IP-in-IP tunneling is employed with transport mode. Steve From owner-ipsec@lists.tislabs.com Fri Feb 18 12:13: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 MAA00380; Fri, 18 Feb 2000 12:13:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28764 Fri, 18 Feb 2000 13:57:58 -0500 (EST) Message-Id: <200002181900.LAA20369@potassium.network-alchemy.com> To: Skip Booth cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: IPSec Complexity In-reply-to: Your message of "Fri, 18 Feb 2000 13:46:24 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20366.950900456.1@network-alchemy.com> Date: Fri, 18 Feb 2000 11:00:56 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Remember the title of this thread is "IPSec Complexity". It started out as a way to get rid of a mode while maintining the functionality of tunneling. There are security issues with that. So now have come full circle when the solution to address the security problems (and still have tunneling and still get rid of one mode) is more complex than the original tunneling design. Dan. On Fri, 18 Feb 2000 13:46:24 EST you wrote > > I assume you are talking about the traffic within the L2TP+IPSEC tunnel. You > are right that without additional filters on the PPP interfaces associated wi >th > the secure tunnel, all traffic is permitted as long as it arrived on the SA > bundle protecting L2TP. On the other hand, if only FTP and Telnet traffic is > permitted to servers X, Y, and Z, these filters could be defined on the PPP > interface. This configuration moves very transparently in this case, since i >n > many cases you are essentially replacing a leased/dialup line running PPP wit >h a > virtual PPP interface running on top of secure IP. From owner-ipsec@lists.tislabs.com Fri Feb 18 12:33: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 MAA01036; Fri, 18 Feb 2000 12:33:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28812 Fri, 18 Feb 2000 14:10:49 -0500 (EST) Message-ID: <38AD9A3B.F2896693@cisco.com> Date: Fri, 18 Feb 2000 14:15:07 -0500 From: "W. Mark Townsley" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: IPSec Complexity References: <38AD7A8C.DD010D8B@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > mark, > > The description you provide for filtering seems plausible, but is not > in any standard. It implies a linkage between PPP, L2TP, and IPsec The linkage between IPsec and L2TP is a standards track document (draft-ietf-pppext-l2tp-security-05.txt). The linkage between L2TP and PPP is a standards track RFC (RFC 2661). The only missing element is the requirement of filters at the virtual PPP interface actually defined in an RFC. Filtering traffic on an interface or based on a PPP user is something that PPP Remote Access vendors have done for years. Since there are no bits on the wire required of these features, I suspect that the WG did not see fit to write up an RFC. However, if we really, really, really, need an RFC for it to be real, that could certainly be accomplished if we found the people with the time to write it up and charter under which to publish it. However, the more important thing to me and my customers is that the given functionality exists and is available from multiple vendors. That is certainly the case throughout the industry now. The fact that it is not in an RFC is purely academic (again, which is not to say that it is not worthwhile to document). > that is not defined in any of those standards. Also, in other than > the dialup user case, e.g., in extranets and intranets based on > IPsec, it is not clear that the same linkages will occur. > > So, I guess I'm willing to believe that a vendor could create an > implementation that maintained the SA linkages you describe, but it In fact, by linking L2TP and IPsec, you get the filter linkages described for free. We have been doing remote access for years via leased lines and dialup connections. We have filtering techniques galore for these at either end of the connection. When you add IPsec for a VPN, in a sense you are simply replacing the leased line with a tunneled connection over the Internet. Securing that connection is necessary given that the internet is a shared public medium, but I do not see why the filter techniques defined in an IPsec RFC are any more real than those we have already been using for years. In fact, I think it makes the transistion much easier for customers to NOT define a whole new protocol, but rather to use what they are already familiar with. > would appear that such linkages would be outside the scope of all the > relevant standards. Not being a fan of relying on vendor-specific > implementation conventions to achieve security, I can't be too > enthusiastic about this approach. > > Steve From owner-ipsec@lists.tislabs.com Fri Feb 18 12:34: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 MAA01080; Fri, 18 Feb 2000 12:34:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28851 Fri, 18 Feb 2000 14:14:44 -0500 (EST) From: Sudeep_Khuraijam@3com.com X-Lotus-FromDomain: 3COM To: Dan Harkins cc: Skip Booth , Stephen Kent , ipsec@lists.tislabs.com Message-ID: <88256889.0069FA73.00@hqoutbound.ops.3com.com> Date: Fri, 18 Feb 2000 11:20:03 -0800 Subject: Re: IPSec Complexity Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > It's not just deciding whether to protect a certain flow with 3DES and >SHA and the other with DES and MD5 (your example). A selector can also >specify an action of "drop". If you tunnel something through UDP and >do IPSec protection on the UDP traffic then you're opening up your entire >network to whatever the peer decides to put in the tunnel. > You're right that most people won't really care that much whether FTP >and telnet have different algorithms applied to protect them but they >would probably care if putting a protect selector for L2TP, e.g. > "10.10.10.1 udp <---> 172.16.2.1 udp 1701 protect" >would implicitly make a bypass selector for everything, e.g. > "any <--> any allow" Not so, if we step out side the IPSec only paradigm. It is inadequate to assume that IPSec will replace/reinvent all access control policies that have been in place. There are gateways that can apply on the fly ACLs on per connection basis. Such policies can be defined per group/per user/per host and deployed via LDAP. Using Selector lists to define access control does not scale and is operationally inefficient. Sudeep From owner-ipsec@lists.tislabs.com Fri Feb 18 12:35: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 MAA01139; Fri, 18 Feb 2000 12:35:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28927 Fri, 18 Feb 2000 14:21:27 -0500 (EST) Date: Fri, 18 Feb 2000 14:26:20 -0500 (EST) From: Skip Booth To: Dan Harkins cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: IPSec Complexity In-Reply-To: <200002181900.LAA20369@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 18 Feb 2000, Dan Harkins wrote: > Remember the title of this thread is "IPSec Complexity". It started > out as a way to get rid of a mode while maintining the functionality of > tunneling. There are security issues with that. So now have come full > circle when the solution to address the security problems (and still > have tunneling and still get rid of one mode) is more complex than the > original tunneling design. I don't think it is any more complex. It does removes one mode from IPSEC and it builds upon infrastuctures which already exists. L2TP and PPP are very mature protocols at this point, and the concept of filtering on an interface like PPP is a very well understood concept (especially by our customers). Anyway I will reiterate that I think removing either mode from IPSEC is a moot point since I wonder how seriously any of us think this code happen. -Skip > > Dan. > > On Fri, 18 Feb 2000 13:46:24 EST you wrote > > > > I assume you are talking about the traffic within the L2TP+IPSEC tunnel. You > > are right that without additional filters on the PPP interfaces associated wi > >th > > the secure tunnel, all traffic is permitted as long as it arrived on the SA > > bundle protecting L2TP. On the other hand, if only FTP and Telnet traffic is > > permitted to servers X, Y, and Z, these filters could be defined on the PPP > > interface. This configuration moves very transparently in this case, since i > >n > > many cases you are essentially replacing a leased/dialup line running PPP wit > >h a > > virtual PPP interface running on top of secure IP. > > From owner-ipsec@lists.tislabs.com Fri Feb 18 12:59: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 MAA01945; Fri, 18 Feb 2000 12:59:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29021 Fri, 18 Feb 2000 14:34:28 -0500 (EST) Message-Id: <200002181937.LAA20472@potassium.network-alchemy.com> To: Sudeep_Khuraijam@3com.com cc: Skip Booth , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: IPSec Complexity In-reply-to: Your message of "Fri, 18 Feb 2000 11:20:03 PST." <88256889.0069FA73.00@hqoutbound.ops.3com.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20469.950902647.1@network-alchemy.com> Date: Fri, 18 Feb 2000 11:37:27 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Nobody said that IPSec will replace/reinvent all access control policies. I just said that IPSec has access control mechanisms and by doing transport mode on some other tunneling method-- IPinIP or L2TP-- you lose that. Period. Dan. On Fri, 18 Feb 2000 11:20:03 PST you wrote > > > You're right that most people won't really care that much whether FTP > >and telnet have different algorithms applied to protect them but they > >would probably care if putting a protect selector for L2TP, e.g. > > "10.10.10.1 udp <---> 172.16.2.1 udp 1701 protect" > >would implicitly make a bypass selector for everything, e.g. > > "any <--> any allow" > > Not so, if we step out side the IPSec only paradigm. It is inadequate to ass >ume > that IPSec > will replace/reinvent all access control policies that have been in place. > There are gateways that can apply on the fly ACLs on per connection basis. > Such policies can be defined per group/per user/per host and deployed via LDA >P. > Using Selector lists to define access control does not scale and is > operationally > inefficient. From owner-ipsec@lists.tislabs.com Fri Feb 18 13:28: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 NAA02943; Fri, 18 Feb 2000 13:28:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29313 Fri, 18 Feb 2000 15:17:35 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <38AD9A3B.F2896693@cisco.com> References: <38AD7A8C.DD010D8B@cisco.com> <38AD9A3B.F2896693@cisco.com> Date: Fri, 18 Feb 2000 15:15:47 -0500 To: "W. Mark Townsley" From: Stephen Kent Subject: Re: IPSec Complexity Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, >The linkage between IPsec and L2TP is a standards track document >(draft-ietf-pppext-l2tp-security-05.txt). I'll be sure to review it when it comes up for last call. > >The linkage between L2TP and PPP is a standards track RFC (RFC 2661). > >The only missing element is the requirement of filters at the virtual >PPP interface actually defined in an RFC. Filtering traffic on an >interface or based on a PPP user is something that PPP Remote Access >vendors have done for years. Since there are no bits on the wire >required of these features, I suspect that the WG did not see fit to >write up an RFC. However, if we really, really, really, need an RFC for >it to be real, that could certainly be accomplished if we found the >people with the time to write it up and charter under which to publish >it. However, the more important thing to me and my customers is that the >given functionality exists and is available from multiple vendors. That >is certainly the case throughout the industry now. The fact that it is >not in an RFC is purely academic (again, which is not to say that it is >not worthwhile to document). I don't doubt that the clients of any single vendor are more focused on the vendor's product doing what the clients want, vs. having a standard that defines what the products should do. That's especially true when a single vendor has a very strong market presence and can establish de facto standards through the introduction of features in products. However, the IETF is a standards forum and only when we produce documents, and get approval for them as standards, are we doing our job as IETF members. So, I stand by my point. > > > that is not defined in any of those standards. Also, in other than > > the dialup user case, e.g., in extranets and intranets based on > > IPsec, it is not clear that the same linkages will occur. > > > > So, I guess I'm willing to believe that a vendor could create an > > implementation that maintained the SA linkages you describe, but it > >In fact, by linking L2TP and IPsec, you get the filter linkages >described for free. Free, at the cost of an extra layer of protocol, i.e., L2TP. >We have been doing remote access for years via leased lines and dialup >connections. We have filtering techniques galore for these at either end >of the connection. When you add IPsec for a VPN, in a sense you are >simply replacing the leased line with a tunneled connection over the >Internet. Securing that connection is necessary given that the internet >is a shared public medium, but I do not see why the filter techniques >defined in an IPsec RFC are any more real than those we have already >been using for years. In fact, I think it makes the transistion much >easier for customers to NOT define a whole new protocol, but rather to >use what they are already familiar with. Yes, we have had filters in place for these links for a while, although most of them, to the best of my knowledge, do not have IETF standards defining the access control filtering. IPsec establishes such standards, and accommodates filtering that can transition from a name space to an address space, as is necessary for dynamically assigned addresses. It defines name forms coupled to the underlying authentication mechanisms, to avoid the need for tables to map between the two, a good place to introduce errors into access control systems. By providing some rigor in the definitions for this access control method, it establishes a basis for more sophisticated inter-organization access control negotiations, of the sort that the IPSEC Policy WG is about to address. Steve From owner-ipsec@lists.tislabs.com Fri Feb 18 15:39: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 PAA06840; Fri, 18 Feb 2000 15:39:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29841 Fri, 18 Feb 2000 17:16:13 -0500 (EST) Date: Fri, 18 Feb 2000 14:21:40 -0800 From: Skye Poier To: ipsec@lists.tislabs.com Subject: Packet Interceptors Message-ID: <20000218142140.A98264@ffwd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-URL: http://www.ffwd.com/ Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks to everyone that responded and continues to debate the whole Tunnel/ESP vs. everything else issue. I'm sure learning a lot. Next question, I've been looking over various IPSec toolkits and the Hi/fn product looks pretty good. The only problem is it doesn't include the packet interceptor engine like the SSH IPSec Express product does. The Hi/fn docs say that it uses "mbufs" internally. Can anyone recommend interceptor products for Windows 9x/NT that will transparently shoehorns itself into the IP stack (ala the SSH VXD - we don't want something that shows up as a network adapter!!) and can serve up these mbufs or something easy to convert? 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 Fri Feb 18 16:25: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 QAA08907; Fri, 18 Feb 2000 16:25:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00056 Fri, 18 Feb 2000 17:59:49 -0500 (EST) Date: Fri, 18 Feb 2000 18:04:47 -0500 (EST) From: "W. Mark Townsley" To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: IPSec Complexity 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 Fri, 18 Feb 2000, Stephen Kent wrote: > Mark, > > > >The linkage between IPsec and L2TP is a standards track document > >(draft-ietf-pppext-l2tp-security-05.txt). > > I'll be sure to review it when it comes up for last call. > > > > >The linkage between L2TP and PPP is a standards track RFC (RFC 2661). > > > >The only missing element is the requirement of filters at the virtual > >PPP interface actually defined in an RFC. Filtering traffic on an > >interface or based on a PPP user is something that PPP Remote Access > >vendors have done for years. Since there are no bits on the wire > >required of these features, I suspect that the WG did not see fit to > >write up an RFC. However, if we really, really, really, need an RFC for > >it to be real, that could certainly be accomplished if we found the > >people with the time to write it up and charter under which to publish > >it. However, the more important thing to me and my customers is that the > >given functionality exists and is available from multiple vendors. That > >is certainly the case throughout the industry now. The fact that it is > >not in an RFC is purely academic (again, which is not to say that it is > >not worthwhile to document). > > I don't doubt that the clients of any single vendor are more focused > on the vendor's product doing what the clients want, vs. having a > standard that defines what the products should do. That's especially > true when a single vendor has a very strong market presence and can > establish de facto standards through the introduction of features in > products. However, the IETF is a standards forum and only when we > produce documents, and get approval for them as standards, are we > doing our job as IETF members. So, I stand by my point. But we can't do everything. Perhaps it is just me, but I believe that it is most important to standardize that which is required to interoperate. Then, to give localized implementation recommendations or requirements. Both are important, but there is a priority here. If we had all the resources in the world, then we could write documents for how to implement every feature in every piece of networking gear. This would leave us at a loss for anyone to actually sit down and write the code to make it all work. The line has to be drawn somewhere. At any rate, my point is that the PPP filters used in the manner described earlier perform the same function as IPsec filters matched to a specific SA (aside of varying transforms per traffic type for a specific user). The advantage to this is that it offloads some of the requirements for IPsec (this thread started as a thread about IPsec complexity) while allowing the user to capilatize on something that they are already familiar with. It also utilizes code that has been field tested on private networks for years. An incremental transition is less complex to define, and typically easier on the customer when completed. > > > > > > that is not defined in any of those standards. Also, in other than > > > the dialup user case, e.g., in extranets and intranets based on > > > IPsec, it is not clear that the same linkages will occur. > > > > > > So, I guess I'm willing to believe that a vendor could create an > > > implementation that maintained the SA linkages you describe, but it > > > >In fact, by linking L2TP and IPsec, you get the filter linkages > >described for free. > > Free, at the cost of an extra layer of protocol, i.e., L2TP. L2TP allows you to capitalize on PPP. The overall cost is less than reinventing everything in IPsec. Tunnel mode vs. L2TP -- either way you have an extra header. With L2TP you preserve PPP and all of the remote access benefits that come with it (user auth, accounting, keepalives, an interface to bind routing protocols to, filtering, etc...). But I digress... > > >We have been doing remote access for years via leased lines and dialup > >connections. We have filtering techniques galore for these at either end > >of the connection. When you add IPsec for a VPN, in a sense you are > >simply replacing the leased line with a tunneled connection over the > >Internet. Securing that connection is necessary given that the internet > >is a shared public medium, but I do not see why the filter techniques > >defined in an IPsec RFC are any more real than those we have already > >been using for years. In fact, I think it makes the transistion much > >easier for customers to NOT define a whole new protocol, but rather to > >use what they are already familiar with. > > Yes, we have had filters in place for these links for a while, > although most of them, to the best of my knowledge, do not have IETF > standards defining the access control filtering. IPsec establishes > such standards, and accommodates filtering that can transition from a > name space to an address space, as is necessary for dynamically > assigned addresses. A noble cause to define filtering, but this could be applied equally as well at a different layer, under a different venue. > It defines name forms coupled to the underlying > authentication mechanisms, to avoid the need for tables to map > between the two, a good place to introduce errors into access control > systems. By providing some rigor in the definitions for this access > control method, it establishes a basis for more sophisticated > inter-organization access control negotiations, of the sort that the > IPSEC Policy WG is about to address. Again, I don't have a problem having filters defined for IPsec. But, saying they are somehow more secure or better applied than the same types of filters at a different layer is nonsense. Even if it is defined in an RFC. > > Steve > > > From owner-ipsec@lists.tislabs.com Fri Feb 18 17:03: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 RAA09760; Fri, 18 Feb 2000 17:03:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00251 Fri, 18 Feb 2000 18:51:38 -0500 (EST) Message-ID: <38ADDC95.D6BBD850@redcreek.com> Date: Fri, 18 Feb 2000 15:58: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: Stephen Kent CC: "W. Mark Townsley" , ipsec@lists.tislabs.com Subject: Re: IPSec Complexity References: <38AD7A8C.DD010D8B@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > mark, > > The description you provide for filtering seems plausible, but is not > in any standard. It implies a linkage between PPP, L2TP, and IPsec > that is not defined in any of those standards. Also, in other than > the dialup user case, e.g., in extranets and intranets based on > IPsec, it is not clear that the same linkages will occur. > > So, I guess I'm willing to believe that a vendor could create an > implementation that maintained the SA linkages you describe, but it > would appear that such linkages would be outside the scope of all the > relevant standards. Not being a fan of relying on vendor-specific > implementation conventions to achieve security, I can't be too > enthusiastic about this approach. > > Steve Howdy, I'm not sure yet where I come down on this debate. But I would like to toss out some thoughts. Filtering linkages between PPP, L2TP, and IPsec are not standardized. Mechanisms for treating an IPsec tunnel as an IGP friendly interface are not standardized. Either of these would satisfy the majority of thread models which the business market currently wishes to face. Perhaps other solutions exist like modifying routing protocols to be IPsec tunnel friendly instead of modifying IPsec to be IGP friendly. Or again, it has been suggested on this list before that we could use iBGP and not sweat making IGPs run. Doing a standardized interface mechanism in IPsec conqueres more threat models than does chaining together differing filtering mechanisms on differing partial protocols. The PPP - L2TP - IPsec(transport) model would be quickest code/implement/bakeoff if we have the will to go that direction. The world I think alot of us would like to see in the future is IPsec and PKIs happily coorborating to solve the worlds problem. And just on an emotional level, I recoil at the legion of headers required to do the PPP/L2TP thing. Once upon a time, I proposed standardizing a IGP friendly IPsec interface (using IPsec tunnels). For any who are interested see Subject= "Re: IPSEC tunnels for LAN-to-LAN interop issue" from 2 Sep 99, messageID= <37CEAEAF.7E865D31@redcreek.com>. It's a pretty odd idea and I've not even been able to convince myself to get fully behind it. Perhaps with some help to clean up the stupid parts... :-0 -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Fri Feb 18 17:14: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 RAA09872; Fri, 18 Feb 2000 17:14:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA00320 Fri, 18 Feb 2000 19:13:29 -0500 (EST) From: Joe Touch Date: Fri, 18 Feb 2000 16:18:58 -0800 (PST) Message-Id: <200002190018.QAA29935@rum.isi.edu> To: CTrobridge@baltimore.com, kent@bbn.com Subject: RE: IPSec Complexity Cc: ipsec@lists.tislabs.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From owner-ipsec@lists.tislabs.com Fri Feb 18 09:36:47 2000 > Date: Fri, 18 Feb 2000 12:29:16 -0500 > To: Chris Trobridge > From: Stephen Kent > Subject: RE: IPSec Complexity > Cc: ipsec@lists.tislabs.com > > Chris, > > If you do IP in IP tunneling, and then apply transport mode, you > will suffer the access control problems I described earlier, because > transport mode IPsec looks only at the outer IP header, not the inner > one. The only one I noticed your mentioning had to do with the difficulty, after popping out of the IP in IP tunnel, of determining which traffic came from where. This is exactly what enables routing over IPSEC. The assumption is that the IPSEC is securing the links in this mode, not the entire system. Or was there another problem mentioned in another message? > Also, you will not be complaint with the IPsec Architecture as > defined in RFC 2401. Depends on how it's read, perhaps. If you are referring to page 9/10: b) A security gateway is required to support only tunnel mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management. When it comes to overlays, a gateway acts as both host and cageway. Host in how it terminates tunnels, and as far as the base network is concerned. A gateway as far as the overlay is concerned. Since the IPSEC occurs visible to the base network, it is an IPSEC-style host. The overlay network does not see the IPSEC at all. Is this the compliance issue? Joe From owner-ipsec@lists.tislabs.com Fri Feb 18 17:14: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 RAA09885; Fri, 18 Feb 2000 17:14:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA00368 Fri, 18 Feb 2000 19:20:01 -0500 (EST) From: Joe Touch Date: Fri, 18 Feb 2000 16:25:29 -0800 (PST) Message-Id: <200002190025.QAA29950@rum.isi.edu> To: CTrobridge@baltimore.com, msa@hemuli.tte.vtt.fi Subject: RE: IPSec Complexity Cc: ipsec@lists.tislabs.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From owner-ipsec@lists.tislabs.com Fri Feb 18 10:37:16 2000 > Date: Fri, 18 Feb 2000 20:30:30 +0200 (EET) > From: Markku Savela > To: CTrobridge@baltimore.com > CC: ipsec@lists.tislabs.com > Subject: RE: IPSec Complexity > > > From: Chris Trobridge The only way around > > this would be, as I think someone's already said, is to perform IP > > in IP tunneling first and then use Transport mode. > > On the wire the tunnel mode is *exactly* same as transport mode applied to > IPIP tunnel. Bitstreams are identical. They weren't when we did it. Maybe something has/is changed/ing, or this was purely an implementation issue. The difference was on keying - in tunnel-mode IPSEC, the inner header indexes the key in IPIP then transport IPSEC, the outer (IPIP) header indexes the key > One end could be applying IPSEC transport mode to IPIP tunnel, and > other end could be doing IPSEC in tunnel mode, and they can > communicate quite okay. The issue has to do with key lookup on _send_. It may be difficult to get an IPSEC/tunnel to generate the appropriate packets. Joe From owner-ipsec@lists.tislabs.com Fri Feb 18 19:37: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 TAA20728; Fri, 18 Feb 2000 19:37:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01114 Fri, 18 Feb 2000 21:37:26 -0500 (EST) Message-ID: <38AE0375.D05BF687@redcreek.com> Date: Fri, 18 Feb 2000 18:44:05 -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: CTrobridge@baltimore.com, kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: IPSec Complexity References: <200002190018.QAA29935@rum.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe Touch wrote: > > > From owner-ipsec@lists.tislabs.com Fri Feb 18 09:36:47 2000 > > Date: Fri, 18 Feb 2000 12:29:16 -0500 > > To: Chris Trobridge > > From: Stephen Kent > > Subject: RE: IPSec Complexity > > Cc: ipsec@lists.tislabs.com > > > > Chris, > > > > If you do IP in IP tunneling, and then apply transport mode, you > > will suffer the access control problems I described earlier, because > > transport mode IPsec looks only at the outer IP header, not the inner > > one. > > The only one I noticed your mentioning had to do with > the difficulty, after popping out of the IP in IP tunnel, > of determining which traffic came from where. > > This is exactly what enables routing over IPSEC. The assumption > is that the IPSEC is securing the links in this mode, not the entire > system. > Your statement is only true if you presuppose that routing protocols must flow on a GRE or L2TP tunnel. Alternativly, you could make IPsec tunnels behave as if they had virtual interfaces and then Routing protocols run nativly over IPsec tunnels and you get to retain all of IPsec's rich authentication services. It is suggested in this thread that authentication services and privacy services could be split apart from each other with authentication going to PPP or L2TP and privacy going to IPsec. I would like to pose an honest question to the proponents of that idea... since PPP and L2TP can provide privacy services, why not just stop using IPsec totally? > Or was there another problem mentioned in another message? > > > Also, you will not be complaint with the IPsec Architecture as > > defined in RFC 2401. > > Depends on how it's read, perhaps. If you are referring to page 9/10: > > b) A security gateway is required to support only tunnel > mode. If it supports transport mode, that should be used > only when the security gateway is acting as a host, e.g., > for network management. > > When it comes to overlays, a gateway acts as both host and cageway. > Host in how it terminates tunnels, and as far as the base network > is concerned. A gateway as far as the overlay is concerned. > > Since the IPSEC occurs visible to the base network, it is an IPSEC-style > host. The overlay network does not see the IPSEC at all. > > Is this the compliance issue? > > Joe -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Fri Feb 18 21:07: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 VAA26998; Fri, 18 Feb 2000 21:07:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA01296 Fri, 18 Feb 2000 23:00:53 -0500 (EST) Date: Fri, 18 Feb 2000 19:07:02 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: IPSec Complexity In-Reply-To: <200002181900.LAA20369@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 18 Feb 2000, Dan Harkins wrote: > ...So now have come full > circle when the solution to address the security problems (and still > have tunneling and still get rid of one mode) is more complex than the > original tunneling design. Have we ever seen the vaguely-alluded-to explanation of why getting rid of *transport* mode, and just doing everything with tunnel mode, would be a horrible error? (Aside from the question of whether it is practical to delete a mode this late in the game, which is a different can of worms.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Feb 18 21:07: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 VAA27010; Fri, 18 Feb 2000 21:07:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA01301 Fri, 18 Feb 2000 23:00:57 -0500 (EST) Date: Fri, 18 Feb 2000 19:13:13 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: IPSec Complexity In-Reply-To: <200002181937.LAA20472@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 18 Feb 2000, Dan Harkins wrote: > Nobody said that IPSec will replace/reinvent all access control policies. > I just said that IPSec has access control mechanisms and by doing transport > mode on some other tunneling method-- IPinIP or L2TP-- you lose that. Well, but the question is whether we lose anything of *value* that way. Access control mechanisms are certainly needed, but whether the stuff in RFC 2401 is the right way to do them is another question. The mere fact that a superficially-reasonable combination of protocols, like IP-in-IP over transport mode, would bypass them suggests that they are not in the right place in the overall architecture. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Feb 18 21:27: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 VAA27508; Fri, 18 Feb 2000 21:27:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA01274 Fri, 18 Feb 2000 22:57:54 -0500 (EST) Date: Fri, 18 Feb 2000 23:02:10 -0500 (EST) From: Skip Booth To: Ricky Charlet cc: Joe Touch , CTrobridge@baltimore.com, kent@bbn.com, ipsec@lists.tislabs.com Subject: Re: IPSec Complexity In-Reply-To: <38AE0375.D05BF687@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 18 Feb 2000, Ricky Charlet wrote: > Joe Touch wrote: > > > > > From owner-ipsec@lists.tislabs.com Fri Feb 18 09:36:47 2000 > > > Date: Fri, 18 Feb 2000 12:29:16 -0500 > > > To: Chris Trobridge > > > From: Stephen Kent > > > Subject: RE: IPSec Complexity > > > Cc: ipsec@lists.tislabs.com > > > > > > Chris, > > > > > > If you do IP in IP tunneling, and then apply transport mode, you > > > will suffer the access control problems I described earlier, because > > > transport mode IPsec looks only at the outer IP header, not the inner > > > one. > > > > The only one I noticed your mentioning had to do with > > the difficulty, after popping out of the IP in IP tunnel, > > of determining which traffic came from where. > > > > This is exactly what enables routing over IPSEC. The assumption > > is that the IPSEC is securing the links in this mode, not the entire > > system. > > > > Your statement is only true if you presuppose that routing protocols > must flow on a GRE or L2TP tunnel. Alternativly, you could make IPsec > tunnels behave as if they had virtual interfaces and then Routing > protocols run nativly over IPsec tunnels and you get to retain all of > IPsec's rich authentication services. What would the phase 2 quick mode id's be? I assume you would have to negotiate either 0.0.0.0 (Netmask 0.0.0.0), ALL Protocols, All Ports. If you don't do this I am not sure how you put routing traffic such as RIP or IGRP which are both broadcast routing protocols. How would you handle a multicast routing protocol such as OSPF? If you don't negotiate an "ALL addresses" proxy, would you set up a new SA for every route you learned on you private network. This would seem to lead to SA explosion in a large mesh network. It has been suggested that it is an implementation issue for how IPSEC tunnels should look like an interface. IMO, it is an interoperability issue and needs the attention of the IPSEC working group if this is to be the suggested way to create VPN's. > It is suggested in this thread that authentication services and privacy > services could be split apart from each other with authentication going > to PPP or L2TP and privacy going to IPsec. I would like to pose an > honest question to the proponents of that idea... since PPP and L2TP can > provide privacy services, why not just stop using IPsec totally? PPP can provide encryptions services, albiet weak one's compared to IPSEC. There is no built in key management protocol and it does not protect the L2TP header. Take a look at the L2TP security draft for more information on why IPSEC/IKE is the security protocol for L2TP/PPP. -Skip > > > > > Or was there another problem mentioned in another message? > > > > > Also, you will not be complaint with the IPsec Architecture as > > > defined in RFC 2401. > > > > Depends on how it's read, perhaps. If you are referring to page 9/10: > > > > b) A security gateway is required to support only tunnel > > mode. If it supports transport mode, that should be used > > only when the security gateway is acting as a host, e.g., > > for network management. > > > > When it comes to overlays, a gateway acts as both host and cageway. > > Host in how it terminates tunnels, and as far as the base network > > is concerned. A gateway as far as the overlay is concerned. > > > > Since the IPSEC occurs visible to the base network, it is an IPSEC-style > > host. The overlay network does not see the IPSEC at all. > > > > Is this the compliance issue? > > > > Joe > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > > From owner-ipsec@lists.tislabs.com Sat Feb 19 21:08: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 VAA05630; Sat, 19 Feb 2000 21:08:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA05186 Sat, 19 Feb 2000 22:54:09 -0500 (EST) From: Joe Touch Date: Sat, 19 Feb 2000 19:59:40 -0800 (PST) Message-Id: <200002200359.TAA00774@rum.isi.edu> To: touch@ISI.EDU, rcharlet@redcreek.com Subject: Re: IPSec Complexity Cc: CTrobridge@baltimore.com, kent@bbn.com, ipsec@lists.tislabs.com X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From owner-ipsec@lists.tislabs.com Fri Feb 18 18:52:05 2000 > Date: Fri, 18 Feb 2000 18:44:05 -0800 > From: Ricky Charlet > To: Joe Touch > CC: CTrobridge@baltimore.com, kent@bbn.com, ipsec@lists.tislabs.com > Subject: Re: IPSec Complexity > > Joe Touch wrote: > > > > > From owner-ipsec@lists.tislabs.com Fri Feb 18 09:36:47 2000 > > > Date: Fri, 18 Feb 2000 12:29:16 -0500 > > > To: Chris Trobridge > > > From: Stephen Kent > > > Subject: RE: IPSec Complexity > > > Cc: ipsec@lists.tislabs.com > > > > > > Chris, > > > > > > If you do IP in IP tunneling, and then apply transport mode, you > > > will suffer the access control problems I described earlier, because > > > transport mode IPsec looks only at the outer IP header, not the inner > > > one. > > > > The only one I noticed your mentioning had to do with > > the difficulty, after popping out of the IP in IP tunnel, > > of determining which traffic came from where. > > > > This is exactly what enables routing over IPSEC. The assumption > > is that the IPSEC is securing the links in this mode, not the entire > > system. > > > Your statement is only true if you presuppose that routing protocols > must flow on a GRE or L2TP tunnel. How so? I run routing protocols - including RIPv2, using multicast, over the IPSEC tunnels I have. I don't do (or want to do) anything over any protocol other than IP (that way I can do overlays on overlays, ad infinitum, modulo packet MTU consumption by headers). > Alternativly, you could make IPsec > tunnels behave as if they had virtual interfaces and then Routing > protocols run nativly over IPsec tunnels and you get to retain all of > IPsec's rich authentication services. That's what I do. Though they're not really virtual interfaces in the sense I'm familiar - they are aliases to real interfaces, though. Joe From owner-ipsec@lists.tislabs.com Mon Feb 21 01:09: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 BAA10130; Mon, 21 Feb 2000 01:09:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA09199 Mon, 21 Feb 2000 02:15:04 -0500 (EST) Message-ID: <38B0E705.C356838@cisco.com> Date: Mon, 21 Feb 2000 08:19:33 +0100 From: Frederic Detienne Reply-To: fd@cisco.com Organization: Cisco Systems, Inc X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Skip Booth CC: Joe Touch , ipsec@lists.tislabs.com, skye@ffwd.com Subject: Re: IPSec Complexity References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Skip Booth wrote: > > On Fri, 18 Feb 2000, Frederic Detienne wrote: > > > > > > > I agree. One very nice thing about L2TP+IPSEC is that it looks like a network > > > interface with security features versus a IPSEC in tunnel mode which is a layer > > > 3 security transport. Since there is a PPP interface on top of L2TP, all the of > > > the interface specific stuff runs transparent to IPSEC. There are no Routing > > > protocol issues and standardized, well deployed MIBs are available for the > > > interface. PPP and L2TP also give you built-in keepalives for interface > > > maintenance. > > > > > I think the presence of an IPSec tunnel interface is a matter of > > implementation. Nothing prevents you a priori from having such an interface > > and you could very well have the traffic run independent of the IPSec thing. > > I agree to some degree. You certainly can implement a IPSEC tunnel interface. > Not sure how many SA's you have to set up though. Would you negotiate a new SA > for every new route you learned?. This would be very cumbersome for mesh > connectivity as it would lead to a huge set of SA's. On the other hand I guess > you could set your filters to encompass all traffic. There is a potential catch 22 here: do you have routing protocols over IPSec or next to it ? You can have both (in some cases, you _need_ both). The routing protocols out of IPSec helps establishing the tunnel, the routes you pass through the tunnel helps you not establishing new SA's. Especially in a dynamic environment like TED. Even with IPSec and no interface, you have that problem. This is more a design issue. > You also cannot assume at this point that your peer also implements a IPSEC > Tunnel interface design. There certainly is nothing in the current set of > standards which addresses this issue. With L2TP + IPSEC you know that both > peers have a PPP interface which is standardized so there are no > interoperability issues here. It does not matter. The implementation and/or interface (the set of commands) you offer has little to see with the bits on the wire. The implemenation/interface can prevent users from exploiting the full power of a protocol or conversely allows incorrect things to be defined. In no way can this affect interoperability (besides the expressivity power). There are examples of interface-enabled IPSec implementations working together with non intercace-enabled implementations. Notice that you could also run routing protocols over an IPSec tunnel even without having a dedicated interface. This is, again, a matter of overall design and not a problem in IPSec itself. > > > > But I agree L2TP has some advantages; it would help in not re-inventing the > > wheel with IPSec (thinking here of mode config). L2TP however does not have > > an inherent "configuration" advantage over an IPSec tunnel. > > Not sure what you mean here. PPP supports a very robust negotiation protocol > for it's link layer characteristics (LCP), and it's network protocols (NCPs). > IPCP is the control protocol which PPP uses to set up IP. IPCP already supports > address, DNS, WINS, and Gateway assignment. I was agreeing with you about the advantage of l2tp (parameter negociation). I just wanted to say that beyond the negociation, a tunnel is a tunnel and what you can transport with l2tp, you can do with IPSec. fred -- ------------------------- * oOo * ------------------------- CiscoSystems Frederic Detienne, CDE Security & Network Services Tel 32 2 704 55 55 From owner-ipsec@lists.tislabs.com Mon Feb 21 04:58: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 EAA16501; Mon, 21 Feb 2000 04:58:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA10452 Mon, 21 Feb 2000 06:40:32 -0500 (EST) From: Michael.Owen@net-tel.co.uk X400-Received: by mta "ice" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Mon, 21 Feb 2000 11:44:47 +0000 X400-Received: by mta "net-tel" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Mon, 21 Feb 2000 11:44:10 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Mon, 21 Feb 2000 11:44:10 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";ORANGE:0081-000221114410-1091] X400-Content-Type: P2-1988 (22) X400-Originator: Michael.Owen@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text, (2)(6)(1)(12)(0), (1)(2)(840)(113556)(3)(10)(1) X400-Recipients: non-disclosure:; Date: Mon, 21 Feb 2000 11:44:10 +0000 X400-Content-Identifier: RE: Bruce Schnei Message-Id: <"GRAPE:0130-000221114558-0002*/G=Michael/S=Owen/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> To: "(Markku Savela)" Cc: ipsec@lists.tislabs.com In-Reply-To: <200002030844.KAA28887@anise.tte.vtt.fi> References: <200002030221.SAA03463@homer.ka9q.ampr.org> Subject: RE: Bruce Schneier on IPsec Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > POP and IMAP servers are one place to apply IPSEC. Instead of having > to create special SSLized POP/IMAP/etc clients, one could have > machines running the servers require IPSEC for accessing the > services. This is just another form of end-to-end application. Unfortunately for IPSEC, this is an area where SSL has taken hold - it's fast becoming the perceived standard for secure connections. To be honest, I personally had always just seen IPSEC as something for VPN use. (ie: if you want everything encrypted, use IPSEC, if you want one or two occasional things encrypted, use SSL.) > Actually HTTPS could also be similarly replaced with IPSEC + HTTP? > > This way the client applications can be used unchanged, when the > client host has IPSEC. The servers admin would also be its own CA, and > thus having the full control of the certificates being used to access. In this case (https) I see even less reason to switch to IPSEC. SSL has already become the standard for secure web communications, and comes build into Netscape and IE, and is supported by Apache-SSL and several commercial web servers. Why would anyone want to change it to IPSEC now? -- Michael Michael Owen IT Security Engineer NET-TEL Computer Systems Ltd Michael.Owen@net-tel.co.uk From owner-ipsec@lists.tislabs.com Mon Feb 21 06:42: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 GAA17947; Mon, 21 Feb 2000 06:42:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10693 Mon, 21 Feb 2000 08:08:51 -0500 (EST) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D27C31@new-exc1.ctron.com> From: "Waters, Stephen" To: ipsec@lists.tislabs.com Subject: RE: IPSec Complexity Date: Mon, 21 Feb 2000 13:13:47 -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 Hi, what a cracker this note is! For me, the most interesting question is the topic of differential protection. If this is not required (mostly), then the model could be made simpler - which is certainly tempting for VPN aggregation devices. Here are some implementation details/defaults we have taken in an attempt to offer simpler LAN-LAN and Client access configuration on a VPN gateway. We have basically split the functions of an IPSEC-tunnel/SPD into routing, the tunnel, IP protection and filtering. The text below is not meant to be the answer, and I'm not sure how much it adds to this debate, but here it is anyway.. 1) We make use of transport-mode for L2TP, and IPIP tunnel when doing LAN-LAN routing, i.e. where dynamic routing protocols are required. The IPSEC protection is applied via a 'Socket' interface API to IPSEC that L2TP and IPIP call at boot time (create-ipsec-policy), and for each packet sent (apply-ipsec-policy). There is no SPD. A routing lookup provided the IPIP tunnel interface as the exist 'port' - which adds the IPIP tunnel header and then calls apply-ipsec-policy to protect (transport mode), then out. This 'socket' approach can also be used to protect management traffic ports on a gateway. If any filtering is required, it is applied with standard interface-based filtering on the virtual (tunnel) interface. All traffic is protected in the same way. 2) For LAN-LAN static links (static routes, as may be used to connect a large number of small site to a hub), we are looking into adding an 'IPSEC Static route' concept. This is much like an IP static route, expect is contains protection policy and peer information. This can be tunnel-mode or transport-mode+tunnel. Again, no SPD, just let the routing table take the strain - use the routing table to find the outbound SA. 3) Client access. Well, since we don't make one of these, we have to play whatever game the available IPSEC clients can support, and they typically do not support an IPIP tunnel+IPSEC transport mode, but it could be done that way. Again, no SPD is needed, since once the client has been assigned an Intranet address, a dynamically created static route can be used to resolve the outbound SA. 4) Filtering. Since the IPSEC implementation is unable to negotiate complex filtering rules, we have found it necessary to apply secondary filtering anyway. We make most use of this with client access: When the client connects, a policy delivers the additional filtering. Each packet (in and out) has to be checked against the policy filtering and the IPSEC policy negotiated by IKE. 5) Differential protection. If this is a hard requirement, then the existing model is necessary, since only the current SPD model (or something like it) can deliver this. THE question to answer, is whether this is a real requirement. If it is not, and all traffic is protected in the same way, we can separate the filtering and security functions. With the dawn of desk-top IPSEC (W2K, Unix, Linux), perhaps differential protection can be left to the desk top, and gateways can just tunnel (IPIP tunnel) and apply transport mode IPSEC authentication?? Bring back AH :) Cheers, Steve. From owner-ipsec@lists.tislabs.com Mon Feb 21 12:39: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 MAA28470; Mon, 21 Feb 2000 12:39:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12453 Mon, 21 Feb 2000 14:29:49 -0500 (EST) Message-ID: <38B19362.74CB6CA8@F-Secure.com> Date: Mon, 21 Feb 2000 21:34:58 +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: ipsec-policy@vpnc.org, ipsec@lists.tislabs.com Subject: IPSP WG solutions are too complex Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (Reply to only one list, thanks.) In my view what IPSP is trying to create is too complex. The SPS is a "swiss army knife" -type of solution, while there is no need for that kind of a solution. There are certainly valid problems to be solved, but the correct way would be specify only what is necessary, and not to try to solve everything at once. For example, each network entity needs to have a base policy (ad hoc terminology) so that the network entity knows what it can trust, who it's allowed to communicate with, and so forth. This base policy is relatively static, it might change for example when the network entity migrates to another network location. It's perfectly OK for IETF to specify standards that define how the base policy can be assigned for the network entity. However, several companies including F-Secure and Microsoft already have solutions for the problem of assigning a base policy for a network entity. Such companies have little interest in changing the whole policy distribution mechanism only to solve some of the other problems, which are not related to the base policy (like security gateway discovery). I would strongly suggest that the solutions created by IPSP be divided into two categories: 1) The internal policy distribution of a company. Some companies may wish to employ IETF-specified policy distribution mechanisms, while other companies wish to employ other, proprietary methods. 2) The problem of INTERCONNECTING network entities that belong to different organizations, and which have their policies defined by different authorities. Here we have (what I view) relevant problems for IPSP, including SGW discovery. This division mirrors an existing philosophy already found in routing protocols. Also, this division would enable parts of the network to evolve in a more rapid speed than other parts. This would be similar to an organization taking a new and improved routing protocol for its internal network, while using an older and less capable routing protocol in interconnections to the rest of the world. Another reason to do this is that this would reduce the complexity of the solutions created. As we've seen discussed quite extensively in IPSec WG, the complexity of a solution creates bugs. The complexity of a security policy system is just as bad as the complexity of IPSec/IKE. Some specific issues follow.. A problem in category 2) is what happens when A wishes to contact to B using IKE, and the connection setup fails. Here one problem is that A has really little knowledge of WHY the setup failed, because IKE will not provide such knowledge. I move that the correct way to solve this particular problem would be to fix IKE (in IPSec WG) to provide sufficient information to A, so that the IKE connection can be fixed (manually or automatically). The good way to solve this particular problem is not to employ SPS/SPP. If B doesn't wish to give this information through a modified IKE, it hardly wishes to give it through SPP either. Another problem in category 2) is the SGW discovery problem. Let's take an example situation: A laptop is roaming in the Internet, and it wishes to connect to its own VPN, to a peer whose address is 10.x.y.z. Let's assume there are very many SGWs, or some other reason, why we don't want to configure all of them statically to the laptop. Here a policy protocol querying some server as to the correct SGW to use is OK, and 'must' in fact be used since the peer's IP address is not routable. However, the protocol can be considerably simpler than (the whole of) SPP. If the peer's IP address is routable, SGW discovery could be done by using ICMP security failure messages. In my view this alternative should not be dismissed too lightly. If the ICMP system is insecure ;), it should be fixed, and some WG should take on that task. Also, a question regarding SPS: Assuming I have a laptop, and the laptop discovers several SGWs that need to be traversed to reach point B, how would one specify a policy that states that the laptop MAY NOT authenticate itself to any of the SGWs that are dynamically discovered. (I'm worried in this case that No Such Agency will try to put a SGW in the between, and discover who I am.) In any case, is there any practical use for more than two SGWs? One between where I am now and Internet, another between Internet and the destination? If there are no such cases, the first SGW can be known by methods in category 1), the second by a simple SGW discovery protocol in category 2). Also, creating solutions incrementally in IPSP WG would make it much easier to coordinate the solutions with those created in IPSRA, for example. Also, incremental solutions would be much easier to take in real use. By incremental I mean solutions that are "only what is necessary, and not everything at once". -- 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 Feb 21 17:05: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 RAA02257; Mon, 21 Feb 2000 17:05:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13624 Mon, 21 Feb 2000 18:33:02 -0500 (EST) Date: Mon, 21 Feb 2000 15:38:32 -0800 From: Skye Poier To: ipsec@lists.tislabs.com Subject: Re: IPSec Complexity Message-ID: <20000221153832.B77890@ffwd.com> References: <200002181900.LAA20369@potassium.network-alchemy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from henry@spsystems.net on Fri, Feb 18, 2000 at 07:07:02PM -0500 X-URL: http://www.ffwd.com/ Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Word on the street is that Henry Spencer said: > Have we ever seen the vaguely-alluded-to explanation of why getting rid of > *transport* mode, and just doing everything with tunnel mode, would be a > horrible error? (Aside from the question of whether it is practical to > delete a mode this late in the game, which is a different can of worms.) That's what my original question that started the thread was... other than a few extra bytes per packet, I can't really see any downside. Skye From owner-ipsec@lists.tislabs.com Tue Feb 22 09:45: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 JAA18932; Tue, 22 Feb 2000 09:44:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18066 Tue, 22 Feb 2000 11:08:11 -0500 (EST) From: "Terry Burnell" To: Subject: FW: Over head using IPSECV6 Date: Fri, 18 Feb 2000 15:51:04 -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.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: Steve Coya [mailto:scoya@ietf.org] Sent: Friday, February 18, 2000 3:51 PM To: Terry Burnell Cc: ietf-web@ietf.org Subject: Re: Over head using IPSECV6 No idea. You night wish to address your query to the ipsec working group. Their email address is ipsec@lists.tislabs.com On Thu, 10 Feb 2000, Terry Burnell wrote: >>What is the average overhead in terms of bandwidth when using IPSECv6 with >>triple DES. >> >> From owner-ipsec@lists.tislabs.com Tue Feb 22 09:45: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 JAA18948; Tue, 22 Feb 2000 09:45:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18065 Tue, 22 Feb 2000 11:08:11 -0500 (EST) Message-Id: <3.0.32.20000218115441.00c2ad40@zbl6c000.corpeast.baynetworks.com> X-Sender: smamros@zbl6c000.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 18 Feb 2000 11:54:42 -0500 To: Skip Booth From: "Shawn Mamros" Subject: Re: IPSec Complexity Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >In terms of pure access control, the filters can be applied to the PPP interface >and achieve the same result as if they were applied to the IPSEC tunnel. Again >the only loss is that the PPP interface can not tell which SA the packet arrived >on, but it does know that they packet was at least secured with the appropriate >L2TP security policy. Steve Kent already pointed out that filters can't ensure that packets actually came from their intended source, while IPsec security policy can. One other drawback with filters: you have no idea what sort of filters your peer might have, since filters aren't negotiated. It could very well be that you've set up an L2TP-in-IPsec connection, but the other side has its filters set such that it's dropping every packet you send, so all the work you put into encapsulation/encryption/authentication is going to waste. With IPsec tunnel mode, both sides have to agree on what the security policy for the tunnel is going to be at Quick Mode negotiation time; otherwise, the tunnel mode SAs aren't going to get established in the first place. That being said, L2TP-in-IPsec is quite useful when you want to tunnel non-IP traffic (believe it or not, some people do still use protocols other than IP...), and for many other applications. Very rarely is there ever one perfect protocol to solve all the world's problems, and truth be told, that applies to the question of tunnel vs. transport mode in IPsec as well. The difference between the two requires far less code than, say, that which is necessary to authenticate a digital signature with certificates, regardless of what security protocol one uses... -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Tue Feb 22 09:45: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 JAA18967; Tue, 22 Feb 2000 09:45:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18047 Tue, 22 Feb 2000 11:07:44 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Koning'" Cc: Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Date: Fri, 18 Feb 2000 12:31:30 -0500 Message-Id: <001e01bf7a35$fead2a40$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: <200002171728.MAA21694@tonga.xedia.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, I don't know that it wouldn't be possible to use client puzzles in a typical VPN. There are certain differences between the typical usage of clients and gateways that might help to reduce load under common scenerios. For example: 1. There are typically more clients than gateways. 2. The gateways have fixed IPs but the clients do not. 3. The gateways are usually initiating to a limited set of remote gateways that is known in advance (or can be detected at runtime). Under these circumstances, the responder could avoid forcing the gateway to solve multiple subsequent client puzzles by issuing him a "get out of puzzle free" token after each phase 1 negotiation. There are a limited number of known gateways, therefore these tokens would only use up a small amount of stored state. And sending the token during a phase 1 negotiation would absolve the initiator of the puzzle-solving task. Of course, this technique only works in the scenario I describe, but that is a fairly common scenerio. Note that this is quite similar to a method of active identity protection that I described a few months ago. 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 Koning > Sent: Thursday, February 17, 2000 12:28 PM > To: zegman@checkpoint.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs > Addressing > > > I have a concern about this notion of using puzzles as a way of > addressing the DoS problem. > > It seems that there is an implied assumption in this approach: that > the client is connecting to only one, or at most only a few, servers. > In that case, the puzzles approach seems plausible because the client > can afford the cost of solving a few puzzles as part of connection > setup. > > On the other hand, what if your "client" is the hub of a hub & spoke > topology VPN, and is initiating many IKE requests concurrently? We > already have seen some topologies of this kind, where scaling is a > concern. The cost of regular IKE exchanges (two DH operations plus > typically some public key stuff) is already high enough to > generate an > interest in PKI accelerators. If the initiator is trying to initiate > several hundred IKE exchanges, and in the process is hammered with > several hundred puzzles, life is suddenly very unpleasant indeed. > Note that the puzzles proposed so far aren't things you can > accelerate > with available "crypto hardware assist" devices. > > Let's be sure to keep this scenario in mind when analyzing proposed > approaches. > > paul > From owner-ipsec@lists.tislabs.com Tue Feb 22 13:19: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 NAA23699; Tue, 22 Feb 2000 13:19:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19256 Tue, 22 Feb 2000 14:50:55 -0500 (EST) Message-ID: <38B2EA58.46EF033C@redcreek.com> Date: Tue, 22 Feb 2000 11:58:16 -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: Skip Booth , ipsec@lists.tislabs.com Subject: Re: IPSec Complexity References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My reply at bottom: Skip Booth wrote: > > On Fri, 18 Feb 2000, Ricky Charlet wrote: > > > Joe Touch wrote: > > > > > > > From owner-ipsec@lists.tislabs.com Fri Feb 18 09:36:47 2000 > > > > Date: Fri, 18 Feb 2000 12:29:16 -0500 > > > > To: Chris Trobridge > > > > From: Stephen Kent > > > > Subject: RE: IPSec Complexity > > > > Cc: ipsec@lists.tislabs.com > > > > > > > > Chris, > > > > > > > > If you do IP in IP tunneling, and then apply transport mode, you > > > > will suffer the access control problems I described earlier, because > > > > transport mode IPsec looks only at the outer IP header, not the inner > > > > one. > > > > > > The only one I noticed your mentioning had to do with > > > the difficulty, after popping out of the IP in IP tunnel, > > > of determining which traffic came from where. > > > > > > This is exactly what enables routing over IPSEC. The assumption > > > is that the IPSEC is securing the links in this mode, not the entire > > > system. > > > > > > > Your statement is only true if you presuppose that routing protocols > > must flow on a GRE or L2TP tunnel. Alternativly, you could make IPsec > > tunnels behave as if they had virtual interfaces and then Routing > > protocols run nativly over IPsec tunnels and you get to retain all of > > IPsec's rich authentication services. > > What would the phase 2 quick mode id's be? I assume you would have to negotiate > either 0.0.0.0 (Netmask 0.0.0.0), ALL Protocols, All Ports. If you don't do > this I am not sure how you put routing traffic such as RIP or IGRP which are > both broadcast routing protocols. How would you handle a multicast routing > protocol such as OSPF? If you don't negotiate an "ALL addresses" proxy, would > you set up a new SA for every route you learned on you private network. This > would seem to lead to SA explosion in a large mesh network. It has been > suggested that it is an implementation issue for how IPSEC tunnels should look > like an interface. IMO, it is an interoperability issue and needs the attention > of the IPSEC working group if this is to be the suggested way to create VPN's. > > > It is suggested in this thread that authentication services and privacy > > services could be split apart from each other with authentication going > > to PPP or L2TP and privacy going to IPsec. I would like to pose an > > honest question to the proponents of that idea... since PPP and L2TP can > > provide privacy services, why not just stop using IPsec totally? > > PPP can provide encryptions services, albiet weak one's compared to > IPSEC. There is no built in key management protocol and it does not > protect the L2TP header. Take a look at the L2TP security draft for more > information on why IPSEC/IKE is the security protocol for L2TP/PPP. > > -Skip > > > > > > > > > > Or was there another problem mentioned in another message? > > > > > > > Also, you will not be complaint with the IPsec Architecture as > > > > defined in RFC 2401. > > > > > > Depends on how it's read, perhaps. If you are referring to page 9/10: > > > > > > b) A security gateway is required to support only tunnel > > > mode. If it supports transport mode, that should be used > > > only when the security gateway is acting as a host, e.g., > > > for network management. > > > > > > When it comes to overlays, a gateway acts as both host and cageway. > > > Host in how it terminates tunnels, and as far as the base network > > > is concerned. A gateway as far as the overlay is concerned. > > > > > > Since the IPSEC occurs visible to the base network, it is an IPSEC-style > > > host. The overlay network does not see the IPSEC at all. > > > > > > Is this the compliance issue? > > > > > > Joe > > > > -- > > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > > > > Howdy Skip, I think you've merged two different questions together a little too quickly. "What would the phase 2 Quick mode IDs be to make routing protocols run (or what would the selectors look like)?" and "If you do get routing protocols running over an IPsec tunnel, what good is it if your policy does not track dynamic route changes?" First off, it is possible to define selectors which match very tightly to particular routing protocols from particular gateways, even when you want to allow the broadcasts and multicasts (which you should). It is also possible to define selectors which match very broadly (multiple endpoints, multiple or routing, or all protocols...). And again, one could even establish a routing PKI and make the endpoints be name type selectors where the names match subject names in certificates. This is an adminstrators choice. The point is that routing protocols can be allowed to flow through SAs in several ways in todays standards. I think the more interesting question (and the one I think you are really building up to) is "So what if we do learn all these new routes, how will policy be made to track with routing changes?" And you retorically suggest that policy would look like and either or choice between 1) allow anything to anything in order for traffic following new routes to be allowed to pass,; or 2) keep hand configuring new selectors which align to the routes in your routing environment of the day. Well either of those may be ligitamate in some circumstances. That 'allow any thing to anything' idea is also what you inherit from using IPsec to add privacy to L2TP/PPP encapsulated tunnels. IPsec, however can do more. Network administrators can define that certian IP ranges belong to certian satalite entities and create secruity policyes to enfores these expectations so that newly discovered routes must conform to the expected IP ranges or the traffic will infact be denied. Again, another possibility is that a large enduser PKI exists within the AS and this may be utilized to name endpoints and govern their access to resources... then the selectors are not IP or route sensitive at all. All of these are possible in today's standards. One further possiblity (and I am only mentioning this, not advicating it) is that some places may put enough trust in their routing protocol that they would accept a situation where (possibliy authenticated) routing updates internally cause selector updates in their SPDs. This idea will not work with todays standards and, if advanced, would probably invoke a huge debate about should we allow unsuspcecting customers to even trust their routing protocols. Your final point about these 'IPsec interfaces' needing the attention of the WG for standardizaion if they go forward, I wholeheartedly agree with. I view this thread as a debate about which mechanism should we carry routing protocol through. The choices are an L2TP/PPP/IPsec combo with authentication and filtering going to L2TP/PPP because routing protocols already flow over them, or making a new routing protocol friendly IPsec interface. I am switching my position from nuteral to advocate for doing the IPsec interface thing (if and only if this WG wants to tackle making routing protocols run through VPNs). I think that simple packet filtering is too week an authenticaion mechanism for all situations, non-ip protocols are sacrificeable with in the IPsec world, and authenticaion and privice services being spit apart from each other is a bad thing. I doubt I will get swayed back to L2TP/PPP/IPsec but I might get swayed to a "change a routing protocol to make it IPsec friendly" position if someone begins advocating there. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Tue Feb 22 17:11: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 RAA26981; Tue, 22 Feb 2000 17:11:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20120 Tue, 22 Feb 2000 18:52:39 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.32.20000218115441.00c2ad40@zbl6c000.corpeast.baynetworks.com> References: <3.0.32.20000218115441.00c2ad40@zbl6c000.corpeast.baynetworks.com> Date: Tue, 22 Feb 2000 18:56:20 -0500 To: "Shawn Mamros" From: Stephen Kent Subject: Re: IPSec Complexity Cc: Skip Booth , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Shawn, Thanks for the note re non-IP traffic. I always point out (in my presentations) that if one is tunneling non-IP traffic, then the IPsec access control don't help much, and so use of L2TP in this context is certainly appropriate. Steve From owner-ipsec@lists.tislabs.com Tue Feb 22 19:18: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 TAA04800; Tue, 22 Feb 2000 19:18:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA20769 Tue, 22 Feb 2000 21:03:24 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "Terry Burnell" Cc: ipsec@lists.tislabs.com Subject: Re: FW: Over head using IPSECV6 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Feb 2000 21:08:51 -0500 Message-Id: <20000223020856.E59B541F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "Terry Burnell" writes: > > >>What is the average overhead in terms of bandwidth when using IPSECv6 with > >>triple DES. > >> By "overhead in terms of bandwidth", do you mean "how many bytes extra does IPsec consume in a v6 packet?" Triple vs. single DES is irrelevant here; the blocks, packet formats, etc., are the same. I don't know of any calculations for IPv6; I calculated a while back that for v4, the overhead was about 12-15%. (Disclaimer: my calculations were quite some time ago, and I don't even remember if they were for 1825-style IPsec vs. the current 2401-style.) Briefly, I took some of NLANR's packet size distribution data, and calculated a weighted average of the exact same set of packets if all were IPsec-protected. That is clearly questionable, since most http won't be protected for the forseeable future. To answer your question, I'd do the same thing, except that I'd take the 512 and 576 byte packets, and scale the count by assuming that that amount of data was carried in 1500-byte packets. v6 mandates Path MTU, and 1500 bytes is more or less standard these days. --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Feb 23 13:06: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 NAA01939; Wed, 23 Feb 2000 13:06:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25248 Wed, 23 Feb 2000 14:22:42 -0500 (EST) Date: Wed, 23 Feb 2000 11:28:07 -0800 From: Skye Poier To: ipsec@lists.tislabs.com Subject: Win2K? Message-ID: <20000223112806.D27253@ffwd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-URL: http://www.ffwd.com/ Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 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 Feb 23 15:40: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 PAA04606; Wed, 23 Feb 2000 15:40:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26702 Wed, 23 Feb 2000 17:14:35 -0500 (EST) Message-ID: <4992824A0863D211964B0008C7B1ACB8072C7D42@fifi.platinum.corp.microsoft.com> From: Randy Ramig To: "'Skye Poier'" , ipsec@lists.tislabs.com Subject: RE: Win2K? Date: Wed, 23 Feb 2000 14:08:19 -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 There are no public APIs for the Win2K release. There is a command line utility, IPSECPOL, in the Win2K Resource Kit that pretty much does everything the UI does, if that helps. Randy -----Original Message----- From: Skye Poier [mailto:skye@ffwd.com] Sent: Wednesday, February 23, 2000 11:28 AM 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 Thu Feb 24 04:52: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 EAA05697; Thu, 24 Feb 2000 04:52:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA29312 Thu, 24 Feb 2000 06:20:24 -0500 (EST) Message-Id: <200002241126.GAA25687@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-intragkm-02.txt Date: Thu, 24 Feb 2000 06:26:00 -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 : Intra-Domain Group Key Management Protocol Author(s) : T. Hardjono, B. Cain, I. Monga, Filename : draft-ietf-ipsec-intragkm-02.txt Pages : 31 Date : 23-Feb-00 This document describes a protocol for intra-domain group key management for IP multicast security, based on the framework of [HCD99]. In order to support multicast groups, the domain is divided into a number of administratively-scoped 'areas'. A host-member of a multicast group is defined to reside within one (and only one) of these areas. The purpose of placing host-members in areas is to achieve flexible and efficient key management, particularly in the face of the problem of changes (joining, leaving, ejections) in the membership of a multicast group. A separate administratively-scoped area control-group is defined for each (data) multicast group, for the express purpose of key management and other control-message delivery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-intragkm-02.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-intragkm-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-intragkm-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000223092657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-intragkm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-intragkm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000223092657.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Feb 24 04:52: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 EAA05700; Thu, 24 Feb 2000 04:52:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA29306 Thu, 24 Feb 2000 06:20:23 -0500 (EST) Message-Id: <200002241125.GAA25673@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-gkmframework-02.txt Date: Thu, 24 Feb 2000 06:25:55 -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 : A Framework for Group Key Management for Multicast Security Author(s) : T. Hardjono, B. Cain, N. Doraswamy Filename : draft-ietf-ipsec-gkmframework-02.txt Pages : 23 Date : 23-Feb-00 This document provides a framework for group key management for multicast security, motivated by three main considerations, namely the multicast application, scalability and trust-relationships among entities. It introduces two planes corresponding to the network entities and functions important to multicasting and to security. The key management plane consists of two hierarchy-levels in the form of a single 'trunk region' (inter-region) and one or more 'leaf regions' (intra-region). The advantages of the framework among others are that it is scalable, it has reduced complexity and allows the independence in regions of group key management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-gkmframework-02.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-gkmframework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-gkmframework-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000223092636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-gkmframework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-gkmframework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000223092636.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Feb 24 07:09: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 HAA10915; Thu, 24 Feb 2000 07:09:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00030 Thu, 24 Feb 2000 08:47:31 -0500 (EST) Date: Wed, 23 Feb 2000 16:30:50 -0800 (PST) From: Jeffrey Lo To: ipsec@lists.tislabs.com cc: shiraisi@trd.tmg.nec.co.jp Subject: RSA library for IKMPD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am trying to find out if there is any free RSA library usable by ikmpd obtained from Cisco PDS? If you know of any, please let me know the ftp site or webpages. Thanks. ---- Jeffrey Lo C&C Research Labs, NEC USA, Inc. Tel : (408) 943 3033 Fax : (408) 943 3099 From owner-ipsec@lists.tislabs.com Thu Feb 24 08:45: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 IAA12878; Thu, 24 Feb 2000 08:45:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00876 Thu, 24 Feb 2000 10:09:10 -0500 (EST) Date: Thu, 24 Feb 2000 10:14:17 -0500 From: "Michael H. Warfield" To: Jeffrey Lo Cc: ipsec@lists.tislabs.com, shiraisi@trd.tmg.nec.co.jp Subject: Re: RSA library for IKMPD Message-ID: <20000224101417.D19179@alcove.wittsend.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: ; from jlo@ccrl.sj.nec.com on Wed, Feb 23, 2000 at 04:30:50PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Feb 23, 2000 at 04:30:50PM -0800, Jeffrey Lo wrote: > Hi, > I am trying to find out if there is any free RSA library usable by ikmpd > obtained from Cisco PDS? If you know of any, please let me know the ftp > site or webpages. Your address is in the US, but a Cc on the message included a .jp address. If you are in the US, your choices for the next few months are rather limited. Due to patent restrictions (Due to expire in the September/October time frame) you must use the RSAREF2 libraries for non-commercial applications and have a fully paided and licensed library for commercial applications. Users outside the US can use the international RSA libraries that are in the OpenSSL package or the ones with SSH or the international version of PGP. I would go with the OpenSSL package first, since it's already build as a library for you. > Thanks. > ---- > > Jeffrey Lo > C&C Research Labs, > NEC USA, Inc. > Tel : (408) 943 3033 > Fax : (408) 943 3099 Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Thu Feb 24 08:54: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 IAA13225; Thu, 24 Feb 2000 08:54:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00812 Thu, 24 Feb 2000 10:00:36 -0500 (EST) Message-Id: <3.0.5.32.20000224163221.009215a0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 24 Feb 2000 16:32:21 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: zlib bugs 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 JAA00570 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK, I changed the inflateInit to inflateInit2 and stuff, but I hit a rather ugly bug the zlib 1.1.3. The inflate routine tends to read one or two bits too much from the input stream and inflate() returns a bogus "out of input buffer" error. I analysed the problem and I know how to fix it in the zlib, but... Anybody else using the zlib successfully? I should state that the problem can only occur when using the undocumented "negative window size" feature. Jörn From owner-ipsec@lists.tislabs.com Thu Feb 24 11:42: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 LAA15606; Thu, 24 Feb 2000 11:42:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01671 Thu, 24 Feb 2000 13:05:33 -0500 (EST) Message-Id: <200002241810.KAA19192@mailman.cisco.com> X-Sender: ntimms@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 24 Feb 2000 10:04:03 -0800 To: Skye Poier From: Natalie Timms Subject: Re: Win2K? Cc: ipsec@lists.tislabs.com In-Reply-To: <20000223112806.D27253@ffwd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Using the mmc command (Microsoft Management Console), then select add snap-ins and load the IPsec policy support. -Nat At 11:28 AM 2/23/2000 -0800, you wrote: >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/ ] > -------------------------------------------------------------------------------------- Natalie Timms Ph Office : 425 468-0851 Software Engineer Email : ntimms@cisco.com EWAN BU Pager : 1 800 365 4578 or Cisco Systems ntimms@epage.cisco.com --------------------------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Feb 24 13:46: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 NAA17222; Thu, 24 Feb 2000 13:46:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02464 Thu, 24 Feb 2000 15:25:52 -0500 (EST) From: Charles Tsai Date: Thu, 24 Feb 2000 12:30:48 -0800 (PST) Message-Id: <200002242030.MAA05407@plata.nsd.3com.com> To: skye@ffwd.com, ntimms@cisco.com Subject: Re: Win2K? Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: vFJWW68B0yAOOml0IzIVXQ== Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From owner-ipsec@lists.tislabs.com Thu Feb 24 11:01:34 2000 > Return-Path: > Message-Id: <200002241810.KAA19192@mailman.cisco.com> > X-Sender: ntimms@diablo.cisco.com > X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 > Date: Thu, 24 Feb 2000 10:04:03 -0800 > To: Skye Poier > From: Natalie Timms > Subject: Re: Win2K? > Cc: ipsec@lists.tislabs.com > In-Reply-To: <20000223112806.D27253@ffwd.com> > Sender: owner-ipsec@lists.tislabs.com > Precedence: bulk > Status: RO > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Content-MD5: uwbFhXGsLyCkgZ7Lum77UQ== > Content-Length: 847 > > Using the mmc command (Microsoft Management Console), then select add snap-ins and load the IPsec policy support. > > -Nat > > > At 11:28 AM 2/23/2000 -0800, you wrote: > >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/ ] > > > -------------------------------------------------------------------------------------- > Natalie Timms Ph Office : 425 468-0851 > Software Engineer Email : ntimms@cisco.com > EWAN BU Pager : 1 800 365 4578 or > Cisco Systems ntimms@epage.cisco.com > --------------------------------------------------------------------------------------- > From owner-ipsec@lists.tislabs.com Fri Feb 25 14:36: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 OAA03965; Fri, 25 Feb 2000 14:36:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08596 Fri, 25 Feb 2000 15:50:46 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B788F9B@md-exchange1.nai.com> From: "Mason, David" To: ipsec@lists.tislabs.com Subject: Simplification of IKE Date: Fri, 25 Feb 2000 12:52:06 -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 Two things that seem to cause a lot of confusion (or at least differing points of view) are how the Commit bit is to be handled (RFC style vs. son-of-ike style) and "negotiating up" of the group in phase 2. So just to make things more confusing I thought I'd throw this out to the list: A possible solution that would (eventually) eliminate these problems would be the introduction of a new phase 2 exchange type (eventually deprecating the current Quick Modes): HDR*, HASH, SA, Ni, [, IDs ] --> <-- HDR*, HASH, SA, Nr, [, KE ] [, IDs ] HDR*, HASH [, KE ] --> <-- HDR*, HASH With this we could eliminate the commit bit altogether which should simplify most IKE implementations' state machines; allows for phase 2 group negotiation; and eliminates the need for "negotiate up" of phase 2 groups (if the responder would normally offer group 2 as the initiator but will "negotiate up" as the responder, the responder would just have the phase 2 policy as multiple proposals that offer both group 2 and group 5). Yes this lengthens the time to do a phase 2 by 1 message transmission time, but it allows group negotiation in phase 2 and eliminates the need for the Commit bit (the out-of-order problem where the initiator's IPSec packets arrive at the responder before the 3rd QM message arrives and/or is processed would no longer happen which simplifies avoiding dropped packets). Like it or not there will be other dramatic IKE changes coming down the pike (e.g., DoS changes). If anyone feels that this new mode is worth pursuing I'll write up a draft (using the apparently de facto VID payload new feature method). -dave From owner-ipsec@lists.tislabs.com Mon Feb 28 08:41: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 IAA16212; Mon, 28 Feb 2000 08:41:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19825 Mon, 28 Feb 2000 09:54:01 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'IPSEC Mailing List @ tis labs'" Subject: Use of Encryption in Heartbeat Packets Date: Mon, 28 Feb 2000 10:05:32 -0500 Message-Id: <004f01bf81fd$42d8d9c0$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 everyone, I'm working on a heartbeat protocol draft based on the comments I received back in December. I want to get people's opinion on one subject that is not clear to me, which is whether heartbeat packets should be both encrypted and authenticated or just authenticated. Possible advantages of encryption are: a) the additional level of authentication it provides, and b) the confidentiality of the packet. a) is not a problem if you use a hash function that is fully resistant to differential plaintext analysis (since consecutive packets may be quite similar). b) seems to be a minor issue because the packet contents are of low sensitivity. The only relevant information the adversary could gain is the list of negotiated Spis for that connection. The disadvantage of encryption is that it slows down packet throughput in the normal case. However, during a DoS attack, the use of encryption would allow the sgw to quickly discard invalid (spoofed/replayed) packets. This gives it an advantage over authentication in rejecting large spoofed packets. However, there is no advantage in rejecting small spoofed packets. So if the adversary can generate and route large numbers of small spoofed packets as easily as small numbers of large spoofed packets, then this protection mechanism doesn't work and encryption does not provide a DoS advantage. I estimate that in the normal case, 1000 SAs will only generate an average of 5kb/sec of heartbeat traffic, so throughput is not a huge issue. But there doesn't seem to be a compelling reason to use encryption either. I'm tempted to say "better safe than sorry", but I'd like to get a straw poll on this issue. Andrew _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Mon Feb 28 08: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 IAA16227; Mon, 28 Feb 2000 08:41:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19650 Mon, 28 Feb 2000 09:34:23 -0500 (EST) Message-ID: <000b01bf7f84$6873e6a0$2dcd09c0@nig95> From: "rupesh" To: Subject: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Date: Fri, 25 Feb 2000 17:05:24 +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 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..... Thanks & Regards Rupesh From owner-ipsec@lists.tislabs.com Mon Feb 28 10:21: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 KAA18389; Mon, 28 Feb 2000 10:21:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20641 Mon, 28 Feb 2000 11:58:29 -0500 (EST) Date: Mon, 28 Feb 2000 12:03:32 -0500 (EST) From: Henry Spencer To: Andrew Krywaniuk cc: "'IPSEC Mailing List @ tis labs'" Subject: Re: Use of Encryption in Heartbeat Packets In-Reply-To: <004f01bf81fd$42d8d9c0$1e0101c8@ANDREWK2.TIMESTEP> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 28 Feb 2000, Andrew Krywaniuk wrote: > I want to get people's opinion on one subject that is not clear to me, which > is whether heartbeat packets should be both encrypted and authenticated or > just authenticated. The business of deciding on a bit-by-bit basis which things need to be encrypted and/or authenticated leaves a bad taste in my mouth. It adds complexity to the design for no very good reason, and there's always the possibility that such an assessment might be wrong for some subtle reason. It's simpler and safer to just encrypt *everything*. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Feb 28 11:14: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 LAA19531; Mon, 28 Feb 2000 11:14:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20884 Mon, 28 Feb 2000 12:57:29 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "rupesh" Cc: ipsec@lists.tislabs.com Subject: Re: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Feb 2000 13:02:57 -0500 Message-Id: <20000228180302.9CF5E41F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <000b01bf7f84$6873e6a0$2dcd09c0@nig95>, "rupesh" writes: > 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..... > Thanks & Regards > Rupesh In principle, there's no reason why other modes can't be used. However, any other mode would need its own security analysis. OFB, for example, is very dangerous if the key stream ever repeats (which in turn would happen if the same IV were ever used twice during the lifetime of a given key. Also note that CFB-64 and OFB-64 still require that the plaintext be a multiple of 8 bytes, and that any other mode -- say, CFB-8 or OFB-8 -- would require a considerable increase in processing time. --Steve Bellovin From owner-ipsec@lists.tislabs.com Mon Feb 28 14:13: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 OAA23092; Mon, 28 Feb 2000 14:13:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21567 Mon, 28 Feb 2000 14:59:11 -0500 (EST) Message-Id: <3.0.32.20000228112422.00cc98f0@zbl6c000.corpeast.baynetworks.com> X-Sender: smamros@zbl6c000.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 28 Feb 2000 11:24:22 -0500 To: rupesh From: "Shawn Mamros" Subject: Re: Q: Why IPSEC to be used only in CBC mode & not other like CFB or OFB ? Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >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 ? CFB and OFB would require one iteration of the block cipher for every octet, vs. one iteration per block for CBC. For an eight octet per block cipher, it would take eight times longer to encrypt the packet, with little or no appreciable benefit security-wise over CBC, as far as I know. And the larger the block size (AES will use 16 octet blocks), the worse the performance will compare to CBC. -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Tue Feb 29 02:14: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 CAA24819; Tue, 29 Feb 2000 02:14:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA25049 Tue, 29 Feb 2000 03:41:46 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D04F9@baltimore.com> From: Chris Trobridge To: "Steven M. Bellovin" , rupesh 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, 29 Feb 2000 08:47:19 -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 > In message <000b01bf7f84$6873e6a0$2dcd09c0@nig95>, "rupesh" writes: > > 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..... > > Thanks & Regards > > Rupesh > > In principle, there's no reason why other modes can't be > used. However, any > other mode would need its own security analysis. OFB, for > example, is very > dangerous if the key stream ever repeats (which in turn would > happen if the > same IV were ever used twice during the lifetime of a given key. > > Also note that CFB-64 and OFB-64 still require that the > plaintext be a > multiple of 8 bytes, and that any other mode -- say, CFB-8 or > OFB-8 -- would > require a considerable increase in processing time. > > --Steve Bellovin CFB-8 is very time consuming and it also doesn't really help with the packet extension problem. Even though it doesn't require padding the rest of IPSEC does and extends the datagram with other fields. IME, once you extend the datagram in anyway then you incur most of the problems with MTU etc anyway. OFB-64 doesn't require the plaintext to be a multiple of 8 bytes - it's just xoring the cipher stream with the plaintext and any 'extra' bytes can be discarded before transmission. A unique IV isn't a problem if it's generated deterministically from the packet counter, though it's probably inherently less safe than CBC. The are some slight advantages to OFB mode - no xor in the feedback path - but nothing significant over CBC, and outweighed by other concerns. Chris From owner-ipsec@lists.tislabs.com Tue Feb 29 02:45: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 CAA27382; Tue, 29 Feb 2000 02:45:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA25183 Tue, 29 Feb 2000 04:32:47 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D04FD@baltimore.com> From: Chris Trobridge To: ipsec@lists.tislabs.com Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Date: Tue, 29 Feb 2000 09:38:29 -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've had some thoughts about this. Consider that rather than generate a 'get out of puzzle free' token that the ISAKMP peers negotiate a shared secret authentication key. Subsequent negotiations could use this key in place of the much more expensive PKI base authentication. These temporary authentication keys could be cached and wouldn't need to be held for every possible peer. If there's a vulnerability here, then the token could be used to authenticate the initial ISAKMP datagram(s) only and be used in addition to the current authentication mechanisms. This doesn't solve the initial connection issue, but it would help protect established VPNs at rekeying time against attacks on their PK/memory resources. Chris > -----Original Message----- > From: Andrew Krywaniuk [mailto:akrywani@newbridge.com] > Sent: 18 February 2000 17:32 > To: 'Paul Koning' > Cc: ipsec@lists.tislabs.com > Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs > Addressing > > > Hi Paul, > > I don't know that it wouldn't be possible to use client > puzzles in a typical > VPN. > > There are certain differences between the typical usage of clients and > gateways that might help to reduce load under common scenerios. > > For example: > > 1. There are typically more clients than gateways. > 2. The gateways have fixed IPs but the clients do not. > 3. The gateways are usually initiating to a limited set of > remote gateways > that is known in advance (or can be detected at runtime). > > Under these circumstances, the responder could avoid forcing > the gateway to > solve multiple subsequent client puzzles by issuing him a > "get out of puzzle > free" token after each phase 1 negotiation. > > There are a limited number of known gateways, therefore these > tokens would > only use up a small amount of stored state. And sending the > token during a > phase 1 negotiation would absolve the initiator of the > puzzle-solving task. > > Of course, this technique only works in the scenario I > describe, but that is > a fairly common scenerio. > > Note that this is quite similar to a method of active > identity protection > that I described a few months ago. > > Andrew From owner-ipsec@lists.tislabs.com Tue Feb 29 03:28: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 DAA02379; Tue, 29 Feb 2000 03:28:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA25357 Tue, 29 Feb 2000 05:12:31 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D0501@baltimore.com> From: Chris Trobridge To: akrywani@newbridge.com, "'IPSEC Mailing List @ tis labs'" Subject: RE: Use of Encryption in Heartbeat Packets Date: Tue, 29 Feb 2000 10:18:12 -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 If you're worried about the protocol being attacked, then authentication is a must. As Henry wrote, the less encrypt/bypass decisions there are the safer the product. I'm a little concerned that you think encryption will enable you to reject datagrams earlier. I presume that you mean you can decrypt the initial few bytes of the datagram to check for good plaintext. This may have some merit, but it's not a substitute for authentication and probably not that useful over all. An attacker can still modify later bytes in the datagram which would pass any sensible decryption test but not the authentication check. The heart beat protocol continues to raise feelings a little. My view is that there should an SA by which the protocol is protected. I think it could be the ISAKMP SA, though others would rather it were separate. I am against putting it though a regular SA (ie a user negotiated one) unless there's some significant change in the SA semantics - eg Transport mode with IP-in-IP tunnelling for user traffic. I think that there only need to send heartbeats in the absence of regular traffic. This makes an assumption that if there's a valid SA up in the peer then they all are. I think this is a good assumption, though there going to be extreme cases where it's not true. In any case, a further assumption would be that if a particular SA had gone down and the peer was generating authenticated heartbeats that there would be still an authenticated SA by which the peer could report the loss of the SA. If it costs more in CPU to check whether a heart beat has been sent than the loss in bandwidth, then there's nothing to stop the heart beats being sent anyway. There are some schemes that involve ping type operations. They have the advantage that it is possible to detect peer loss without any support in the peer but I've not seen any proposal that works without bending the rules, eg spoofing addresses to meet the SA. Chris > -----Original Message----- > From: Andrew Krywaniuk [mailto:akrywani@newbridge.com] > Sent: 28 February 2000 15:06 > To: 'IPSEC Mailing List @ tis labs' > Subject: Use of Encryption in Heartbeat Packets > > > Hi everyone, > > I'm working on a heartbeat protocol draft based on the > comments I received > back in December. > > I want to get people's opinion on one subject that is not > clear to me, which > is whether heartbeat packets should be both encrypted and > authenticated or > just authenticated. > > Possible advantages of encryption are: a) the additional level of > authentication it provides, and b) the confidentiality of the packet. > > a) is not a problem if you use a hash function that is fully > resistant to > differential plaintext analysis (since consecutive packets > may be quite > similar). > > b) seems to be a minor issue because the packet contents are of low > sensitivity. The only relevant information the adversary > could gain is the > list of negotiated Spis for that connection. > > The disadvantage of encryption is that it slows down packet > throughput in > the normal case. > > > However, during a DoS attack, the use of encryption would > allow the sgw to > quickly discard invalid (spoofed/replayed) packets. This gives it an > advantage over authentication in rejecting large spoofed > packets. However, > there is no advantage in rejecting small spoofed packets. > > So if the adversary can generate and route large numbers of > small spoofed > packets as easily as small numbers of large spoofed packets, then this > protection mechanism doesn't work and encryption does not > provide a DoS > advantage. > > I estimate that in the normal case, 1000 SAs will only > generate an average > of 5kb/sec of heartbeat traffic, so throughput is not a huge > issue. But > there doesn't seem to be a compelling reason to use > encryption either. I'm > tempted to say "better safe than sorry", but I'd like to get > a straw poll on > this issue. > > Andrew > _______________________________________________ > Beauty without truth is insubstantial. > Truth without beauty is unbearable. > From owner-ipsec@lists.tislabs.com Tue Feb 29 07:26: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 HAA11939; Tue, 29 Feb 2000 07:26:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26040 Tue, 29 Feb 2000 08:53:47 -0500 (EST) From: "Mr. Anderson" Message-Id: <200002291356.IAA01819@linux.silkroad.com> Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing To: ipsec@lists.tislabs.com Date: Tue, 29 Feb 100 08:56:04 -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 Thinking about future ISAKMP denial of service attacks on UDP has lead me to these system-centric risk reduction architectural observations (sorry for the mouthful ...) (1) ISAKMP is most vulnerable to DoS attack during the initial set up. (2) Risk is reduced by minimizing set-up time and maximizing non-setup processing (time). (3) Therefore, one trade-off goal in architecture and vs risk could be based on creating an architecture which minimizes ISAKMP set-up(s). (4) Establishing long standing tunnels with ISAKMP (tunnel mode) vs. shorter duration host-to-host exchanges (transparent mode) may significantly reduce ISAKMP DoS risk. This does imply that the complexity of 'trying to do it all' with IPSEC/ISAKMP is weakening the integrity of the system architecture (mentioned in the other thread on 'IPSEC complexity'). Controversy may continue in the 'complexity vs. robustness' debate, and it is possible that organizations will migrate to tunnel mode centric architectures to reduce DoS risk. Finest Regards, Neo --------------------------- 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 Tue Feb 29 09: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 JAA13569; Tue, 29 Feb 2000 09:01:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26680 Tue, 29 Feb 2000 10:33:53 -0500 (EST) Date: Tue, 29 Feb 2000 10:39:28 -0500 Message-Id: <200002291539.KAA17339@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: ipsec@lists.tislabs.com Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <1FD60AE4DB6CD2118C420008C74C27B81D04FD@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> I've had some thoughts about this. Consider that rather than Chris> generate a 'get out of puzzle free' token that the ISAKMP Chris> peers negotiate a shared secret authentication key. Chris> Subsequent negotiations could use this key in place of the Chris> much more expensive PKI base authentication. These temporary Chris> authentication keys could be cached and wouldn't need to be Chris> held for every possible peer. Chris> If there's a vulnerability here, then the token could be used Chris> to authenticate the initial ISAKMP datagram(s) only and be Chris> used in addition to the current authentication mechanisms. Chris> This doesn't solve the initial connection issue, but it would Chris> help protect established VPNs at rekeying time against attacks Chris> on their PK/memory resources. Interesting notion, but I am worried about the initial connection aspect as well. Consider the monday morning effect, or tunnel re-establishment after a security gateway reboot. paul From owner-ipsec@lists.tislabs.com Tue Feb 29 09: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 JAA13570; Tue, 29 Feb 2000 09:01:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26703 Tue, 29 Feb 2000 10:42:10 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Chris Trobridge'" , "Andrew Krywaniuk" , "'IPSEC Mailing List @ tis labs'" Subject: RE: Use of Encryption in Heartbeat Packets Date: Tue, 29 Feb 2000 10:54:13 -0500 Message-Id: <005a01bf82cd$397e2c60$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: <1FD60AE4DB6CD2118C420008C74C27B81D0501@baltimore.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chris & Henry, If you read my message closely, you will see that I was never considering using a heartbeat packet that is not authenticated. The choice was between AUTHENTICATED ONLY and AUTHENTICATED AND ENCRYPTED. I have most of the rest of the details of the protocol worked out already. 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 Chris Trobridge > Sent: Tuesday, February 29, 2000 5:18 AM > To: akrywani@newbridge.com; 'IPSEC Mailing List @ tis labs' > Subject: RE: Use of Encryption in Heartbeat Packets > > > If you're worried about the protocol being attacked, then > authentication is > a must. As Henry wrote, the less encrypt/bypass decisions > there are the > safer the product. > > I'm a little concerned that you think encryption will enable > you to reject > datagrams earlier. I presume that you mean you can decrypt > the initial few > bytes of the datagram to check for good plaintext. This may have some > merit, but it's not a substitute for authentication and > probably not that > useful over all. An attacker can still modify later bytes in > the datagram > which would pass any sensible decryption test but not the > authentication > check. > > The heart beat protocol continues to raise feelings a little. > My view is > that there should an SA by which the protocol is protected. > I think it > could be the ISAKMP SA, though others would rather it were > separate. I am > against putting it though a regular SA (ie a user negotiated > one) unless > there's some significant change in the SA semantics - eg > Transport mode with > IP-in-IP tunnelling for user traffic. > > I think that there only need to send heartbeats in the > absence of regular > traffic. This makes an assumption that if there's a valid SA > up in the peer > then they all are. I think this is a good assumption, though > there going to > be extreme cases where it's not true. In any case, a further > assumption > would be that if a particular SA had gone down and the peer > was generating > authenticated heartbeats that there would be still an > authenticated SA by > which the peer could report the loss of the SA. If it costs > more in CPU to > check whether a heart beat has been sent than the loss in > bandwidth, then > there's nothing to stop the heart beats being sent anyway. > > There are some schemes that involve ping type operations. > They have the > advantage that it is possible to detect peer loss without any > support in the > peer but I've not seen any proposal that works without > bending the rules, eg > spoofing addresses to meet the SA. > > Chris > > > -----Original Message----- > > From: Andrew Krywaniuk [mailto:akrywani@newbridge.com] > > Sent: 28 February 2000 15:06 > > To: 'IPSEC Mailing List @ tis labs' > > Subject: Use of Encryption in Heartbeat Packets > > > > > > Hi everyone, > > > > I'm working on a heartbeat protocol draft based on the > > comments I received > > back in December. > > > > I want to get people's opinion on one subject that is not > > clear to me, which > > is whether heartbeat packets should be both encrypted and > > authenticated or > > just authenticated. > > > > Possible advantages of encryption are: a) the additional level of > > authentication it provides, and b) the confidentiality of > the packet. > > > > a) is not a problem if you use a hash function that is fully > > resistant to > > differential plaintext analysis (since consecutive packets > > may be quite > > similar). > > > > b) seems to be a minor issue because the packet contents are of low > > sensitivity. The only relevant information the adversary > > could gain is the > > list of negotiated Spis for that connection. > > > > The disadvantage of encryption is that it slows down packet > > throughput in > > the normal case. > > > > > > However, during a DoS attack, the use of encryption would > > allow the sgw to > > quickly discard invalid (spoofed/replayed) packets. This gives it an > > advantage over authentication in rejecting large spoofed > > packets. However, > > there is no advantage in rejecting small spoofed packets. > > > > So if the adversary can generate and route large numbers of > > small spoofed > > packets as easily as small numbers of large spoofed > packets, then this > > protection mechanism doesn't work and encryption does not > > provide a DoS > > advantage. > > > > I estimate that in the normal case, 1000 SAs will only > > generate an average > > of 5kb/sec of heartbeat traffic, so throughput is not a huge > > issue. But > > there doesn't seem to be a compelling reason to use > > encryption either. I'm > > tempted to say "better safe than sorry", but I'd like to get > > a straw poll on > > this issue. > > > > Andrew > > _______________________________________________ > > Beauty without truth is insubstantial. > > Truth without beauty is unbearable. > > > From owner-ipsec@lists.tislabs.com Tue Feb 29 09:19: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 JAA13830; Tue, 29 Feb 2000 09:19:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26781 Tue, 29 Feb 2000 11:02:15 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D0518@baltimore.com> From: Chris Trobridge To: Chris Trobridge , Andrew Krywaniuk , "'IPSEC Mailing List @ tis labs'" Subject: RE: Use of Encryption in Heartbeat Packets Date: Tue, 29 Feb 2000 16:07:54 -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 was more concerned that you though encryption would provide a quick authentication check and strengthen the authentication. Ok, re-reading, you do say this is strengthening is only useful where the authentication algorithm is weak in the first place. I could be wrong, but I wasn't aware that the prescribed authentication algorithms were weak in this way. You do go on to say that encryption helps you reject large spoofed packets more quickly than authentication alone thus helping defeat a DOS attack. This was the other point I was questioning. Chris > Chris & Henry, > > If you read my message closely, you will see that I was never > considering > using a heartbeat packet that is not authenticated. > > The choice was between AUTHENTICATED ONLY and AUTHENTICATED > AND ENCRYPTED. > > I have most of the rest of the details of the protocol worked > out already. > > 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 Chris Trobridge > > Sent: Tuesday, February 29, 2000 5:18 AM > > To: akrywani@newbridge.com; 'IPSEC Mailing List @ tis labs' > > Subject: RE: Use of Encryption in Heartbeat Packets > > > > > > If you're worried about the protocol being attacked, then > > authentication is > > a must. As Henry wrote, the less encrypt/bypass decisions > > there are the > > safer the product. > > > > I'm a little concerned that you think encryption will enable > > you to reject > > datagrams earlier. I presume that you mean you can decrypt > > the initial few > > bytes of the datagram to check for good plaintext. This > may have some > > merit, but it's not a substitute for authentication and > > probably not that > > useful over all. An attacker can still modify later bytes in > > the datagram > > which would pass any sensible decryption test but not the > > authentication > > check. > > > > The heart beat protocol continues to raise feelings a little. > > My view is > > that there should an SA by which the protocol is protected. > > I think it > > could be the ISAKMP SA, though others would rather it were > > separate. I am > > against putting it though a regular SA (ie a user negotiated > > one) unless > > there's some significant change in the SA semantics - eg > > Transport mode with > > IP-in-IP tunnelling for user traffic. > > > > I think that there only need to send heartbeats in the > > absence of regular > > traffic. This makes an assumption that if there's a valid SA > > up in the peer > > then they all are. I think this is a good assumption, though > > there going to > > be extreme cases where it's not true. In any case, a further > > assumption > > would be that if a particular SA had gone down and the peer > > was generating > > authenticated heartbeats that there would be still an > > authenticated SA by > > which the peer could report the loss of the SA. If it costs > > more in CPU to > > check whether a heart beat has been sent than the loss in > > bandwidth, then > > there's nothing to stop the heart beats being sent anyway. > > > > There are some schemes that involve ping type operations. > > They have the > > advantage that it is possible to detect peer loss without any > > support in the > > peer but I've not seen any proposal that works without > > bending the rules, eg > > spoofing addresses to meet the SA. > > > > Chris > > > > > -----Original Message----- > > > From: Andrew Krywaniuk [mailto:akrywani@newbridge.com] > > > Sent: 28 February 2000 15:06 > > > To: 'IPSEC Mailing List @ tis labs' > > > Subject: Use of Encryption in Heartbeat Packets > > > > > > > > > Hi everyone, > > > > > > I'm working on a heartbeat protocol draft based on the > > > comments I received > > > back in December. > > > > > > I want to get people's opinion on one subject that is not > > > clear to me, which > > > is whether heartbeat packets should be both encrypted and > > > authenticated or > > > just authenticated. > > > > > > Possible advantages of encryption are: a) the additional level of > > > authentication it provides, and b) the confidentiality of > > the packet. > > > > > > a) is not a problem if you use a hash function that is fully > > > resistant to > > > differential plaintext analysis (since consecutive packets > > > may be quite > > > similar). > > > > > > b) seems to be a minor issue because the packet contents > are of low > > > sensitivity. The only relevant information the adversary > > > could gain is the > > > list of negotiated Spis for that connection. > > > > > > The disadvantage of encryption is that it slows down packet > > > throughput in > > > the normal case. > > > > > > > > > However, during a DoS attack, the use of encryption would > > > allow the sgw to > > > quickly discard invalid (spoofed/replayed) packets. This > gives it an > > > advantage over authentication in rejecting large spoofed > > > packets. However, > > > there is no advantage in rejecting small spoofed packets. > > > > > > So if the adversary can generate and route large numbers of > > > small spoofed > > > packets as easily as small numbers of large spoofed > > packets, then this > > > protection mechanism doesn't work and encryption does not > > > provide a DoS > > > advantage. > > > > > > I estimate that in the normal case, 1000 SAs will only > > > generate an average > > > of 5kb/sec of heartbeat traffic, so throughput is not a huge > > > issue. But > > > there doesn't seem to be a compelling reason to use > > > encryption either. I'm > > > tempted to say "better safe than sorry", but I'd like to get > > > a straw poll on > > > this issue. > > > > > > Andrew > > > _______________________________________________ > > > Beauty without truth is insubstantial. > > > Truth without beauty is unbearable. > > > > > > From owner-ipsec@lists.tislabs.com Tue Feb 29 09:19: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 JAA13842; Tue, 29 Feb 2000 09:19:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA26796 Tue, 29 Feb 2000 11:04:33 -0500 (EST) Date: Tue, 29 Feb 2000 10:51:24 -0500 Message-Id: <200002291551.KAA17349@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: neo@silkroad.com Cc: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <200002291356.IAA01819@linux.silkroad.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Anderson" == Anderson writes: Anderson> Thinking about future ISAKMP denial of service attacks on Anderson> UDP has lead me to these system-centric risk reduction Anderson> architectural observations (sorry for the mouthful ...) Anderson> (1) ISAKMP is most vulnerable to DoS attack during the Anderson> initial set up. True. 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. Anderson> (3) Therefore, one trade-off goal in architecture and vs Anderson> risk could be based on creating an architecture which Anderson> minimizes ISAKMP set-up(s). Or rather, the consumption of the resources I mentioned. Anderson> (4) Establishing long standing tunnels with ISAKMP (tunnel Anderson> mode) vs. shorter duration host-to-host exchanges Anderson> (transparent mode) may significantly reduce ISAKMP DoS Anderson> risk. Not necessarily. I assume you mean "transport" rather than "transparent" but in any case the SAs can live longer than the TCP connections protected by them. In any case, keeping the rate of legit requests low doesn't necessarily help. It's the rejection rate of illegit requests that needs to be improved. Also, lengthening the life of SAs may introduce other issues (key exposure). And while it helps reduce the setup rate due to rekeying, it does nothing to help the SA setup rate for the initial SA establishment. paul From owner-ipsec@lists.tislabs.com Tue Feb 29 10:10: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 KAA14488; Tue, 29 Feb 2000 10:10:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27439 Tue, 29 Feb 2000 11:55:17 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D0519@baltimore.com> From: Chris Trobridge To: "Mr. Anderson" , ipsec@lists.tislabs.com Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Date: Tue, 29 Feb 2000 17:00:59 -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 > Thinking about future ISAKMP denial of service attacks > on UDP has lead me to these system-centric risk reduction > architectural observations (sorry for the mouthful ...) You mention DOS attacks on UDP. Is there an alternative? TCP clearly hasn't solved this problem. > (1) ISAKMP is most vulnerable to DoS attack during the > initial set up. > > (2) Risk is reduced by minimizing set-up time and maximizing > non-setup processing (time). > > (3) Therefore, one trade-off goal in architecture and > vs risk could be based on creating an architecture > which minimizes ISAKMP set-up(s). We've considered the vulnerability to attacks on against memory and processing exhaustion. Neither of these are attacks that take place 'during' a set-up. These are attacks which force the creation of set-ups and hence the consumption of memory and processing time. The protocol already tries to minimise (defer) the processing effort until the host is reasonably certain that it's not being spoofed. The trouble here is that this causes to retain state until authentication is performed later in the protocol and this leaves it open to a memory consumption attack or even, still, a resource depletion attack if the attacker opens a number set-ups before proceeding to the next stage. What allows this is that the delays inherent in the Internet force hosts to hold sessions open for a reasonable time to allow a 'distant' peer time to respond. I think the points here would be to minimise the state held for pre-authentication sessions and minimising the effort require to authenticate a session. These two points apply particularly to the responder, assuming the threats are on the 'public' side of the gateway. One way to minimise the state held is for the responder to sign its state and return it to the initiator. One way to minimise the processing used is to employ symmetric authentication algorithms rather than public key algorithms. Symmetric key based solutions don't scale so this doesn't affect the need for a PKI. > (4) Establishing long standing tunnels with ISAKMP > (tunnel mode) vs. shorter duration host-to-host > exchanges (transparent mode) may significantly > reduce ISAKMP DoS risk. Other than these are different applications, I would agree. > This does imply that the complexity of 'trying to do it > all' with IPSEC/ISAKMP is weakening the integrity of > the system architecture (mentioned in the other thread > on 'IPSEC complexity'). This is probably the greatest risk. > Controversy may continue in the 'complexity vs. robustness' > debate, and it is possible that organizations will migrate > to tunnel mode centric architectures to reduce DoS risk. > > > Finest Regards, > Neo Chris From owner-ipsec@lists.tislabs.com Tue Feb 29 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 KAA14635; Tue, 29 Feb 2000 10:22:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27579 Tue, 29 Feb 2000 12:08:01 -0500 (EST) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B81D051B@baltimore.com> From: Chris Trobridge To: Paul Koning Cc: ipsec@lists.tislabs.com Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing Date: Tue, 29 Feb 2000 17:13:38 -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 > Chris> This doesn't solve the initial connection issue, but it would > Chris> help protect established VPNs at rekeying time against attacks > Chris> on their PK/memory resources. > > Interesting notion, but I am worried about the initial connection > aspect as well. Consider the monday morning effect, or tunnel > re-establishment after a security gateway reboot. > > paul I think it's pretty much accepted that DOS can't be prevented, so it's more a question of limiting it as best one can. There is a problem with the initial authentication. Random packet dropping and a puzzle based slowing down mechanism have been discussed as ways of limiting an attackers ability to overwhelm a host though ISAKMP. Once that initial authentication has been made, a secret point-to-point authentication key could be used to provide a cheap way of authenticating subsequent ISAKMP exchanges, from, the initial packet on. If the pre-existing authentication is still required then this secret key isn't particularly sensitive and would not require particular protection (relative to, eg, ESP keys). Given this, it could be possible to cache these for a reasonable amount of time. Depending on the device in question this would cope with Monday morning or reboot situations. It won't help if we all start using IPSEC in place of SSL to talk to web servers (is this ever likely?), but it would help with VPNs. Chris From owner-ipsec@lists.tislabs.com Tue Feb 29 10:31: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 KAA14750; Tue, 29 Feb 2000 10:31:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA27647 Tue, 29 Feb 2000 12:11:15 -0500 (EST) Date: Tue, 29 Feb 2000 12:16:49 -0500 Message-Id: <200002291716.MAA22748@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: ipsec@lists.tislabs.com Subject: RE: Future ISAKMP Denial of Service Vulnerablity Needs Addressing References: <1FD60AE4DB6CD2118C420008C74C27B81D051B@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> Once that initial authentication has been made, a secret Chris> point-to-point authentication key could be used to provide a Chris> cheap way of authenticating subsequent ISAKMP exchanges, from, Chris> the initial packet on. If the pre-existing authentication is Chris> still required then this secret key isn't particularly Chris> sensitive and would not require particular protection Chris> (relative to, eg, ESP keys). Given this, it could be possible Chris> to cache these for a reasonable amount of time. Depending on Chris> the device in question this would cope with Monday morning or Chris> reboot situations. Not reboot, unless you assume that these things go into NVram, which is not all that likely. That tends to be a very scarce resource. Chris> It won't help if we all start using IPSEC in place of SSL to Chris> talk to web servers (is this ever likely?), but it would help Chris> with VPNs. For most of us, the web server case is indeed not that likely for now, but John Gilmore certainly is pushing hard that way. paul From owner-ipsec@lists.tislabs.com Tue Feb 29 12:52: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 MAA16878; Tue, 29 Feb 2000 12:52:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA28314 Tue, 29 Feb 2000 14:22:08 -0500 (EST) Message-Id: <200002291927.OAA14536@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing In-Reply-To: Your message of "Tue, 29 Feb 2000 17:13:38 GMT." <1FD60AE4DB6CD2118C420008C74C27B81D051B@baltimore.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Feb 2000 14:27:04 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chris" == Chris Trobridge writes: Chris> It won't help if we all start using IPSEC in place of SSL to talk to web Chris> servers (is this ever likely?), but it would help with VPNs. But, please note that HTTPS currently has no protection against denial of service attacks. Even ISAKMP as it is now, before TCP would provide a huge increase in resistance against DOS. :!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 Feb 29 16:15: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 QAA22161; Tue, 29 Feb 2000 16:15:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29118 Tue, 29 Feb 2000 17:57:56 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Chris Trobridge'" , "'Andrew Krywaniuk'" , "'IPSEC Mailing List @ tis labs'" Subject: RE: Use of Encryption in Heartbeat Packets Date: Tue, 29 Feb 2000 18:09:18 -0500 Message-Id: <006101bf830a$020c37d0$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: <1FD60AE4DB6CD2118C420008C74C27B81D0518@baltimore.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Chris, > I was more concerned that you though encryption would provide a quick > authentication check and strengthen the authentication. Encryption does provide a "quick authentication check." In formal-speak, encryption provides an O(1) authentication check of a NbnS indicator of packet validity. (NbnS = Necessary, but not Sufficient) As the term (NbnS) implies, you still have to do the full check later. > Ok, re-reading, you > do say this is strengthening is only useful where the authentication > algorithm is weak in the first place. I could be wrong, but > I wasn't aware > that the prescribed authentication algorithms were weak in this way. Encryption also strengthens the authentication by preventing a known plaintext analysis of the hash. Of course, no one that we know of currently has the ability to break an MD5 MAC by known plaintext analysis, which is why this property provides no tangible benefit (except for that warm, fuzzy feeling you get knowing that no one can read your packets). > You do go on to say that encryption helps you reject large > spoofed packets > more quickly than authentication alone thus helping defeat a > DOS attack. > This was the other point I was questioning. I assume you mean this comment: > > > An attacker can still modify later bytes in > > > the datagram > > > which would pass any sensible decryption test but not the > > > authentication > > > check. 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/clientpuzzles.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 _______________________________________________ Beauty without truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Tue Feb 29 19:47: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 TAA03697; Tue, 29 Feb 2000 19:47:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA29893 Tue, 29 Feb 2000 21:28:41 -0500 (EST) Message-Id: <10003010237.AA03121@Ichiko.imailab.iis.u-tokyo.ac.jp> From: Kanta Matsuura Date: Wed, 01 Mar 2000 11:37:22 +0900 To: Paul Koning Cc: neo@silkroad.com, ipsec@lists.tislabs.com Subject: Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing In-Reply-To: <200002291551.KAA17349@tonga.xedia.com> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, Since I also think CPU protection is important, http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt improves the DoS-resistance of IKE in terms not only of memory resource but also of CPU resource. My opinion is that CPU is more important in a sense that memory exhaustion can be numerically evaluated (please have a look at K. Matsuura and H. Imai. ``Resolution of ISAKMP/Oakley Key-Agreement Protocol Resistant against Denial-of-Service Attack''. Proc. of Internet Workshop'99 (IWS'99), IEEE Press, pp. 17-24, 1999 available from http://imailab-www.iis.u-tokyo.ac.jp/Members/kanta/iws99cr.ps.gz ) if CPU is protected. Do you have any other reasons (why the most significant resource is CPU power rather than state memory) ? 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. ---- **** ---- Kanta MATSUURA, Ph.D. Lecturer 3rd Department, Institute of Industrial Science, University of Tokyo, Roppongi 7-22-1, Minato-ku, Tokyo 106-8558, JAPAN Tel: +81-3-3402-6231 (ext. 2325) Fax: +81-3-3479-1736 E-Mail: kanta@iis.u-tokyo.ac.jp