From owner-ipsec@portal.ex.tis.com Mon Feb 1 04:46:29 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA04531; Mon, 1 Feb 1999 04:46:28 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id EAA00196 for ipsec-outgoing; Mon, 1 Feb 1999 04:52:19 -0500 (EST) Message-Id: <3.0.1.32.19990201154924.00687fe0@206.40.37.34> X-Sender: ramana@206.40.37.34 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 01 Feb 1999 15:49:24 +0500 To: ipsec@tis.com From: Ramana Yarlagadda Subject: Ike - Auth using digital signatures. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi We need some clarifications in IKE ( authentication using Digital Signature). Kivinen writes : > That is true, but it doesn't matter. Extra certificates are cheap > inside the ike messages, if they save one extra ldap search from the > directory... It means that if at all a CERT payload comes in the exchange, we are just verifying the signature in the CERT payload. But dont we need to verify the certificate by looking at the CRLs using some directory service and finding out whether it is revoked or not ? Some more questions : * When sending a CERT-REQ to the other peer, how do we decide which is the CA to send in the body of the CERT-REQ payload ? means, the CA which is commonly trusted by both the peers in a CA heirarchy.. If the certificates are issued by two different CAs to the peers * How do we discover the path from our CA to the peer's CA? If the peers share the same CA, how do we know that? How do we know which CA is com- -mon to both the peers in the heirarchy of CAs ? How do we take care of cross-certified roots in path discovery? * When the peer sends a CERT payload which consists of a chain, it consists of multiple CERT payloads in any order (i.e., it doesnt need to send the chain in a hierarchical fashion). In this case, how do we verify the chain? * What does verification of a CERT chain mean anyway? The verification of the signature that is part of every certificate using the public key of the issuer? -thanks - ramana. From owner-ipsec@portal.ex.tis.com Mon Feb 1 05:02:52 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA04611; Mon, 1 Feb 1999 05:02:52 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA00271 for ipsec-outgoing; Mon, 1 Feb 1999 05:27:20 -0500 (EST) Message-Id: <3.0.3.32.19990201014156.00b23290@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 01 Feb 1999 01:41:56 -0800 To: Frank Kastenholz , Stephen Kent From: Alex Alten Subject: Re: transport-friendly ESP Cc: Steve Bellovin , ipsec@tis.com, jis@MIT.EDU, mleech@nortel.ca, tf-esp@research.att.com In-Reply-To: <3.0.3.32.19990131101536.0098abe0@shultz.argon.com> References: <3.0.3.32.19990130194427.00afa230@mail> <3.0.3.32.19990127200721.00b553e0@mail> <199901280234.VAA03373@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Frank, Thank you for your detailed analysis about why a block cipher like DES will not work for a core router. It's a bit like saying why a 2400 baud modem won't work either. Why can't we design, implement and verify a cipher that can meet these constraints you point out in such detail? We are engineers who don't hesitate to design complex new protocols, yet when it comes to designing a new cipher we become extremely timid. If we cannot create ciphers to meet our needs then why bother doing secure protocols? All we are doing is chasing our own tail trying to work around the limitations of DES, etc. We know the asymptotic speed limit of any cipher, either an XOR or an indexed memory lookup operation. Generally speaking on today's modern CPU's these are limited to how fast you can move data from main memory through the L2 & L1 caches and back out to main memory. On a Pentium one can get 1.5 cycle/Byte, on a PPro 200 about 1 c/B, and on a PP II about .8 c/B. Any extra computations should be simple, few in number and only on L1 cached data. I contend that it should be feasible to develop a cipher that can come close to meeting your performance and memory constraints. However having said all that, I do agree that it will be a long time before the core routers would do any crypto. - Alex P.S. BTW, DES lived well beyond its design lifetime without a single hyperadenoidal, asocial, teenager cracking it. -- Alex Alten Alten@Home.Com Alten@TriStrata.Com P.O. Box 11406 Pleasanton, CA 94588 USA (925) 417-0159 From owner-ipsec@portal.ex.tis.com Mon Feb 1 08:06:50 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA05934; Mon, 1 Feb 1999 08:06:50 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA00755 for ipsec-outgoing; Mon, 1 Feb 1999 08:17:21 -0500 (EST) Date: Mon, 1 Feb 1999 15:37:18 +0200 (EET) From: Markku Savela Message-Id: <199902011337.PAA25180@anise.tte.vtt.fi> To: Alten@home.com CC: ipsec@tis.com In-reply-to: <3.0.3.32.19990201014156.00b23290@mail> (message from Alex Alten on Mon, 01 Feb 1999 01:41:56 -0800) Subject: Re: transport-friendly ESP [hop-by-hop encryption ] Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk I've some difficulty in seeing what significant advantage would blind hop-by-hop IPSEC encryption of transit traffic serve (co-operating SG's are also end-to-end in a way). Without end-to-end IPSEC, an eavesdropper would only need to find one weak router on the path to break the security. So why waste resources for something that doesn't provide much utility? Am I missing something? However, I suppose every additional security does not hurt either, if someone wants to assign the resources. It would protect one link, but would anyone trust that their packets always take a route where all hops are protected and routers secure? If I have sensitive data, I would use end-to-end protection. Of course, for connecting to the router box for maintenance and other similar purposes, IPSEC is the right thing again. (As to transport-friendly ESP, I feel kind of "violated" if some random router peeks inside my packets, so I prefer ESP as is :-) -- 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@portal.ex.tis.com Mon Feb 1 08:08:38 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA05957; Mon, 1 Feb 1999 08:08:37 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA00662 for ipsec-outgoing; Mon, 1 Feb 1999 08:03:19 -0500 (EST) Date: Mon, 1 Feb 1999 15:23:22 +0200 (EET) Message-Id: <199902011323.PAA28210@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Kalyan Chakravarthy Bade" Cc: , Subject: Where should be the CERT payload in IKE ? In-Reply-To: <01be4b57$59d323c0$320110ac@garfield.roc.com> References: <01be4b57$59d323c0$320110ac@garfield.roc.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 6 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Kalyan Chakravarthy Bade writes: > In section 3.6 of isakmp draft, it is stated that the Certificate payload > MUST be accepted at any point during an exchange. Whereas in IKE, > it is given as part of only fifth and sixth messages in the main mode > exchange. Can we assume that if at all CERT payload is exchanged, > it is done ONLY in fifth and sixth messages of main mode ? In IKE there is only exchange examples, the pictures are not meant to be authorative (for example they never list initial contact etc notifications). The IKE rfc says: ---------------------------------------------------------------------- ... Exchanges in IKE are not open ended and have a fixed number of messages. Receipt of a Certificate Request payload MUST NOT extend the number of messages transmitted or expected. ... 5.1 IKE Phase 1 Authenticated With Signatures ... One or more certificate payloads MAY be optionally passed. ... ---------------------------------------------------------------------- so certificates may exists in all messages. Certificate requests may exists in all other messages execpt where it would extend the exchange. -- 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@portal.ex.tis.com Mon Feb 1 08:17:12 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06023; Mon, 1 Feb 1999 08:17:11 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA00776 for ipsec-outgoing; Mon, 1 Feb 1999 08:19:19 -0500 (EST) Date: Mon, 1 Feb 1999 15:39:55 +0200 (EET) Message-Id: <199902011339.PAA28324@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Lewis McCarthy Cc: IP Security WG List Subject: Re: New IPSec Monitoring MIB draft In-Reply-To: <36B4E0A2.F7FC3379@cs.umass.edu> References: <319A1C5F94C8D11192DE00805FBBADDF7750E8@exchange> <199901292217.RAA10569@brill.shiva.com> <199901300329.FAA06680@torni.ssh.fi> <36B4E0A2.F7FC3379@cs.umass.edu> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 5 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Lewis McCarthy writes: > > Yes, you can have multiple certificates, but at the end you only have > > ONE end user public key you use in the authentication take from the > > certificate. There isn't a reason to include the whole path, only the > > end user certificate used in the authentication is really interesting. > This last point isn't obvious to me. In view of the work on trust metrics > for certification paths, I imagine that examining the whole path might be > useful. Since the overall authentication relies upon the entire path, I'm > not sure why you would single out the terminal cert for inclusion in the MIB. Mostly, because that information can be quite large, and getting it can be quite hard. Also the management statition etc can do the same path validation procedures than the ike did if it wants. One thing we might want to add is to add table of trusted CA-certificates in the MIB, so the management station etc can do that path finding itself. I just don't see currently any reason to include all of the certificates used in the authentication, and including them doesn't provide any usefull information that is not available already. -- 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@portal.ex.tis.com Mon Feb 1 08:18:56 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06041; Mon, 1 Feb 1999 08:18:55 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA00870 for ipsec-outgoing; Mon, 1 Feb 1999 08:41:24 -0500 (EST) MR-Received: by mta GEMAIL.MUAS; Relayed; Mon, 01 Feb 1999 14:57:51 +0000 MR-Received: by mta GEMAIL; Relayed; Mon, 01 Feb 1999 14:58:48 +0000 Disclose-recipients: prohibited Date: Mon, 01 Feb 1999 14:57:51 +0000 (GMT) From: Sergio Torassa Subject: VPN draft To: ipsec@tis.com Message-id: <3851571401021999/A07427/GEMAIL/11D20BB93200*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Sensitivity: Company-Confidential UA-content-id: 11D20BB93200 X400-MTS-identifier: [;3851571401021999/A07427/GEMAIL] Hop-count: 1 Sender: owner-ipsec@ex.tis.com Precedence: bulk In the Internet Draft on Remote Access over the Internet using IPSec another draft is cited: "implementation of virtual private networks with IP Security". I looked for it but I didn't find anything. Could anyone give me a clue? regards, Sergio Torassa ------------------------------------------------- Sergio Torassa Marconi Communications Phone: +39 010 6002916 Fax: +39 010 6508698 e-mail: sergio.torassa@marconicomms.com ------------------------------------------------- From owner-ipsec@portal.ex.tis.com Mon Feb 1 09:31:36 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06663; Mon, 1 Feb 1999 09:31:36 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA01080 for ipsec-outgoing; Mon, 1 Feb 1999 09:27:22 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF7A583A@exchange> From: Tim Jenkins To: Ricky Charlet , "'ipsec@tis.com'" Subject: RE: New IPSec Monitoring MIB draft Date: Mon, 1 Feb 1999 09:48:45 -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@ex.tis.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Ricky Charlet [mailto:rcharlet@redcreek.com] > Sent: Friday, January 29, 1999 4:48 PM > To: 'Tim Jenkins'; 'ipsec@tis.com' > Subject: RE: New IPSec Monitoring MIB draft > > > Howdy () > I have some questions about the ipsecProtSuite Table > and identities. > > Suppose that I have an IPSec SA bundle made up of one AH SA > and one ESP SA > and one Comp SA. This bundle was built as a unit by a single > IKE negotiation > with a single peer. > > > So now I have in my box one each of: > ipsecProtSuiteInboundEspSpi > ipsecProtSuiteOutboundEspSpi > ipsecProtSuiteInboundAhSpi > ipsecProtSuiteOutboundAhSpi > ipsecProtSuiteInboundCompCpi > ipsecProtSuiteOutboundCompCpi > > Where ipsecProtSuiteLocalAddress and ~RemoteAddress are the > same for all the > above. > > Now I build a query for some statistical value (ex PolicyErrors)of a > ProtSuite and get the whole table as ordered by 'index' > > I expect to get the "total number of inbound packets > discarded [...] due to > policy errors" which have passes across these THREE SAs since there > instantiation (don't sweat counter wraps for this discussion) > at one single > indexed table entry. > > But, (and here come my questions) Is there a way to monitor > individual SAs? No, but remember, the selectors for all SAs in the protection suite are the same. This means (in the case of policy errors) that the policy rule for the packet says "Apply ESP+AH" (for example), not "Apply ESP and then check to see of AH should be applied". The latter is not a protection suite, but it is still an SA bundle. In that case the protection suite table would have at two entries. One entry puts ESP on the packet, while the second puts AH on the ESP packet that resulted from the first encapsulation. > Can I expect an indexed entry for EspSpis with 0 for the AH and Comp > Spis/Cpis? Would I then get the total number of inbound > packets discarded > due to policy errors on just the ESP SA? This seems a little > cumbersome to > dig into individual SAs and also seems to allow enough > ambiguity to muck > with inter-vendor consistency. I'm not sure what you're asking here. Protection suites with no ESP have an ESP SPI of 0; all the stats and error apply to the AH/IPCOMP if they are used. > > Did/could we consider an approach where we have a table of > ESP SAs, a table > of AH SAs, a table of Comp SAs and then a table of ProtSuite > bundles which > refers to appropriate values (or formulas of values) from > those first three? I did look at this. However, ISAKMP explicitly states that protection suites are to be treated as a single unit. The multi-table approach was much more complicated, and did not add what I believe significant value. > > Now let me anticipate the question, "What would be the value > of measuring > individual SAs?" > > First, I acknowledge that measuring statistics on "protSuites" is very > useful! This closly paralles link monitoring which is of > highest concern to > O&M groups. I certainly believe that protSuite measuring (as > opposed to > individual SA measuring) will be the most common application > for this mib > and be the most customer demanded feature (just my gut > feeling, not any > official survey). > > But I see three needs for finer grain visibility into IPSec devices. > 1. drill down trouble shootin' for finer fault isolation > 2. pattern recognition to identify attack profiles > 3. device capacity monitoring, so that total number of SAs may be > tracked as well as traffic count summations on comp, ESP and AH I'm not sure that multiple tables will give you any significant benefit for points 1 and 2, given the nature of protection suites. Even for point 3, if you want to measure the total traffic that has ESP applied to it across all protections suites, you add up the traffic serviced by all protection suites that have ESP. That's because the user level traffic reported by ESP+AH, ESP, and AH protection suites should be the same. (Even with IPCOMP, the user level traffic reported should still be the same.) > > > So, I know this is a BIG SHIFT from the proposal (which has > just undergone a > BIG SHIFT). Let's talk it out... what do Y'all think? > > ################################### > # Ricky Charlet > # rcharlet@RedCreek.com > # (510) 795-6903 > ################################### > end Howdy; > From owner-ipsec@portal.ex.tis.com Mon Feb 1 09:36:33 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06737; Mon, 1 Feb 1999 09:36:33 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA01015 for ipsec-outgoing; Mon, 1 Feb 1999 09:17:18 -0500 (EST) To: Alex Alten Cc: Frank Kastenholz , Stephen Kent , Steve Bellovin , ipsec@tis.com, jis@MIT.EDU, mleech@nortel.ca, tf-esp@research.att.com Subject: Re: transport-friendly ESP References: <3.0.3.32.19990130194427.00afa230@mail> <3.0.3.32.19990127200721.00b553e0@mail> <199901280234.VAA03373@smb.research.att.com> <3.0.3.32.19990201014156.00b23290@mail> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 01 Feb 1999 09:37:30 -0500 In-Reply-To: Alex Alten's message of "Mon, 01 Feb 1999 01:41:56 -0800" Message-ID: <87vhhmb36d.fsf@jekyll.piermont.com> Lines: 15 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Alten writes: > Thank you for your detailed analysis about why a block > cipher like DES will not work for a core router. It's a > bit like saying why a 2400 baud modem won't work either. > > Why can't we design, implement and verify a cipher that can > meet these constraints you point out in such detail? Security has to be end to end. You can't trust the operators of every router on the internet. There is NOT ANY POINT in designing such a thing, even if one could, and one can't. Perry From owner-ipsec@portal.ex.tis.com Mon Feb 1 09:48:53 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06873; Mon, 1 Feb 1999 09:48:52 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA00918 for ipsec-outgoing; Mon, 1 Feb 1999 08:56:19 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF7A57F5@exchange> From: Tim Jenkins To: John Shriver Cc: ipsec@tis.com Subject: RE: New IPSec Monitoring MIB draft Date: Mon, 1 Feb 1999 09:17:38 -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@ex.tis.com Precedence: bulk John makes some very good points here, and when I first read it, I thought that perhaps we should be pursuing that route. However, I'm not sure anymore. Here's some of my concerns. 1) This group is IPSec centric, and perhaps not in the best position to attempt to define anything outside that area. I don't know of anyone using ISAKMP for something other than IPSec SA construction. If someone is, and has an interest in their MIBs being part of this, we should hear about. The bottom line in this point is that I'm concerned that any non-IKE/IPSec work we do would either be wrong or incomplete. 2) John's suggestions essentially define a couple of base tables, and a whole bunch of table augmentations. According to RFC1902, the time to use augmentations (rather than indices into one table from another) is when the augmentations apply to all rows in the base table. So, if someone is using ISAKMP for both IKE and for other purposes, the augmentations defined here possibly should not be used. This appears to be the justification for using augmentations; in that the augmentations separate the DOI specific elements. On the other hand, if an implementation is using ISAKMP only for IKE, then the only justification for separate tables is for better configuration of what is to be retrieved and presented. In this case, the same DOI is being used everywhere. 3) The definition of IKE/IPSec specific use of ISAKMP does not preclude the definition of generic ISAKMP MIBs, or ISAKMP MIBs for other DOIs. 4) Increased complexity will delay development and implementation. This proposal feels much more complex. -- Anyway, while I do comment on details, John has opened up the entire architecture again, so we need to focus our attention on nailing that down first. I notice that Tero has commented on details; that's great, but we really, really need to talk about the architecture. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: John Shriver [mailto:jas@shiva.com] > Sent: Friday, January 29, 1999 5:17 PM > To: tjenkins@TimeStep.com > Cc: ipsec@tis.com > Subject: Re: New IPSec Monitoring MIB draft > > > OK, now I've had a chance to work on my IPSec DOI textual conventions, > I know the MIB well enough to comment on it in structure and in > detail. > > Sorry folks, but it's a BIG message. I've got lots to say here... This is also very long. > > STRUCTURE > ========= > > The first issue is that this is not, as written an IPSec Monitoring > MIB. It is an IKE monitoring MIB. The structure assumes IKE in every > grain, despite the notes that you could use it with manual keys. It > also completely assumes the IPSec DOI, despite the fact that there > have been active proposals for other DOIs (RIP, OSPF). Also, there > are already two DOI's, ISAKMP (0), and IPSEC (1). > > So, we need to be more careful of where we hang this in the MIB tree. > There should be a object identifier { ipsec }, but it shouldn't be > where this MIB hangs directly on. Instead, this mib should be > > ikeMonitoring OBJECT IDENTIFIER ::= { ipsec 1 } > > or something like that. Well, really there should be branches for > ipsec, for isakmp, for ike, etc... > > If you don't get the numbering right up front, you wind up having to > throw a lot away later, unmaintainable. See the end where I rough out the start of the architecture that I believe is being suggested here. Comments, please. > > LAYERING > ======== > > I think we need to try and be much more careful about our layering. > There is a first layer that assumes nothing but IPSec proper. There > is a next layer that assumes ISAKMP, but nothing above that. Then > there is a layer that assumes IKE with the IPSEC DOI. (Or should we > split that too?) This all works fine with the AUGMENTS model of > SMIv2. > Here's where I get concerned about complexity. I think we do need layers, but I start to question the value added after we get too many. > PHASE 1 > ======= > > So, there should be a isakmpSaTable. It would contain, and (in my > opinion) be indexed by, the two cookies. As data, it would have only > the IPv4/IPv6 address of each peer, the UDP port of each peer, the > ISAKMP major version, the ISAKMP minor version, the mode, and the > Domain of Interpretation. You can't put in the Protocol-ID, it's > within the DOI. > > So you have: > > isakmpSaInitiatorCookie OCTET STRING (SIZE (16)) *** index > isakmpSaResponderCookie OCTET STRING (SIZE (16)) *** index > isakmpSaLocalIpAddress OCTET STRING (SIZE (4 | 16)) > isakmpSaLocalUdpPort INTEGER (0..65535) > isakmpSaLocalMajorVersion INTEGER (0..15) > isakmpSaLocalMinorVersion INTEGER (0..15) > isakmpSaRemoteIpAddress OCTET STRING (SIZE (4 | 16)) > isakmpSaRemoteUdpPort INTEGER (0..65535) > isakmpSaRemoteMajorVersion INTEGER (0..15) > isakmpSaRemoteMinorVersion INTEGER (0..15) > isakmpSaMode INTEGER { base(1), > identityProtection(2), authOnly(3), > agressive(4) } > isakmpSaDoi Unsigned32 > > Note that I support all the Phase 1 ISAKMP modes, even though IKE only > uses identityProtection(2) and aggressive(4). I don't see the point in having version numbers for both ends. They're going to operate at the level of lowest numbered version of the two anyway, and the local version is likely to be fixed for the entity. This implies we need entity objects for the version numbers, rather than columns. > > We need to note that the isakmpSaResponderCookie is 0 when the > initiator has sent it's first packet, but no response has been > received. > > As you can see, I still want to index without creating arbitrary > indices. But, even if I lose on that issue, the table will have some > index, allowing it to be augmented. > It's not clear to me what the objection is to a number as an index. Does it not make it easier to refer to the table entries from other objects? > Augmented tables aren't performance pigs, since the indexing > code/hooks/overhead can be shared by all the tables if you like. > There is a bit more overhead of skipping those entries that aren't > relevant when the augmentation is partial. But RFC1902 wants to discourage this kind of application. However, would I be correct in guessing that's not what's happening in practise??? > > The first table augmenting this would be ISAKMP SA's using DOI 0 for > Phase 1 identification. (Reference sections 3.4 and A.4 of RFC 2408 > and section 4 paragraph 8 of RFC 2409.) This would be > isakmpSaDoi0Table, partially augmenting isakmpSaTable, having: > > isakmpSaDoi0LocalIdType INTEGER { ipv4(0), ipv4Subnet(1), > ipv6(2), ipv6Subnet(3) } > isakmpSaDoi0LocalId OCTET STRING (SIZE (4 | 8 | 16 | 32)) > isakmpSaDoi0RemoteIdType INTEGER { ipv4(0), ipv4Subnet(1), > ipv6(2), ipv6Subnet(3) } > isakmpSaDoi0RemoteId OCTET STRING (SIZE (4 | 8 | 16 | 32)) > > (Maybe this needs other elements?) I'm not even sure we want to define this as part of the IPSec working group (or whatever we are now). If none of us are using it, it might better be left, rather than slowing the MIB's progress. > > The second, and far more commonly used, table augmenting isakmpSaTable > would be isakmpSaDoi1Table, having: > > isakmpSaDoi1LocalIdType INTEGER { reserved(0), idIpv4Addr(1), > idFqdn(2), idUserFqdn(3), > idIpv4AddrSubnet(4), idIpv6Addr(5), > idIpv6AddrSubnet(6), > idIpv4AddrRange(7), idIpv6AddrRange(8), > idDerAsn1Dn(9), idDerAsn1Gn(10), > idKeyId(11) } > isakmpSaDoi1LocalId OCTET STRING (SIZE (0..511)) > isakmpSaDoi1RemoteIdType INTEGER { reserved(0), idIpv4Addr(1), > idFqdn(2), idUserFqdn(3), > idIpv4AddrSubnet(4), idIpv6Addr(5), > idIpv6AddrSubnet(6), > idIpv4AddrRange(7), idIpv6AddrRange(8), > idDerAsn1Dn(9), idDerAsn1Gn(10), > idKeyId(11) } > isakmpSaDoi1RemoteId OCTET STRING (SIZE (0..511)) > > (You may ask why two tables? Well, the syntax of > isakmpSaDoi1LocalIdType is not the same as isakmpSaDoi0LocalIdType. > If you want to decode symbolically, you have to have a seperate table > for each DOI.) > > Then we can work our way up to ikePhase1SaTable. This augments > isakmpSaTable, since you can use IKE with Phase 1 ID's of DOI 0 or 1. Why are you separating the ikePhase1SaTable from the isakmpSaDoi1Table? The production of phase 1 (IKE) SAs is the purpose of using DOI 1 with a phase 1 ISAKMP exchange. > This would have: > > ikePhase1SaAuthMethod INTEGER > ikePhase1SaEncAlg INTEGER > ikePhase1SaEncKeyLength INTEGER > ikePhase1SaHashAlg INTEGER > ikePhase1SaDifHelGroupDesc INTEGER > ikePhase1SaDifHelGroupType INTEGER > ikePhase1SaInboundOctets Counter64 > ikePhase1SaOutboundOctets Counter64 > ikePhase1SaInboundPackets Counter32 > ikePhase1SaOutboundPackets Counter32 > ikePhase1SaProtSuitesCreated Counter32 > ikePhase1SaProtSuitesDeleted Counter32 > ikePhase1SaCurrentProtSuites Gauge32 -- new... > ikePhase1SaDecryptErrors Counter32 > ikePhase1SaAuthErrors Counter32 > ikePhase1SaOtherRecieveErrors Counter32 > ikePhase1SaSendErrors Counter32 > > Now, this table needs some expansion over the variables that were in > the ipsecIkeSaTable. We need the full parameters of the > Diffie-Hellman group, since all are negotiable in Phase 1 and Phase > 2. So, throw in: > > ikePhase1SaDifHelGroupPrime OCTET STRING > ikePhase1SaDifHelGroupGenOne Integer32 (or must it be OCTET STRING?) > ikePhase1SaDifHelGroupGenTwo Integer32 (") > ikePhase1SaDifHelGroupCurveA Integer32 (") > ikePhase1SaDifHelGroupCurveB Integer32 (") > ikePhase1SaDifHelGroupOrder OCTET STRING > > Then, we have to decide if the MIB is obligated to fill in these > values for standard Groups, or whether it is filled on only when the > GroupType is 0. Or perhaps it's clearer if we define GroupType to be > -1 if non-standard, or have a TruthValue SYNTAX variable incidating > non-standard group. I had most or all of this in a very early version of the MIB and a number of comments were that this was too much, and it should be left out. There appears to be a desire to not put excessive stuff in that will not seem to get a lot of use. Comments???? > > As for the SA lifetime variables, I think Counter64 is safe. Really, > who is going to use "bignum" math in their SA's to count the lifetime > in kbytes? Nobody will accept (or properly implement) a lifetime with > a length greater than 8 bytes. For that matter, I think lifetimes in > seconds can be limited to 4 bytes, that's 136 years. (68 years if you > want to allow for sign bugs.) These are really flaws in the DOI, it > doesn't prohibit insane values... Fair enough on this; my original version with Unsigned32 for life times got alot of complaints, so clearly there is a desire for 64 bit values. > > Next, I'd rather have a seperate variable for lifetime in > kbytes versus > lifetime in seconds. Why? Becuase you can then put proper UNITS > statements on each. So, we would have: > > ikePhase1SaLifeType INTEGER { none(0), seconds(1), > kilobytes(2) } > ikePhase1SaTimeStart DataAndTime > ikePhase1SaTimeLimit Counter32 UNITS "Seconds" > ikePhase1SaByteLimit Counter64 UNITS "Kilobytes" The dual expirations limits are already there. As Tero has stated in another reply, both may be used simultaneously. > > You might want to make ikePhase1SaTimeStart optional, not all systems > may have the facilities to determine DateAndTime. This might raise > the issue of wanting to add: > > ikePhase1SaTimeActive Counter32 UNITS "Seconds" > > for calendar-challenged implementations. If acceptable, I'd rather drop the DateAndTime if the above is sufficient. Comments? > > Now we come to another major issue. There is no limit of one > Certificate Payload per SA. You ROUTINELY will have a chain of > certificates. But that's not possible with this MIB. So, we need a > table for certs. But, the cert formats are all documented in ISAKMP, > not IKE, so we push it back to being more generic. Thus we create > isakmpPhase1CertTable. The first two indices would be the > augmentation of isakmpSaTable. The last index would be an integer > from 1 to (say) 1000, for each of the Phase 1 certs for this SA. > (There has to be some upper limit on the number of certs, if only due > to maximum UDP packet size of 65535!) > > Here's the data I'd put in: > > isakmpPhase1SaCertIndex INTEGER (1..1000) *** last index > isakmpPhase1SaCertType INTEGER { pkcs7(1), pgp(2), ... } > isakmpPhase1SaCertData OCTET STRING (SIZE (1..65530)) > isakmpPhase1SaCertSerial OCTET STRING (SIZE (1..63)) > isakmpPhase1SaCertIssuer OCTET STRING > > I don't see the need to put "Peer" in the name, since this is a table > only of Peer certificates. (Does bring up the issue, should we have a > global table of our own Certs?) I strongly disagree with this. It's not even required that peers exchange certificates, much less the entire chain in phase 1. This means that the chain may not even be available to the IKE implementation. If the ID, issuer and serial number of the peer are what is used, this may then be used to access tables of certificates that be defined outside the scope of this MIB. I don't dispute that a table like this should exist; I believe it should be part of whatever certificate is being used by the host implementation. Perhaps the pki requirements draft would like to comment on this. Further, by your logic, we would have to create a similar table for CRLs. Again, I believe this to be outside the scope of IPSec. > > Another thing to think about when we reach peer certificates is the > identity protection issues. ISAKMP and IKE go to great lengths to > ensure identity protection. Now we go and put all those identities in > a MIB. Obviously, there have to be different MIB views that can and > cannot see the identity information. (These views would probably be > different for SNMPv1, SNMPv2c, SNMPv3 with crypto, and perhaps any > SNMP with Transport mode ESP.) We should be careful to have seperate > tables with sensitive information, to make it easier to configure the > MIB views. (Otherwise they will have to protect individual collumns > in tables, which is a configuration pain in the butt.) I'd like comments from the group relating to how far we want to take protection of the tables as far as sensitive information. Right now it's all or nothing, and I'd really like to keep it that way. Is there really any particular table that is significantly more or less sensitive to other to make this complexity worh while, given that aggressive mode does not provide identity protection? > > So far, I'm OK on that score, as isakmpSaDoi0Table, isakmpSaDoi1Table, > and isakmpPhase1CertTable, are all standalone tables full of > "identity" information. > > DATA SA'S > ========= > > As I've noted before, I really want to see tables of the individual > SA's, indexed by the true indices of the SA's. However, we have to > have one table per SA type, because SPI's are unique only within one > security protocol (AH, ESP, IPCOMP). (See section 2.1 of RFC 2408.) > We also have to do this because the additional uniqueness criteria (IP > address, which is optional as a SPI discriminator in ISAKMP) are not > necessarily the same for each security protocol. Also, the other > annoying problem is that the numbering space for security protocols is > DOI-specific. > > So, I would like to see ahSaTable, espSaTable, and ipcompSaTable. > Each is indexed by destination IP address and SPI. > > Another reason for seperate tables is that ipcomp is optional. This > makes it easy to leave out everything about ipcomp. > > Further, after the Destination and SPI, everything else is specific to > DOI 1. (Magic numbers.) That's handy, since all the DOI 1 > information is security-sensitive, you again you want it in a seperate > table to simply view control. > > So, for instance, on AH: > > ahSaDestination OCTET STRING (SIZE (4 | 16)) > ahSaSpi Unsigned32 > > Then there is ahSaDoi1Table, indexed by the previous table's indices: > > ahSaDoi1AuthAlgorithm INTEGER > > Similarly for ESP: > > espSaTable:: > espSaDestination > espSaSpi > > augmented by espSaDoi1Table:: > espSaDoi1Encapsulation > espSaDoi1EncryptAlg > espSaDoi1EncryptKeyLength > espSaDoi1AuthAlgorithm > > Finally, for IPCOMP: > > ipcompSaTable:: > ipcompSaDestination > ipcompSaSpi > > augmented by ipcompSaDoi1Table:: > ipcompSaDoi1Algorithm > > Given my comments below on protection suites, I really don't understand what you're getting at above, and why such a fine granularity is desired. > PROTECTION SUITES > ================= > > What does the proposed ipsecProtSuiteTable do during the 30 second > rekey period (per Tim's draft-jenkins-ipsec-rekey-00.txt) when two > sets of SA's are active? Just show the new ones and leave the old > ones orphans? What do you mean orphans? Active? These are re-keying issues, and the MIB should be completely independent of this. Every created SA/protection suite occupies a row of a table. If I had my way, we would be re-keying using the oldest SAs until they were used up. In this case, you could have an arbitrary number of pre-negotiated SAs ready for use with the same selectors. The RFCs even state that this is possible, even though it didn't work out that way for phase 2 SAs. > > Very clear rules need to be laid out when a protection suite table > entry can be changed in-place, and when it must be replaced by a new > one. Certainly, if the Local ID or Remote ID change, it's a new > protection suite. But changes in the SPI's don't cause a new row. Yes they do. No matter how you do it, one protection suite table or three SA by protocol tables, new SAs have their own identity in the table. As you stated, the index to each row is the SPI (and protocol and address). > > Obviously, if the above AH, ESP, and IPCOMP tables are created, the > corresponding entries would be removed from the protection suite > table. > > Also, protection suites are a specifically IKE-specific concept, > methinks. So, lets name the table ikeProtSuiteTable. Protection suites are specifically defined in ISAKMP. See section 2.1 and paragraph 2 of section 4.2, for example. ISAKMP is used to negotiate protection suites; SAs are simply single security service versions of protections suites, (As a side issue, protection suites are a specific type of SA bundle, which the current MIB does not show.) > > It would be really nice if there was some way to have the Protection > Suite entry point back to the Phase 1 SA. We could have the two > cookies, with a syntax similar to IfIndexOrZero, where Zero means that > the Phase I SA is no longer there. (If I can't win the cookie index, > then it can be the arbitrary index, where 0 is a reserved index.) Based on comments from Tero Kivinen, the real interest is in knowing what authenticated IDs were used when the protection suite was created. This implies that the reference in the protection suite entry back to phase 1 should be the local and peer id objects (and their types). While this means they don't point to a single SA, it does does allow a system to point to any SA that may control them. > > There's rather a mish-mosh between Inbound/Outbound and Local/Remote > in the proposed table. That will get realy confusing if we create the > proper 4 variables: > > ikeProtSuiteLocalLocalPort > ikeProtSuiteLocalRemotePort > ikeProtSuiteRemoteLocalPort > ikeProtSuiteRemoteRemotePort > > Probably better to do Inbound/Outbound consistently. > > Another approach to inbound/outbound would be to have the table > changed from full-duplex to half-duplex, and make the last index be > INTEGER { inbound(1), outbound(2) }. Half as many MIB variables to > define and implement, at the cost of one more dimension. Also > addresses simplex connections, if such a thing becomes important. This sounds reasonable, given that there more fewer shared objects between the inbound and outbound pairs. However, I think it's important that the pairs that are created together are marked as such, since they will be deleted together. > > We probably want to make an augmenting table with the error counters, > since that's security sensitive. Maybe the traffic counters belong > there as well. Again, it's not clear to my why the table augmentation is that valuable. Perhaps I over-estimate the complexity to define and implement it. > > Should there be a "status" variable? What would the status be? These SAs are either statically created, or created by some key exchange protocol. Maybe instead of status, a "how created" variable?? > > Again, as in the ISAKMP SA, we need the FULL set of Diffie-Hellman > group parameters. > Again, as in earlier documents, I had these and took them out. Has anyone had a change of heart on this?? > > REPLAY COUNTERS > =============== > > I'd like to propose two more counters for receive replay events. The > first would count "out of order" packets. The second wound count > "lost" packets. > > The out of order counter would increment whenever you received an > anti-replay counter lower than the previously received one, but it is > has not be received before. This is a handy QOS measurement, you can > tell if the Internet between the peers is shuffling packets on you. > > The lost counter would be incremented every time you slid the > anti-replay window, and some of the "flags" that you slid away were > for packets you never recieved. This is another indication of the QOS > the Internet is providing. > > Since monitoring the QOS of the underlying Internet is generally a > VERY hot button on VPN, I think that these would be really valuable > counters. > > To interpret the latter counter, you also need to know the size of the > receive anti-replay window, so add a variable for that. > Ouch. Now I agree that an optional augmentation is in order. > NOTIFY TABLE > ============ > > Every notify message has a Protocol-ID field. This needs to be added > as an index to the notify count table. > > Also, there's a DOI in the Notification Payload. So we need to make > it DOI 1 specific. Also, some of the message types are DOI 1 > specific. (Most are ISAKMP generic.) > > So, it should be isakmpNotifyDoi1CountTable: > > isakmpNotifyDoi1ProtocolId INTEGER { isakmp(1), ah(2), > esp(3), ipcomp(4) } > isakmpNotifyDoi1MessageType INTEGER { invalidPayloadType(1), > doiNotSupported(2), ... } > isakmpNotifyDoi1Count Counter32 > > With the first two variables being the two indices (in order). This seems reasonable. > It would also be nice to have a scalar variable containing the > Notification Data from the last received Notify Payload. This may be > a helpful human-readable string. This could be passed along with the > trap(s) generated on receiving such messages. However, we'd need to > make the size rather limited, given the 576 byte limit on trap > PDU's... The notification data is not only DOI specific, it is message type specific in the IPSec DOI. Given the trap limit you mention, passing it at all is not practical, unless we develop some coding rules. > The following is what I believe the architecture should be if we go that route. Someone tell I'm wrong, and that we can or can't do something like: ISAKMP-MIB DEFINITIONS ::= BEGIN IMPORTS ... isakmpMIB MODULE-IDENTITY ... -- ::= { mib-2 ?? } ::= { experimental 500 } isakmpMIBObjects OBJECT IDENTIFIER ::= { isakmpMIB 1 } isakmp OBJECT IDENTIFIER ::= { isakmpMIBObjects 1 } ... isakmpSaTable OBJECT-TYPE ... ::= { isakmp 1 } isakmpSaEntry OBJECT-TYPE ... ::= { isakmpSaTable 1 } IsakmpSaEntry ::= SEQUENCE { ... } ... isakmpGenericDoiTable OBJECT-TYPE ... ::= { isakmp 2 } isakmpGenericDoiEntry OBJECT-TYPE ... AUGMENTS { isakmpSaEntry } ::= { isakmpGenericDoiTable 1 } IsakmpGenericDoiEntry ::= SEQUENCE { ... } ... END IKE-MIB DEFINITIONS ::= BEGIN IMPORTS stuff from isakmpMIB ... ikeMIB MODULE-IDENTITY ... -- ::= { mib-2 ?? } ::= { experimental 501 } ikeMIBObjects OBJECT IDENTIFIER ::= { ikeMIB 1 } ike OBJECT IDENTIFIER ::= { ikeMIBObjects 1 } ... ikeSaTable OBJECT-TYPE ... ::= { ike 1 } ikeSaEntry OBJECT-TYPE ... AUGMENTS { isakmpSaEntry } ::= { ikeSaTable 1 } IkeSaEntry ::= SEQUENCE { ... } ... END protection suite tables are part of ipsecMIBObjects..., temporarily under the experimental 502.... Does this make it too large to get pushed through? It would also require three separate documents, and perhaps a fourth to put them all together? From owner-ipsec@portal.ex.tis.com Mon Feb 1 09:48:56 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06882; Mon, 1 Feb 1999 09:48:56 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA01330 for ipsec-outgoing; Mon, 1 Feb 1999 09:52:22 -0500 (EST) Message-Id: <3.0.3.32.19990201084641.0093d680@shultz.argon.com> X-Sender: kasten@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 01 Feb 1999 08:46:41 -0500 To: Alex Alten From: Frank Kastenholz Subject: Re: transport-friendly ESP Cc: ipsec@tis.com, tf-esp@research.att.com In-Reply-To: <3.0.3.32.19990201014156.00b23290@mail> References: <3.0.3.32.19990131101536.0098abe0@shultz.argon.com> <3.0.3.32.19990130194427.00afa230@mail> <3.0.3.32.19990127200721.00b553e0@mail> <199901280234.VAA03373@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 01:41 AM 2/1/99 -0800, Alex Alten wrote: >Frank, > >Thank you for your detailed analysis about why a block >cipher like DES will not work for a core router. It's a >bit like saying why a 2400 baud modem won't work either. I didn't say it won't work. I said it won't happen. We could put all that stuff into silicon for a greater cost and lower performance than the market is willing to bear right now. >Why can't we design, implement and verify a cipher that can >meet these constraints you point out in such detail? For the same reason that the IETF does not go off and come up with some new kind of semiconductor lasers to make faster optical links. We do protocols. Someone else does semiconductor lasers, or encryption algorithms. Besides, there are other issues besides encryption algorithms, such as key distribution. If each router along the path is supposed to decrypt the packet, or a part of it, then that router needs the key. How do you do it? The path may be 10, 20, 30, ... routers long. Plus the path will change over time, and the end stations do not know when that happens. The path might even go through someplace that you don't trust. (At one point in time, the ISP we then used had its pop in a wiring closet in a facility owned by one of our competitors. Any key exchange with that router would go through wires that were accessible to that competitor, to a router that was accessible to that competitor. If they were sufficiently shady and sufficiently motivated, our communications could have been compromised). Frank Kastenholz From owner-ipsec@portal.ex.tis.com Mon Feb 1 09:57:25 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06975; Mon, 1 Feb 1999 09:57:24 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA01269 for ipsec-outgoing; Mon, 1 Feb 1999 09:50:21 -0500 (EST) From: Barney Wolff To: ipsec@tis.com, tf-esp@research.att.com Date: Mon, 1 Feb 1999 09:27 EST Subject: Hop-by-hop considered boring Content-Type: text/plain Message-ID: <36b5bbb20.c8e@databus.databus.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk With all due respect, argument on the feasibility of hop-by-hop encryption is irrelevant. Exposure of the cleartext to intermediate routers is unacceptable in all interesting cases. (The preceding may be taken as a definition of "interesting".) Barney Wolff From owner-ipsec@portal.ex.tis.com Mon Feb 1 09:57:57 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA06985; Mon, 1 Feb 1999 09:57:56 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA01366 for ipsec-outgoing; Mon, 1 Feb 1999 09:53:20 -0500 (EST) Date: Sun, 31 Jan 1999 06:44:40 GMT Message-Id: <199901310644.GAA06712@chimp.juniper.net> From: Tony Li To: kent@bbn.com CC: Alten@home.com, smb@research.att.com, ipsec@tis.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, jis@MIT.EDU, mleech@nortel.ca In-reply-to: (message from Stephen Kent on Fri, 29 Jan 1999 15:55:41 -0500) Subject: Re: transport-friendly ESP Sender: owner-ipsec@ex.tis.com Precedence: bulk Please, please, please, please... Take this thread off of every list except end2end-interest. Thanks, Tony | The purpose of IPsec is to offer end-to-end protection, so applying IPsec | on a per-hop basis is feasible, but findamentally counter to the underlying | motivation for these protocols, since the begining of this work (too) many | years ago. From owner-ipsec@portal.ex.tis.com Mon Feb 1 09:59:14 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07003; Mon, 1 Feb 1999 09:59:14 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA01329 for ipsec-outgoing; Mon, 1 Feb 1999 09:52:22 -0500 (EST) Message-ID: <36B34971.C76F50E1@lucent.com> Date: Sat, 30 Jan 1999 13:03:30 -0500 From: Sashidhar Annaluru Organization: Lucent Technologies X-Mailer: Mozilla 4.05 [en]C-EMS-1.4 (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: A question about re-keying Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, I have two questions about Re-Keying of Phase2 IKE. 1. Can any peer initiate re-keying? Or is there any restriction saying that only the initiator of first session can initiate subsequent pahse2 re-keying? 2. If there is no such restriction, then I have some confusions about the Proxy IDs of phase2. Consider the following scenario: Initial IKE is done between I1 and R1, where I1 is the initiator and R1 is the responder. For this session I1 sets the ProxyIDs IDci1 and IDcr1 for phase2, where IDci1 is initiator's ProxyID and IDcr1 is the responder's. Now if R1 initiates the re-keying of phse2, then what should it send in ProxyIDs and how? (a)Should it send, the same Proxy IDs IDci1 and IDcr1? or (b)Should it swap those two and send IDcr1 as the initiator proxyID (IDci2) and IDci1 as the responder ProxyID (IDcr2)? If it does (a), then isn't it confusing to interpret the proxyIDs? Even though these ProxyIDs make sense for the first session, with respect to the second session (which is re-keying) the initiator is R1 and the initiator's ProxyID is IDci1. Which is not right, because IDci1 is really the I1's proxyID. Can any body clarify me with this subject, or is there any draft which specifies these confusions? Thanks in advance Sashidhar Annaluru avs@lucent.com (908)-582-4105 From owner-ipsec@portal.ex.tis.com Mon Feb 1 09:59:38 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA07012; Mon, 1 Feb 1999 09:59:38 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA01332 for ipsec-outgoing; Mon, 1 Feb 1999 09:52:23 -0500 (EST) Message-Id: <199902011512.KAA08028@postal.research.att.com> To: perry@piermont.com Cc: Alex Alten , Frank Kastenholz , Stephen Kent , ipsec@tis.com, jis@MIT.EDU, mleech@nortel.ca, tf-esp@research.att.com Subject: Re: transport-friendly ESP Date: Mon, 01 Feb 1999 10:12:49 -0500 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <87vhhmb36d.fsf@jekyll.piermont.com>, "Perry E. Metzger" writes: > > Alex Alten writes: > > Thank you for your detailed analysis about why a block > > cipher like DES will not work for a core router. It's a > > bit like saying why a 2400 baud modem won't work either. > > > > Why can't we design, implement and verify a cipher that can > > meet these constraints you point out in such detail? > > Security has to be end to end. You can't trust the operators of every > router on the internet. There is NOT ANY POINT in designing such a > thing, even if one could, and one can't. Oh, it can and does exist, and it's useful in some contexts. But it's then called link encryption, not network layer encryption, and it has very different security properties. For most of the threat models that ipsec is intended to deal with, link encryption is quite useless. From owner-ipsec@portal.ex.tis.com Mon Feb 1 10:03:57 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA07097; Mon, 1 Feb 1999 10:03:56 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA01302 for ipsec-outgoing; Mon, 1 Feb 1999 09:51:20 -0500 (EST) Message-Id: <3.0.3.32.19990131101536.0098abe0@shultz.argon.com> X-Sender: kasten@shultz.argon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 31 Jan 1999 10:15:36 -0500 To: Alex Alten , Stephen Kent From: Frank Kastenholz Subject: Re: transport-friendly ESP Cc: Steve Bellovin , ipsec@tis.com, jis@MIT.EDU, mleech@nortel.ca, tf-esp@research.att.com In-Reply-To: <3.0.3.32.19990130194427.00afa230@mail> References: <3.0.3.32.19990127200721.00b553e0@mail> <199901280234.VAA03373@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 07:44 PM 1/30/99 -0800, Alex Alten wrote: >Steve K., > >As a technology spreads it starts to be used in ways that may >not have been intended by the original designers. Possibly IPSEC >is better suited for per hop protection within a security system >which maintains and enforces intermediate node trustworthiness. Ok, I'll say it again. No. No, No, a thousand times No. Most routers at the "core" of the internet (i.e. pretty much every router from when a packet enters my ISP until it emerges from the ISP at its destination) use, or shortly will use, hardware-based forwarding. Putting security "stuff" - running encryption algorithms or message digest hashes, simply won't happen in the near term because - The lookup for the security attributes takes memory accesses which are in short supply. At OC48 the max packet rate is something like 6.2M/sec. If your memory can do 100M accesses/second, that gives you about 16 accesses per pacet before fifos back up. Think about it. - Core Routers often channel many different Interfaces through a single ASIC (i.e. they have multiple internal contexts). Each such stream represents one or more packets that could be going through the crypto-goop. Crypto-goop requires that there are intermediate results that have to be generated with "this" chunk of data and then used on the "next" such chunk in the stream. This increases storage requirements on the chips, or memory accesses to save and then retrieve the state. And memory accesses are precious resources, not to be used lightly. - Encryption and hashing algorithms change frequently as hyperadenoidal, asocial, teenagers crack the current ones. Redesigning the ASICs in the router every time this happens, and then doing an upgrade of all the routers, is a non starter. - The NRE to the FAB alone is on the order of 1M. Thats $ spent before you even think about the designers of it, etc, etc, etc. - The turnaround time is measured in months. You can't pull a couple of all-nighters, quickly test some code, and ship out new CDs by the end of the week. There's probably a minimum of 4-6 months here. - It requires board replacement. No sockets today. ASICs can have _lots_ of "pins" - 1500, 2000, or more... That means replacing boards in the field and scrapping the boards that are there now... - Encryption and hashing algorithms typically have lots of repetitive operations. A typical chunk of data is processed many times. Each 'pass' through the process can probably be done in one tick, but you've got P passes through the process for each chunk, taking P ticks per chunk -- and the line rate is probably less than P ticks/chunk. eg, assume a 100MHz asic and OC48. OC48 is ~300MB/sec - about 3B/tick. To receive a single 8B chunk takes ~3 ticks -- how many times do you have to look at those bytes if doing DES? This problem, btw, is alleviated by pipelining and parallizing things -- looking at chunks from different packets at different points in parallel -- but that means more storage, etc, on the ASIC which consumes space for the storage and space for the multiple pipeline stages... To repeat myself Core routers will most likely not be doing any crypto stuff in the forwarding path for the next several years, at least. Any solution based on an assumption that they will is simply not going to happen. Frank Kastenholz From owner-ipsec@portal.ex.tis.com Mon Feb 1 10:18:35 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA07285; Mon, 1 Feb 1999 10:18:34 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA01529 for ipsec-outgoing; Mon, 1 Feb 1999 10:03:21 -0500 (EST) To: Steve Bellovin Cc: Alex Alten , Frank Kastenholz , Stephen Kent , ipsec@tis.com, jis@MIT.EDU, mleech@nortel.ca, tf-esp@research.att.com Subject: Re: transport-friendly ESP References: <199902011512.KAA08028@postal.research.att.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 01 Feb 1999 10:23:28 -0500 In-Reply-To: Steve Bellovin's message of "Mon, 01 Feb 1999 10:12:49 -0500" Message-ID: <877lu2b11r.fsf@jekyll.piermont.com> Lines: 13 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve Bellovin writes: > Oh, it can and does exist, and it's useful in some contexts. But > it's then called link encryption, not network layer encryption, > and it has very different security properties. Encrypting the link is a very different thing. One usually doesn't even bother with doing things per packet -- you literally just encrypt the leased line. I'll agree that this isn't pointless -- my point was that the vision of all the routers in the world doing hop-by-hop IPSec was pointless. Perry From owner-ipsec@portal.ex.tis.com Mon Feb 1 11:36:15 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA08048; Mon, 1 Feb 1999 11:36:14 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA02022 for ipsec-outgoing; Mon, 1 Feb 1999 11:31:24 -0500 (EST) Date: Mon, 1 Feb 1999 11:51:16 -0500 Message-Id: <199902011651.LAA01636@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alten@home.com Cc: kasten@argon.com, ipsec@tis.com Subject: Re: transport-friendly ESP References: <3.0.3.32.19990130194427.00afa230@mail> <3.0.3.32.19990127200721.00b553e0@mail> <199901280234.VAA03373@smb.research.att.com> <3.0.3.32.19990131101536.0098abe0@shultz.argon.com> <3.0.3.32.19990201014156.00b23290@mail> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Alex" == Alex Alten writes: Alex> Frank, Thank you for your detailed analysis about why a block Alex> cipher like DES will not work for a core router. It's a bit Alex> like saying why a 2400 baud modem won't work either. I didn't see the message you're replying to; my guess is that it appeared on the tf-esp list (which I don't see). Alex> Why can't we design, implement and verify a cipher that can Alex> meet these constraints you point out in such detail? We are Alex> engineers who don't hesitate to design complex new protocols, Alex> yet when it comes to designing a new cipher we become extremely Alex> timid. I should hope so. Creating protocols is a completely trivial exercise by comparison, yet it's hard enough. The number of competent cryptographers in the world is very small. Many engineers are smart enough to know they are not competent cryptographers. (Unfortunately, some, either through ignorance or otherwise, think that they are.) I assume you know about the AES effort. Apart from that, there are additional existing cyphers that may be faster and/or more secure than DES. Alex> We know the asymptotic speed limit of any cipher, either an XOR Alex> or an indexed memory lookup operation. Generally speaking on Alex> today's modern CPU's these are limited to how fast you can move Alex> data from main memory through the L2 & L1 caches and back out Alex> to main memory. On a Pentium one can get 1.5 cycle/Byte, on a Alex> PPro 200 about 1 c/B, and on a PP II about .8 c/B. Any extra Alex> computations should be simple, few in number and only on L1 Alex> cached data. I contend that it should be feasible to develop a Alex> cipher that can come close to meeting your performance and Alex> memory constraints. I don't see that the CPU data moving timings have any relevance whatsoever in a discussion about crypto on core routers. Core routers don't do anything relating to forwarding in anything resembling a general purpose CPU. If you want to talk high speed crypto, you need to examine what the state of the art allows for data rates in custom ASIC implementations. Those numbers are actually quite high, close to what core routers would need. For example, a 1 Gb/s DES implementation was done back in 1992 (DEC SRC report #90). And that one wasn't even pipelined so you should be able to do quite a lot better with today's densities. Alex> However having said all that, I do agree that it will be a long Alex> time before the core routers would do any crypto. That's probably true, but I'm not sure that performance is the argument for it. Rather, since end to end is the most useful way of doing crypto, you wouldn't do it at core routers because they are not at any end. paul From owner-ipsec@portal.ex.tis.com Mon Feb 1 11:54:04 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA08211; Mon, 1 Feb 1999 11:54:04 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA02082 for ipsec-outgoing; Mon, 1 Feb 1999 11:33:25 -0500 (EST) Message-Id: <199902011653.LAA23818@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com@tis.com;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-monitor-mib-00.txt Date: Mon, 01 Feb 1999 11:53:17 -0500 Sender: owner-ipsec@ex.tis.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 : IPSec Monitoring MIB Author(s) : T. Jenkins Filename : draft-ietf-ipsec-monitor-mib-00.txt Pages : 44 Date : 29-Jan-99 This document defines low level monitoring and status MIBs for IPSec. It does not define MIBs that may be used for configuring IPSec implementations or for providing low-level diagnostic or debugging information. It assumes no specific use of IPSec. Further, it does not provide policy information. The purpose of the MIBs is to allow system administrators to determine operating conditions and perform system operational level monitoring of the IPSec portion of their network. Statistics are provided as well. Additionally, it may be used as the basis for application specific MIBs for specific uses of IPSec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-monitor-mib-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-monitor-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-monitor-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990129110009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-monitor-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-monitor-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990129110009.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@portal.ex.tis.com Mon Feb 1 12:32:49 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA08787; Mon, 1 Feb 1999 12:32:48 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA02339 for ipsec-outgoing; Mon, 1 Feb 1999 12:27:23 -0500 (EST) Date: Mon, 1 Feb 1999 12:47:49 -0500 Message-Id: <199902011747.MAA12208@brill.shiva.com> From: John Shriver To: ipsec@tis.com Subject: IPSec MIB and "augmenting" Sender: owner-ipsec@ex.tis.com Precedence: bulk I suppose I didn't make myself clear enough by what I was thinking of in the way of augmentation. I didn't mean the literal AUGMENTS statement in many cases, since the "augmenting" table may not instantiate every row of the base table. I was thinking more of the way that the IETF Interface MIBs parallel the MIB-II ifTable. That is, if this ISAKMP Phase 1 SA is also a IKE Phase I SA, then there will be a row in the IKE Phase I SA table. More importantly, the indices won't be duplicated as data elements. The two cookies will only be assigned object identifiers in the ISAKMP Phase 1 SA table. The other tables will be indexed by the indices of the primary table. The only cases where I can see a strict AUGMENTS would be in the case where two tables are identical in indexing and row instantiation, but are of very different security sensitivities. For instance, if we were insane enough to want a column with ESP crypto keys (yikes!), you would want it in a table that strictly AUGMENTS the ESP SA table. From owner-ipsec@portal.ex.tis.com Mon Feb 1 13:39:44 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA09426; Mon, 1 Feb 1999 13:39:44 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA02487 for ipsec-outgoing; Mon, 1 Feb 1999 13:05:21 -0500 (EST) Date: Mon, 1 Feb 1999 13:26:17 -0500 Message-Id: <199902011826.NAA12232@brill.shiva.com> From: John Shriver To: ipsec@tis.com Subject: My IPSec MIB structuring motivations Sender: owner-ipsec@ex.tis.com Precedence: bulk One thing I realize I didn't put much text into was some of the motivations for my layering of the IPSec MIB. Sure, one possible consideration was for people using ISAKMP with something other than IKE. But, those people (presently) are so in the "black" that they probably have no intention of ever having a MIB, it's too much of a security issue for them! Certainly, they're not going to offer us much design assistance (much less admit who they work for). But, the IPSec community could wind up implementing a replacement for IKE, if some tragic security flaw were to be found. It would be nice if we didn't have to design a whole new set of MIBs when that happens, but instead could just define a limited set of new tables for "Son of IKE". Also, I wanted a MIB that still made some sense in an environment where there are non-IKE Security associations. Let's remember that dynamic keying is still nominally an optional part of the IPSec stack. Some of the complexity is also due to the motivation of defining a group of TEXTUAL-CONVENTIONS for all the DOI1 and IKE magic numbers. Moreover, the values of these MIB enumerations would be exactly the same as their on-the-wire encoding, to simplify implementation. (These TC's would be managed by the IANA as they assign more of those magic numbers.) Thus, any variable using one of those textual conventions must be in a DOI1-specific place in a MIB. If we want to establish our own number space for all these magic numbers, with different values than on the DOI's, then we don't have to make the per-DOI tables for all the ISAKMP stuff. But I think that makes continuing management of the number space a much bigger pain in the behind... Then there's the whole nuisance of supporting IPv6. One side of me would like seperate v4 and v6 tables, with the v4 tables having the canonical encoding (IpAddress) of IPV4 addresses. But that would result in massive duplicate tables. But, we've no pretty solution, since the SNMP SMI doesn't have CHOICE OF from real ASN.1. I suppose a really strange approach would be to have seperate IPv4 and IPv6 address fields in each table. Only one would be non-zero in a given row. If the table needs to be indexed by the address, you just index it by BOTH of them. One all zeros in every row. But at least you can make the IPv4 one be SYNTAX IpAddress. The current scheme has the annoying feature that IPv[46]Address indexes will have to be instantiated with a length octet or 4 or 16 in front of them. I suppose this is one reason Tim avoided indexing by IP address. From owner-ipsec@portal.ex.tis.com Mon Feb 1 18:17:31 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA12797; Mon, 1 Feb 1999 18:17:30 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA03374 for ipsec-outgoing; Mon, 1 Feb 1999 18:22:21 -0500 (EST) Date: Tue, 2 Feb 1999 01:43:06 +0200 (EET) Message-Id: <199902012343.BAA19691@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Sashidhar Annaluru Cc: ipsec@tis.com Subject: A question about re-keying In-Reply-To: <36B34971.C76F50E1@lucent.com> References: <36B34971.C76F50E1@lucent.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min X-Total-Time: 2 min Sender: owner-ipsec@ex.tis.com Precedence: bulk Sashidhar Annaluru writes: > 1. Can any peer initiate re-keying? Yes. > Or is there any restriction saying that only the initiator of first > session can initiate subsequent pahse2 re-keying? No, there is no restriction like that. > 2. If there is no such restriction, then I have some confusions > about the Proxy IDs of phase2. > > Consider the following scenario: > > Initial IKE is done between I1 and R1, where I1 is the initiator > and R1 is the responder. For this session I1 sets the ProxyIDs IDci1 > and IDcr1 for phase2, where IDci1 is initiator's ProxyID and IDcr1 > is the responder's. > > Now if R1 initiates the re-keying of phse2, then what should it send in > ProxyIDs and how? > > (a)Should it send, the same Proxy IDs IDci1 and IDcr1? or > (b)Should it swap those two and send IDcr1 as the initiator > proxyID (IDci2) and IDci1 as the responder ProxyID (IDcr2)? It must swap those. Rekey initiator sends first its own proxy ID and then the remote ends proxy ID. -- 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@portal.ex.tis.com Tue Feb 2 09:22:36 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA13284; Tue, 2 Feb 1999 09:22:35 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA05550 for ipsec-outgoing; Tue, 2 Feb 1999 08:16:21 -0500 (EST) Message-ID: <36B5F738.674E6AF5@nortel.ca> Date: Mon, 01 Feb 1999 19:49:28 +0100 From: "Marcus Leech" Organization: Security Development X-Mailer: Mozilla 2.02 (X11; I; Linux 1.2.13 i486) MIME-Version: 1.0 To: Alex Alten CC: Frank Kastenholz , Stephen Kent , Steve Bellovin , ipsec@tis.com, jis@MIT.EDU, "Marcus Leech" , tf-esp@research.att.com Subject: Re: transport-friendly ESP References: <3.0.3.32.19990130194427.00afa230@mail> <3.0.3.32.19990127200721.00b553e0@mail> <199901280234.VAA03373@smb.research.att.com> <3.0.3.32.19990201014156.00b23290@mail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Alex Alten wrote: > > Frank, > > However having said all that, I do agree that it will be > a long time before the core routers would do any crypto. > Jumping in in the middle here: Why should core routers do any significant crypto? Apart from the peeking-in-so-I-can-do-stuff requirements of Steve Bellovins tf-esp proposal, I can't see why they'd need to be a party to any security association. Even if we have blazing-fasting algorithms that could reasonably be put in a core router, I can't really see the need. My security requirements are end to end, and I'll be damned if I'll let some ISP I know nothing about, run by a pimply-faced teenage moron, be a party to my security associations. To have all the core routers be a party to security associations is to reduce the security of the internet to what is in the (virtual) copper world of today. Core routers WILL do crypto, but not because they need to provide decrypt--do-some-stuff--encrypt services to client data streams. They'll do crypto because that's the only secure way to manage them over the network--a very much lower bandwidth requirement than handling crypto on client data streams. -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Security and Internet Solutions Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Technology mleech@nortel.ca -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec@portal.ex.tis.com Tue Feb 2 10:15:16 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA13916; Tue, 2 Feb 1999 10:15:15 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA05744 for ipsec-outgoing; Tue, 2 Feb 1999 08:50:23 -0500 (EST) Message-ID: <36B70817.56E726CC@assured-digital.com> Date: Tue, 02 Feb 1999 09:13:44 -0500 From: Andrew Sweeney X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com Subject: Question about mis-match SA lifetimes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Who wins when there is a mismatch in SA lifetimes. Is the initiators value always used, do you negotiate down to the lowest value, or do you just reject the proposal? Thanks Andy -- Andrew Sweeney andy@assured-digital.com 9 Goldsmith Street, Littleton, MA 01460 http://www.assured-digital.com/ From owner-ipsec@portal.ex.tis.com Tue Feb 2 21:14:17 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA02624; Tue, 2 Feb 1999 21:14:17 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA08669 for ipsec-outgoing; Tue, 2 Feb 1999 21:03:05 -0500 (EST) Message-Id: <199902030223.SAA27582@chip.cisco.com> To: Andrew Sweeney cc: ipsec@tis.com Subject: Re: Question about mis-match SA lifetimes In-reply-to: Your message of "Tue, 02 Feb 1999 09:13:44 EST." <36B70817.56E726CC@assured-digital.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27580.918008608.1@cisco.com> Date: Tue, 02 Feb 1999 18:23:28 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Good question. It's not really possible to negotiate down to the lowest value since this is a simple request-response protocol. RFC2407, in section 4.5.4, defines 3 things you can do if someone offers you a lifetime which is greater than the one you have configured: 1) fail the negotiation; 2) complete the negotiation but just use the locally configured, shorter, time; or, 3) complete the negotiation and notify the peer what the real lifetime you're using is. But that only works with phase 2 negotiation because RFC2409, sadly, does not define a notify message analagous to the DOI's RESPONDER-LIFETIME. So the only options for phase 1 are 1 or 2: fail the negotiation or just ignore what the operator has configured. One of the action items from http://www.lounge.org/ike_doi_errata.html is to rectify that though. Keep in mind that if you choose option 1 you may have a difficult time going through the "certification" process. One of the presumptions of the "certification" testing is that IPSec and IKE policy are commutative. That's a flawed premise (enforcement of SA lifetime and Diffie-Hellman group policy are examples of how you can configure things such that Alice can successfully initiate to Bob but Bob can't successfully initiate to Alice) and I had a helluva time explaining that when our box which chooses option 1 for phase 1 negotiation (it does option 3 for phase 2) was tested against the ACME corporation box which choose option 2 for phase 1. When I initiated to ACME it could care less what the lifetime I offered was and accepted; when ACME initiated to me I enforced my locally configured policy (under the assumption that it was put that way for a reason by the operator) and failed. Dan. On Tue, 02 Feb 1999 09:13:44 EST you wrote > Hi, > > Who wins when there is a mismatch in SA lifetimes. Is the initiators > value always used, do you negotiate down to the lowest value, or do you > just reject the proposal? > > Thanks > Andy From owner-ipsec@portal.ex.tis.com Wed Feb 3 09:36:06 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23292; Wed, 3 Feb 1999 09:36:06 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA10865 for ipsec-outgoing; Wed, 3 Feb 1999 09:43:04 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05CF0C@md-exchange1.nai.com> From: "Mason, David" To: "'ipsec@tis.com'" Subject: RE: Question about mis-match SA lifetimes Date: Wed, 3 Feb 1999 07:03:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Suppose that both sides negotiate to use the same lifetime. Locally you will enforce that lifetime but there is no guarantee that the other side enforces that lifetime properly. This can therefore reduce to being the same thing as if they offered a longer lifetime than what you enforce according to your local policy. This being the case, what's the merit in choosing option 1? Do you expect an exact match on the lifetimes(s) - i.e., do you fail the negotiation if the lifetime offered is less than what you have configured as well? Along the same line. If their certificate would expire before the lifetime(s) would expire, do you fail the negotiation or just enforce the lifetime(s) to not extend past the expiration of their certificate? I would be curious as to how many implementations reduce the lifetime that they offer to limit it to the expiration of their own certificate. -dave > -----Original Message----- > From: Daniel Harkins [SMTP:dharkins@cisco.com] > Sent: Tuesday, February 02, 1999 9:23 PM > To: Andrew Sweeney > Cc: ipsec@tis.com > Subject: Re: Question about mis-match SA lifetimes > > Good question. It's not really possible to negotiate down to the > lowest value since this is a simple request-response protocol. RFC2407, > in section 4.5.4, defines 3 things you can do if someone offers you a > lifetime which is greater than the one you have configured: 1) fail the > negotiation; 2) complete the negotiation but just use the locally > configured, shorter, time; or, 3) complete the negotiation and notify the > peer what the real lifetime you're using is. > From owner-ipsec@portal.ex.tis.com Wed Feb 3 09:40:01 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23340; Wed, 3 Feb 1999 09:40:01 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA10739 for ipsec-outgoing; Wed, 3 Feb 1999 09:16:04 -0500 (EST) Message-ID: <01BE4F58.7AF9F330.jcastonguay@motus.qc.ca> From: James Castonguay Reply-To: "jcastonguay@motus.qc.ca" To: "ipsec@tis.com" Subject: Question about the situation field of the SA payload. Date: Wed, 3 Feb 1999 09:35:04 -0000 Organization: Motus technologies inc X-Mailer: Messagerie Internet de Microsoft/MAPI - 8.0.0.4211 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Can anyone help me in clarifying the use of the situation in the SA payload (introduce in the IPDOI). I.e. Where the value for the following fields are defined? 1) "secrecy level" 2) "secrecy category bitmap" 3) "Integrity level" 4) "integrity category bitmap" thanks in advance James From owner-ipsec@portal.ex.tis.com Wed Feb 3 12:57:06 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25738; Wed, 3 Feb 1999 12:57:05 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA11606 for ipsec-outgoing; Wed, 3 Feb 1999 12:43:02 -0500 (EST) Message-Id: <199902031802.KAA21179@chip.cisco.com> To: "Mason, David" cc: "'ipsec@tis.com'" Subject: Re: Question about mis-match SA lifetimes In-reply-to: Your message of "Wed, 03 Feb 1999 07:03:16 PST." <447A3F40A07FD211BA2700A0C99D759B05CF0C@md-exchange1.nai.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21177.918064967.1@cisco.com> Date: Wed, 03 Feb 1999 10:02:47 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk You're right, there's no guarantees on anything. The other side could encrypt the key, SPI and destination address in Louis Freeh's public key and send it off to him. But the lack of guarantees shouldn't mean that no policy enforcement should be done. I figure that the operator set the lifetime for a reason (and since a key from the IKE SA can be the "root key" for lots of IPSec SAs that may be a very good reason) and not just on a whim. To ignore that setting is wrong. To answer your question: no, I don't fail if the other side offers a time that's less than mine. I accept it and I respect it. If my lifetime is 2 hours and the peer offers 1 hour I delete the SA after 1 hour. Dan. On Wed, 03 Feb 1999 07:03:16 PST you wrote > Suppose that both sides negotiate to use the same lifetime. Locally you > will enforce that lifetime but there is no guarantee that the other side > enforces that lifetime properly. This can therefore reduce to being the > same thing as if they offered a longer lifetime than what you enforce > according to your local policy. This being the case, what's the merit in > choosing option 1? Do you expect an exact match on the lifetimes(s) - i.e., > do you fail the negotiation if the lifetime offered is less than what you > have configured as well? > > Along the same line. If their certificate would expire before the > lifetime(s) would expire, do you fail the negotiation or just enforce the > lifetime(s) to not extend past the expiration of their certificate? I would > be curious as to how many implementations reduce the lifetime that they > offer to limit it to the expiration of their own certificate. > > -dave From owner-ipsec@portal.ex.tis.com Wed Feb 3 13:03:17 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25825; Wed, 3 Feb 1999 13:03:16 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA11738 for ipsec-outgoing; Wed, 3 Feb 1999 13:18:03 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05CF12@md-exchange1.nai.com> From: "Mason, David" To: "'ipsec@tis.com'" Subject: RE: Question about mis-match SA lifetimes Date: Wed, 3 Feb 1999 10:38:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk If the peer has an IKE SA lifetime configuration of 2 hours, and locally you have an IKE SA lifetime configuration of 1 hour, then wouldn't it be more advantageous to allow the phase 1 negotiation to proceed and then just send a delete notification for the IKE SA cookie after 1 hour, right before you expire your IKE SA, then to just always fail the negotiation? -dave > -----Original Message----- > From: Daniel Harkins [SMTP:dharkins@cisco.com] > Sent: Wednesday, February 03, 1999 1:03 PM > To: Mason, David > Cc: 'ipsec@tis.com' > Subject: Re: Question about mis-match SA lifetimes > > You're right, there's no guarantees on anything. The other side could > encrypt the key, SPI and destination address in Louis Freeh's public key > and send it off to him. But the lack of guarantees shouldn't mean that no > policy enforcement should be done. I figure that the operator set the > lifetime for a reason (and since a key from the IKE SA can be the "root > key" > for lots of IPSec SAs that may be a very good reason) and not just on a > whim. To ignore that setting is wrong. > > To answer your question: no, I don't fail if the other side offers a > time that's less than mine. I accept it and I respect it. If my lifetime > is 2 hours and the peer offers 1 hour I delete the SA after 1 hour. > > Dan. From owner-ipsec@portal.ex.tis.com Wed Feb 3 14:04:29 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27129; Wed, 3 Feb 1999 14:04:28 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA11912 for ipsec-outgoing; Wed, 3 Feb 1999 14:16:03 -0500 (EST) Date: Wed, 3 Feb 1999 14:35:38 -0500 From: hugh@mimosa.com ("D. Hugh Redelmeier") Message-Id: <199902031935.OAA04806@mimosa.com> To: ipsec@tis.com Subject: Quick Mode HASH(3) and optional payloads Sender: owner-ipsec@ex.tis.com Precedence: bulk RFC2409 (IKE) section 5.5 (Phase 2 - Quick Mode) describes HASH(3) in a way that does not specify that optional payloads should be included. [The whole wording for hashing of optional payloads and other payload orders seems to be tacked on in an unfortunate way.] I think that optional payloads should be fed into the hash function, after Nr_b. This would make HASH(3) more like HASH(1) and HASH(2). It would also provide checking for these optional payloads. - am I right in thinking that optional payloads are allowed in the initiator's second Quick Mode message? - am I right that the RFC does not specify that the HASH(3) includes optional payloads? - is there a good reason not to include the optional payloads in HASH(3)? - is there a good reason to include the optional payloads in HASH(3)? Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 From owner-ipsec@portal.ex.tis.com Wed Feb 3 14:48:00 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29038; Wed, 3 Feb 1999 14:47:59 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA12014 for ipsec-outgoing; Wed, 3 Feb 1999 14:44:06 -0500 (EST) Date: Wed, 3 Feb 1999 15:04:40 -0500 Message-Id: <199902032004.PAA21371@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: ipsec@tis.com Subject: RE: Question about mis-match SA lifetimes References: <447A3F40A07FD211BA2700A0C99D759B05CF12@md-exchange1.nai.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Mason," == Mason, David writes: Mason,> If the peer has an IKE SA lifetime configuration of 2 hours, Mason,> and locally you have an IKE SA lifetime configuration of 1 Mason,> hour, then wouldn't it be more advantageous to allow the Mason,> phase 1 negotiation to proceed and then just send a delete Mason,> notification for the IKE SA cookie after 1 hour, right before Mason,> you expire your IKE SA, then to just always fail the Mason,> negotiation? I would have thought the same. In fact, it's not clear to me why the lifetime value needs to be mentioned in the protocol at all. If I think the SA has lived long enough, I can rekey. Whether the other side is more tolerant seems irrelevant. To put it differently: consider a hypothetical protocol that was just like IKE except that it doesn't exchange this information. What bad properties, if any, would such a protocol have? paul From owner-ipsec@portal.ex.tis.com Wed Feb 3 15:58:13 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02596; Wed, 3 Feb 1999 15:58:13 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA12271 for ipsec-outgoing; Wed, 3 Feb 1999 16:00:07 -0500 (EST) Message-Id: <199902032119.NAA02649@chip.cisco.com> To: Paul Koning cc: David_Mason@nai.com, ipsec@tis.com Subject: Re: Question about mis-match SA lifetimes In-reply-to: Your message of "Wed, 03 Feb 1999 15:04:40 EST." <199902032004.PAA21371@tonga.xedia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2644.918076767.1@cisco.com> Date: Wed, 03 Feb 1999 13:19:28 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk A delete message is not delivered reliably and to depend on it is foolhardy. Tim Jenkins has proposed a reliable delete message and that would work but we don't have it yet. Also, if RFC2409 had a RESPONDER-LIFETIME type of message ala RFC2407 that's work but it doesn't--yet. So, why care about how long the peer retains the SA and key I guess is the question. I've heard several people mention that a solution to the "failover" problem-- where the box crashes, reboots, loses all state, and silently drops incoming IPSec packets leaving the remote peer to try and figure out why-- is to save all SA information, including keys, on a disk somewhere. (Our product doesn't have a disk so I don't have that option but some people do). Not knowing whether a peer is doing this I can only assume that it is. So if I have a lifetime configured for 1 hour and the peer offers 12 hours, or worse doesn't even offer a lifetime, my assumption is that this key is sitting somewhere for 12 hours, or worse as long as the peer wants it to. Since this key can be used to generate lots and lots of IPSec SAs that might not be a good thing. Even disregarding the issue of storing the key in a file, I just get a warm fuzzy knowing that the peer has acknowledged that the key will be destroyed in accordance with my local policy. So maybe I'm paranoid (or maybe I'm ignorantly proscribing some security benefit where there is none). But there's also a knob to set the lifetime and if someone takes an affirmative step to actually set the lifetime on my box I assume he did it for a reason and I honor the policy configuration. Is there a similar knob on your product? Dan. On Wed, 03 Feb 1999 15:04:40 EST you wrote > >>>>> "Mason," == Mason, David writes: > > Mason,> If the peer has an IKE SA lifetime configuration of 2 hours, > Mason,> and locally you have an IKE SA lifetime configuration of 1 > Mason,> hour, then wouldn't it be more advantageous to allow the > Mason,> phase 1 negotiation to proceed and then just send a delete > Mason,> notification for the IKE SA cookie after 1 hour, right before > Mason,> you expire your IKE SA, then to just always fail the > Mason,> negotiation? > > I would have thought the same. In fact, it's not clear to me why the > lifetime value needs to be mentioned in the protocol at all. If I > think the SA has lived long enough, I can rekey. Whether the other > side is more tolerant seems irrelevant. > > To put it differently: consider a hypothetical protocol that was just > like IKE except that it doesn't exchange this information. What bad > properties, if any, would such a protocol have? > > paul From owner-ipsec@portal.ex.tis.com Wed Feb 3 16:02:50 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA03046; Wed, 3 Feb 1999 16:02:49 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA12346 for ipsec-outgoing; Wed, 3 Feb 1999 16:12:06 -0500 (EST) Message-ID: <36B8C110.56E944BC@assured-digital.com> Date: Wed, 03 Feb 1999 16:35:13 -0500 From: Andrew Sweeney X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Mason, David" CC: "'ipsec@tis.com'" Subject: Re: Question about mis-match SA lifetimes References: <447A3F40A07FD211BA2700A0C99D759B05CF12@md-exchange1.nai.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Is it me, or do you guys just make this up as you go? ;-) "Mason, David" wrote: > If the peer has an IKE SA lifetime configuration of 2 hours, and locally you > have an IKE SA lifetime configuration of 1 hour, then wouldn't it be more > advantageous to allow the phase 1 negotiation to proceed and then just send > a delete notification for the IKE SA cookie after 1 hour, right before you > expire your IKE SA, then to just always fail the negotiation? > > -dave > > > -----Original Message----- > > From: Daniel Harkins [SMTP:dharkins@cisco.com] > > Sent: Wednesday, February 03, 1999 1:03 PM > > To: Mason, David > > Cc: 'ipsec@tis.com' > > Subject: Re: Question about mis-match SA lifetimes > > > > You're right, there's no guarantees on anything. The other side could > > encrypt the key, SPI and destination address in Louis Freeh's public key > > and send it off to him. But the lack of guarantees shouldn't mean that no > > policy enforcement should be done. I figure that the operator set the > > lifetime for a reason (and since a key from the IKE SA can be the "root > > key" > > for lots of IPSec SAs that may be a very good reason) and not just on a > > whim. To ignore that setting is wrong. > > > > To answer your question: no, I don't fail if the other side offers a > > time that's less than mine. I accept it and I respect it. If my lifetime > > is 2 hours and the peer offers 1 hour I delete the SA after 1 hour. > > > > Dan. -- Andrew Sweeney andy@assured-digital.com 9 Goldsmith Street, Littleton, MA 01460 http://www.assured-digital.com/ From owner-ipsec@portal.ex.tis.com Wed Feb 3 19:24:06 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA21736; Wed, 3 Feb 1999 19:24:06 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA12857 for ipsec-outgoing; Wed, 3 Feb 1999 19:34:07 -0500 (EST) Date: Thu, 4 Feb 1999 02:54:10 +0200 (EET) Message-Id: <199902040054.CAA16692@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: hugh@mimosa.com ("D. Hugh Redelmeier") Cc: ipsec@tis.com Subject: Quick Mode HASH(3) and optional payloads In-Reply-To: <199902031935.OAA04806@mimosa.com> References: <199902031935.OAA04806@mimosa.com> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 6 min X-Total-Time: 6 min Sender: owner-ipsec@ex.tis.com Precedence: bulk D. Hugh Redelmeier writes: > RFC2409 (IKE) section 5.5 (Phase 2 - Quick Mode) describes HASH(3) in > a way that does not specify that optional payloads should be included. > [The whole wording for hashing of optional payloads and other payload > orders seems to be tacked on in an unfortunate way.] > I think that optional payloads should be fed into the hash function, > after Nr_b. This would make HASH(3) more like HASH(1) and HASH(2). > It would also provide checking for these optional payloads. True, and it doesn't even break anything, because I don't think there is any optional payloads in the third packet of the quick mode defined now... > - am I right in thinking that optional payloads are allowed in the > initiator's second Quick Mode message? Which option payload you could put there? Notify payload is only thing I can think about, and there is no currently defined use for that in the third message. Only status notification going from the initiator to the responder is INITIAL-CONTACT, and you can put that in the first packet. > - am I right that the RFC does not specify that the HASH(3) includes > optional payloads? At least I interpret that so. > - is there a good reason not to include the optional payloads in > HASH(3)? Not really. > - is there a good reason to include the optional payloads in HASH(3)? Yes, to give them protection. But because there is no NEED to use any optional payloads in the third message I think this issue can be ignored now, and added to the TODO list for the later revisions. -- 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@portal.ex.tis.com Thu Feb 4 04:24:37 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA24784; Thu, 4 Feb 1999 04:24:36 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id DAA13966 for ipsec-outgoing; Thu, 4 Feb 1999 03:41:08 -0500 (EST) Date: Thu, 4 Feb 1999 11:01:14 +0200 (EET) From: Markku Savela Message-Id: <199902040901.LAA28966@anise.tte.vtt.fi> To: ipsec@tis.com In-reply-to: <199902032119.NAA02649@chip.cisco.com> (message from Daniel Harkins on Wed, 03 Feb 1999 13:19:28 -0800) Subject: Re: Question about mis-match SA lifetimes Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, (me again with agenda? :0) This may be a bit off the topic, and concerns only the proper IPSEC SA's, not ISAKMP key negotiation SAs. I return to my old graphic on the basic SA negotiation transaction: H1 H2 ------------------------ ------------------ (0) IP:H1->H2 ->SA0 -> SA1 ==================> SA1 \ ^ ^ \ | | \ | | (1) ACQUIRE SA: H1->H2 | <-- Key Mgmnt --> | \ | -------------------(a)---------> (2) GETSPI: dst=H2 | UPDATE SA: dst=H2 | / / (3) ADD SA: dst=H2 <------(b)----------- I'm assuming that for a conforming IPSEC implementation, BOTH ends of SA1's on H1 and H2 must be IDENTICAL. All parameters must be identical, including the lifetimes. This means that data (a) contains proposals, and data (b) must contain the chosen values, including reduced lifetimes, if H2 so decided. This way, I don't see any problems (excluding box crashes), other than a slight uncertainty period for time based life times due to delays between H1/H2. But, as H1 SA is updated last, even this may be rare (e.g. the H1 starts counting later than H2). For byte based lifetimes, the discrepancy may result from lost data, but in this case the counter on H1 should run faster than H2, and again it would usually expire first. When H1 expires first, the negotiation is simply redone for this single unidirectional SA. If H2 expires first (on what conditions this happens?), packets will be lost for a while, unless something extra is done. > I've heard several people mention that a solution to the "failover" > problem-- where the box crashes, reboots, loses all state A box crash of H1 would just cause normal regotiation of this SA1. A box crash of H2 is more difficult, would need some refinements or guidelines how to cope with the situation. I don't have a solution for this, the ones that come first into mind, may have nasty drawbacks... - if a packet with unknown SPI arrives, send a delete for that SA (DOS attack problems!) - save (KEYSRC, SPI, proto, dst) onto a disk, and on bootup contact each key manager SRC, and send delete SA. Only those SA's need to be stored for which this host is the receiving end point. (Needs a storage that survives crash...) Agenda? Umm.. well just trying to show that if SA's are negotiated independently of bundles, many problems reduce to manageable size and perhaps it is easier to find exact solutions. -- 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@portal.ex.tis.com Thu Feb 4 09:30:11 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA00833; Thu, 4 Feb 1999 09:30:10 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA15077 for ipsec-outgoing; Thu, 4 Feb 1999 09:10:07 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05CF16@md-exchange1.nai.com> From: "Mason, David" To: "'Daniel Harkins'" Cc: "'ipsec@tis.com'" Subject: RE: Question about mis-match SA lifetimes Date: Thu, 4 Feb 1999 06:30:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Dan - it's me again :) Between me being thick skulled and ridiculous remarks about sending keys off to Louis Freeh (who is he anyways?), I'm having a hard time sorting out when your serious and when your just having fun. If you truly believe that the other side might compromise the keys during the remaining seven hours in a 1 hour versus 8 hour mismatch, what's to keep them from compromising the keys during the first hour? And if there's a posssibilty that they might compromise the IKE/IPsec keys, wouldn't it be likely that they might also compromise the secret in a preshared link or their private key in a certificate based link? If you can't trust the other side to protect the keys, and you care about protecting the data transferred, you should not only fail the negotiation under a lifetime mismatch, but fail the negotiation under all circumstances. If you don't care about protecting the data, or if you trust the other side to protect the keys, then I don't see any advantage in failing the negotiation because of a lifetime mis-match. Are there any cryptography experts out there that think a note should go into the security considerations section of RFC 2407 stating that option 2 (complete the negotiation but use a shorter lifetime than what was offered) of section 4.5.4 might possibly represent a security risk? -dave From owner-ipsec@portal.ex.tis.com Thu Feb 4 09:55:42 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA01073; Thu, 4 Feb 1999 09:55:42 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA15261 for ipsec-outgoing; Thu, 4 Feb 1999 10:00:07 -0500 (EST) Message-ID: <36B9BAC3.CD72D498@lucent.com> Date: Thu, 04 Feb 1999 09:20:35 -0600 From: "David W. Faucher" Organization: Lucent Technologies X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: REPLAY-STATUS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk With respect to REPLAY-STATUS messages, RFC2407 section 4.6.3.2 only mentions responder. Is it legal for the initiator of a quick mode exchange to include a REPLAY-STATUS notify message? Specifically, how would an initiator tell the responder that anti-replay detection is disabled? thanks, From owner-ipsec@portal.ex.tis.com Thu Feb 4 10:48:33 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA01633; Thu, 4 Feb 1999 10:48:32 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA15488 for ipsec-outgoing; Thu, 4 Feb 1999 10:44:12 -0500 (EST) Message-Id: <3.0.32.19990204110709.00a05720@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 04 Feb 1999 11:07:10 -0500 To: Paul Koning From: Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Subject: Re: Question about mis-match SA lifetimes Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk >I would have thought the same. In fact, it's not clear to me why the >lifetime value needs to be mentioned in the protocol at all. If I >think the SA has lived long enough, I can rekey. Whether the other >side is more tolerant seems irrelevant. > >To put it differently: consider a hypothetical protocol that was just >like IKE except that it doesn't exchange this information. What bad >properties, if any, would such a protocol have? What if the peer wants to rekey once every second, and use PFS to boot? If you're trying to support hundreds or thousands of SAs, this can get quite expensive in a hurry, and could be considered a denial- of-service attack in some circles. Knowing what the peer's intended lifetime is can help prevent this, assuming that you're looking for it. And one corollary to Dan's comments: If you're assuming a lifetime of eight hours and the peer is assuming one minute, and the peer for whatever reason only wants to negotiate once (assume here a device that comes online, performs a transaction then goes away, and furthermore that its DELETE doesn't make it across), then you're going to keep all the SA information around for eight hours because you don't know any better. Whether or not it's kept on disk, it still occupies memory that might be better used elsewhere (again, you could be trying to do hundreds or thousands of SAs). I'd just as soon keep the lifetimes in the protocol, thanks. -Shawn Mamros E-mail to: smamros@BayNetworks.com From owner-ipsec@portal.ex.tis.com Thu Feb 4 11:30:12 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02218; Thu, 4 Feb 1999 11:30:12 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA16049 for ipsec-outgoing; Thu, 4 Feb 1999 11:49:11 -0500 (EST) Message-Id: <199902031633.LAA23860@relay.hq.tis.com> Date: Wed, 3 Feb 1999 11:23:51 -0500 (EST) From: "Loretta Zhou" Reply-To: "Loretta Zhou" Subject: Question about truncating output length of HMAC computation To: ipsec@tis.com X-Mailer: Rosa 2.0b1 SunOS5.5.1 X-Rosa-Trace: lzhou@bcarsc3c <47.208.140.93> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id LAA11256 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, In section 5 of rfc 2104 (HMAC: Keyed-Hashing for message Authentication), it has the following information: Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation. We recommend that the output length t be not less than half the length of the hash output and not less than 80 bits. We propose denoting a realization of HMAC that uses a hash function H with t bits of output as HMAC-H-t. For example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function and with the output truncated to 80 bits. (If the parameter t is not specified, e.g. HMAC-MD5, then it is assumed that all the bits of the hash are output.) When I was searching for RFCs about HMAC-MD5-t and HMAC-SHA1-t under the ipsec working group of IETF homepage, I only found two relevant RFCs. One is "The Use of HMAC-MD5-96 with ESP and AH" and the other is "The Use of HMAC-SAH-1-96 with ESP and AH". My question is that by default, what do we MUST support for the output length if we implement SHA-1 and MD5? Do we must support truncating output length to 96 bits or outputing all length (no truncating)? Which one is more preferred and widely supported? Loretta. From owner-ipsec@portal.ex.tis.com Thu Feb 4 11:38:40 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02305; Thu, 4 Feb 1999 11:38:40 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA16005 for ipsec-outgoing; Thu, 4 Feb 1999 11:44:12 -0500 (EST) Message-ID: <447A3F40A07FD211BA2700A0C99D759B05CF1C@md-exchange1.nai.com> From: "Mason, David" To: "'Shawn_Mamros@BayNetworks.COM'" , Paul Koning Cc: ipsec@tis.com Subject: RE: Question about mis-match SA lifetimes Date: Thu, 4 Feb 1999 08:59:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk When one side is using a 1 hour lifetime and the other side an eight hour lifetime, there definitely will be problems when the eight hour side trys to use the IKE SA after the first hour. That's why we need a phase 1 RESPONDER-LIFETIME ASAP. But without it the eight hour daemon should still be able to recover and initiate a new Phase 1 that will allow communications to proceed (especially if the 1 hour daemon initiates a new phase 1 so that he can send a secure invalid cookie to the other side). In the meantime the logging of the failure after the first hour will enable the administrators to sort out what's going wrong and fix it so that communications will proceed in a better fashion. I just think it's better to allow some communication to proceed while the lifetime mismatch is sorted out rather than block all communication until it is sorted out. -dave > -----Original Message----- > From: Shawn_Mamros@BayNetworks.COM [SMTP:Shawn_Mamros@BayNetworks.COM] > Sent: Thursday, February 04, 1999 11:07 AM > To: Paul Koning > Cc: ipsec@tis.com > Subject: Re: Question about mis-match SA lifetimes > > >I would have thought the same. In fact, it's not clear to me why the > >lifetime value needs to be mentioned in the protocol at all. If I > >think the SA has lived long enough, I can rekey. Whether the other > >side is more tolerant seems irrelevant. > > > >To put it differently: consider a hypothetical protocol that was just > >like IKE except that it doesn't exchange this information. What bad > >properties, if any, would such a protocol have? > > What if the peer wants to rekey once every second, and use PFS to > boot? If you're trying to support hundreds or thousands of SAs, this > can get quite expensive in a hurry, and could be considered a denial- > of-service attack in some circles. Knowing what the peer's intended > lifetime is can help prevent this, assuming that you're looking for it. > > And one corollary to Dan's comments: If you're assuming a lifetime > of eight hours and the peer is assuming one minute, and the peer > for whatever reason only wants to negotiate once (assume here a > device that comes online, performs a transaction then goes away, > and furthermore that its DELETE doesn't make it across), then > you're going to keep all the SA information around for eight hours > because you don't know any better. Whether or not it's kept on > disk, it still occupies memory that might be better used elsewhere > (again, you could be trying to do hundreds or thousands of SAs). > > I'd just as soon keep the lifetimes in the protocol, thanks. > > -Shawn Mamros > E-mail to: smamros@BayNetworks.com From owner-ipsec@portal.ex.tis.com Thu Feb 4 12:04:12 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA02631; Thu, 4 Feb 1999 12:04:11 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA16095 for ipsec-outgoing; Thu, 4 Feb 1999 11:59:11 -0500 (EST) Date: Thu, 4 Feb 1999 12:15:19 -0500 Message-Id: <199902041715.MAA27259@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Shawn_Mamros@BayNetworks.COM Cc: ipsec@tis.com Subject: Re: Question about mis-match SA lifetimes References: <3.0.32.19990204110709.00a05720@bl-mail1.corpeast.baynetworks.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Shawn" == Shawn Mamros writes: >> I would have thought the same. In fact, it's not clear to me why >> the lifetime value needs to be mentioned in the protocol at all. >> If I think the SA has lived long enough, I can rekey. Whether the >> other side is more tolerant seems irrelevant. >> >> To put it differently: consider a hypothetical protocol that was >> just like IKE except that it doesn't exchange this information. >> What bad properties, if any, would such a protocol have? Shawn> What if the peer wants to rekey once every second, and use PFS Shawn> to boot? If you're trying to support hundreds or thousands of Shawn> SAs, this can get quite expensive in a hurry, and could be Shawn> considered a denial- of-service attack in some circles. Shawn> Knowing what the peer's intended lifetime is can help prevent Shawn> this, assuming that you're looking for it. No it doesn't. If someone wants to mount such a denial of service attack, there is no reason to believe they would advertise their evil intent by announcing a lifetime of 1 second. The scenario you describe is a real issue. But by definition you CANNOT use protocol rules to protect from evildoers -- you must take local action to protect your local resources. Another way of saying the same thing is that your system has to be robust enough that it doesn't malfunction (and in particular, it recovers after the attack stops) no matter what nasty stuff appears on the wire. If you crash because I send you bad packets, "the protocol spec doesn't allow you do to that" isn't a valid defense... paul From owner-ipsec@portal.ex.tis.com Mon Feb 8 05:52:39 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA28301; Mon, 8 Feb 1999 05:52:38 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA06922 for ipsec-outgoing; Mon, 8 Feb 1999 05:36:08 -0500 (EST) Message-Id: <3.0.1.32.19990208163100.006a2c58@172.16.1.10> X-Sender: srinu@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 08 Feb 1999 16:31:00 +0500 To: ipsec@tis.com From: "S. B. Kulkarni" Subject: Questions about Certificates Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I have some doubts regarding handling of certificates is concern. * If we support multiple certificates (issued by different CAs) and we get CERT-REQ payloads of all those CAs, is it necessary to send all the certificates or just one is sufficient ? If one is sufficient,is it ok to send the reply to the first matching CA ? * If the responder to the CERT-REQ payloads sents out two CERT payloads issued by two different CAs and one of the certificate is invalid (certificate is expired ..) whereas the other one is a valid one, do we abort the connection as there is some error in the certificate or can we proceed with the valid certificate ? * If we get a CERT-REQ payload and we dont have a certificate issued by that particular CA, can we abort the connection or can we send some other certificate issued by a different CA ? * If we dont get a CERT-REQ payload at all in the IKE exchange and we support multiple certificates (issued by different CAs), can we send all the certificates issued by those CAs, or it is ok if we send one of the certficate ? If one is ok, how do we select which of the certificate to send ? *If we get a CERT-REQ payload with the certificate type as a CRL and we dont have a CRL on our side, can we abort the connection ? or we have to send the CRL some how (getting CRL from the CA using LDAP) ? Thank U - Srinu From owner-ipsec@portal.ex.tis.com Mon Feb 8 06:58:10 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA29022; Mon, 8 Feb 1999 06:58:09 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA07222 for ipsec-outgoing; Mon, 8 Feb 1999 07:12:07 -0500 (EST) Message-Id: <3.0.5.32.19990208143335.00a6b690@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 08 Feb 1999 14:33:35 +0200 To: ipsec@tis.com From: Joern Sierwald Subject: Re: Questions about Certificates In-Reply-To: <3.0.1.32.19990208163100.006a2c58@172.16.1.10> 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 portal.ex.tis.com id HAA07219 Sender: owner-ipsec@ex.tis.com Precedence: bulk At 16:31 8.2.1999 +0500, you wrote: >Hi, > >I have some doubts regarding handling of certificates is concern. > >* If we support multiple certificates (issued by different CAs) >and we get CERT-REQ payloads of all those CAs, is it necessary >to send all the certificates or just one is sufficient ? If one is >sufficient,is it ok to send the reply to the first matching CA ? > I suppose you're talking about X.509 certificates for authentication here. For SPKI, things have to be handled differently. Just send the first matching certificate. >* If the responder to the CERT-REQ payloads sents out two CERT >payloads issued by two different CAs and one of the certificate is >invalid (certificate is expired ..) whereas the other one is a valid one, >do we abort the connection as there is some error in the certificate >or can we proceed with the valid certificate ? > Proceed, but you should log the error. >* If we get a CERT-REQ payload and we dont have a certificate issued >by that particular CA, can we abort the connection or can we send some >other certificate issued by a different CA ? > If this happens for just one CERT-REQ, never mind. The question is, what do we do if we can't answer any of the requests at all? I'd send my default certificate. Maybe it'll work. Maybe the other side trusts all certificates. >* If we dont get a CERT-REQ payload at all in the IKE exchange and we >support multiple certificates (issued by different CAs), can we send all >the certificates issued by those CAs, or it is ok if we send one of the >certficate ? If one is ok, how do we select which of the certificate to send ? > You may send as many certificates as you want. And you can implement this in any way you want. Or avoid the decision: let the end user decide. >*If we get a CERT-REQ payload with the certificate type as a CRL and we >dont have a CRL on our side, can we abort the connection ? or we have >to send the CRL some how (getting CRL from the CA using LDAP) ? > Just ignore the CERT-REQ. >Thank U >- Srinu > Jörn Sierwald From owner-ipsec@portal.ex.tis.com Tue Feb 9 09:57:09 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA09153; Tue, 9 Feb 1999 09:57:09 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA13770 for ipsec-outgoing; Tue, 9 Feb 1999 08:38:08 -0500 (EST) Date: Tue, 9 Feb 1999 12:05:09 +0200 (EET) From: Oktay Adalier To: ipsec@tis.com Subject: public key transfer problem. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Can any one answer my quastion? The problem is: In the RFC-2409 (the IKE RFC) in section 5.2 (phasa 1 Authenticated with Public Key Encryption) it is said that " in order to perform the public key encryption, the initiator must already have the responder's public key." My quastion is : How one can have the responder's (or vise versa; initiators) public key. How can the peers send and recevie the public key values of RSA if there is no main mode, aggressive mode or quick mode of ISAKMP. In what format would be the RSA public keys transformed? Oktay ADALIER **************************************** * TUBITAK - UEKAE * * P.K: 21 41470 * * Gebze / KOCAELI * * TURKEY * * * * * * Daily phone : 90-262-6481351 * * mail : oadalier@mam.gov.tr * * oadalier@bornova.ege.edu.tr * **************************************** From owner-ipsec@portal.ex.tis.com Tue Feb 9 09:59:16 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA09185; Tue, 9 Feb 1999 09:59:16 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA13597 for ipsec-outgoing; Tue, 9 Feb 1999 08:31:08 -0500 (EST) Message-ID: <36BF7B1D.709D37CE@mail1.sjtu.edu.cn> Date: Tue, 09 Feb 1999 08:02:37 +0800 From: Wang Huaibo X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com Subject: HELP Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I am a student from China, and am interested in IPsec, I have a question about IKE, followed fragment is cut off from RFC1409: KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b) where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman exchange of this Quick Mode. I wonder how to determine the bits of item g(qm)^xy,as to MODP, the leading(high order or most significant bits) zero should be trimmed off? as to ECP or EC2N, the item is a point ,say,(X,Y), then the Y should be compressed, and the leading zero should be trimmed off? THANKS & REGARDS Wang Huaibo 6/2 From owner-ipsec@portal.ex.tis.com Tue Feb 9 11:45:52 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA10143; Tue, 9 Feb 1999 11:45:52 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA15592 for ipsec-outgoing; Tue, 9 Feb 1999 11:10:13 -0500 (EST) Message-Id: <3.0.32.19990209081912.009e1a2c@intotoinc.com> X-Sender: sathyan@intotoinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 09 Feb 1999 08:19:18 -0800 To: Anita Freeman , ipsec@tis.com, ietf-ppp@merit.edu From: Sathyan Iyengar Subject: Re: April IPSec and PPP Interoperability Workshop Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello, Is it confirmed that there is going to be IPSEC Interoperability Workshop in the week of April? Any more information on this will be helpful. Thanks, -Sathyan At 04:20 PM 4/28/99 -0700, Anita Freeman wrote: >Greetings, > >We are preparing to sign a hotel contract for the next IPSec and PPP Interoperability Workshop for the week of April 19-23, 1999, in Santa Barbara, CA, with arrival and set up on April 18. > >It has been brought to our attention there is an Internet Security Conference taking place April 19-22, 1999, in San Jose, CA. The details are listed below. > >This email is sent for the participants of the interoperability workshop. Will this conference present a conflict in your company's resources to attend the IPSec and PPP interoperability workshop? > >Please respond at your earliest opportunity as this is the only week in April the hotel accommodations are available in Santa Barbara and we would like to complete our contract negotiations promptly if this is a viable week for the workshop. > >Thank you, Anita Freeman > >------------------------------------ /******************************************************************* INTOTO - Formerly, products division of Technology Rendezvous Inc. Intoto Inc. Ph : 408-844-0480 Ext:302 3160, De La Cruz Blvd. Fax : 408-844-0488 Suite #100, Santa Clara e-mail: sathyan@intotoinc.com CA - 95054, USA Web : www.intotoinc.com ********************************************************************/ From owner-ipsec@portal.ex.tis.com Tue Feb 9 12:29:22 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11251; Tue, 9 Feb 1999 12:29:21 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA20054 for ipsec-outgoing; Tue, 9 Feb 1999 12:48:14 -0500 (EST) Date: Tue, 9 Feb 1999 19:55:59 +0200 (EET) From: Oktay Adalier To: ipsec@tis.com Subject: exchange values Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, could any one tell me what the exchange type values for QUICK mode and NEW GROUP mode in IKE aare? oktay.. From owner-ipsec@portal.ex.tis.com Tue Feb 9 12:37:22 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA11317; Tue, 9 Feb 1999 12:37:22 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA19949 for ipsec-outgoing; Tue, 9 Feb 1999 12:47:16 -0500 (EST) From: "Evan Caves" To: "Sathyan Iyengar" , "Anita Freeman" , , Subject: RE: April IPSec and PPP Interoperability Workshop Date: Tue, 9 Feb 1999 09:48:20 -0800 Message-Id: <001801be5454$61d88b40$6317c081@evan.acc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3.0.32.19990209081912.009e1a2c@intotoinc.com> X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@ex.tis.com Precedence: bulk Actually because of the Security Conference conflict in San Jose for that same week we are in the process of rescheduling it for May 24-28 (still in Santa Barbara). We will be following up with more information shortly. evan - > -----Original Message----- > From: owner-ietf-ppp@merit.edu [mailto:owner-ietf-ppp@merit.edu]On > Behalf Of Sathyan Iyengar > Sent: Tuesday, February 09, 1999 8:19 AM > To: Anita Freeman; ipsec@tis.com; ietf-ppp@merit.edu > Subject: Re: April IPSec and PPP Interoperability Workshop > > > Hello, > > Is it confirmed that there is going to be IPSEC Interoperability > Workshop in the week of April? > > Any more information on this will be helpful. > > Thanks, > -Sathyan > > At 04:20 PM 4/28/99 -0700, Anita Freeman wrote: > >Greetings, > > > >We are preparing to sign a hotel contract for the next IPSec and PPP > Interoperability Workshop for the week of April 19-23, 1999, in Santa > Barbara, CA, with arrival and set up on April 18. > > > >It has been brought to our attention there is an Internet Security > Conference taking place April 19-22, 1999, in San Jose, CA. The details > are listed below. > > > >This email is sent for the participants of the interoperability workshop. > Will this conference present a conflict in your company's resources to > attend the IPSec and PPP interoperability workshop? > > > >Please respond at your earliest opportunity as this is the only week in > April the hotel accommodations are available in Santa Barbara and we would > like to complete our contract negotiations promptly if this is a viable > week for the workshop. > > > >Thank you, Anita Freeman > > > >------------------------------------ > > > /******************************************************************* > INTOTO - Formerly, products division of Technology Rendezvous Inc. > > Intoto Inc. Ph : 408-844-0480 Ext:302 > 3160, De La Cruz Blvd. Fax : 408-844-0488 > Suite #100, Santa Clara e-mail: sathyan@intotoinc.com > CA - 95054, USA Web : www.intotoinc.com > ********************************************************************/ > From owner-ipsec@portal.ex.tis.com Tue Feb 9 14:12:42 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12912; Tue, 9 Feb 1999 14:12:42 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA22736 for ipsec-outgoing; Tue, 9 Feb 1999 14:16:18 -0500 (EST) Message-ID: From: Bryan Gleeson To: ipsec@tis.com Subject: ipsec sub-groups Date: Tue, 9 Feb 1999 11:34:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Can someone post the mailing list addresses of the active IPSEC sub-groups? There was some discussion on this issue in Orlando, but unfortunately no meeting report for the last meeting seems to have been submitted, so it isn't clear what the status is. Other than a posting to indicate that the ipsec-errors list has shutdown, I haven't seen any notifications about these sub-groups on the main list. Thanks, Bryan Gleeson Shasta Networks. From owner-ipsec@portal.ex.tis.com Tue Feb 9 14:41:22 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA13208; Tue, 9 Feb 1999 14:41:22 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA22925 for ipsec-outgoing; Tue, 9 Feb 1999 14:56:17 -0500 (EST) Message-Id: <199902092017.PAA11229@istari.sandelman.ottawa.on.ca> To: Bryan Gleeson CC: ipsec@tis.com Subject: Re: ipsec sub-groups In-Reply-To: Your message of "Tue, 09 Feb 1999 11:34:32 PST." Date: Tue, 09 Feb 1999 15:17:09 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk AFAIK, There are no active IPsec sub-groups at this time. A number of IPsec related WGs will have BOFs in Mineapolis, but no mailing lists have been made yet. The Ipsec-errors sub-group was closed at Orlando. The archives are at: http://weww.sandelman.ottawa.on.ca/ipsec-errors/ :!mcr!: | Network and security consulting/contract programming Michael Richardson | IPsec, VPN, Firewalls, PKI, network design, Unix admin Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. From owner-ipsec@portal.ex.tis.com Tue Feb 9 16:56:29 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA14475; Tue, 9 Feb 1999 16:56:29 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA23381 for ipsec-outgoing; Tue, 9 Feb 1999 16:46:20 -0500 (EST) Message-ID: <91AE69321799D211AEC500105A9C469605D8C4@sothmxs05.entrust.com> From: Greg Carter To: ipsec@tis.com, "'Oktay Adalier'" Subject: RE: public key transfer problem. Date: Tue, 9 Feb 1999 17:01:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, By some out of band means, which means not within IKE. So that could be floppy, ftp or through LDAP. ---- Greg Carter, Entrust Technologies greg.carter@entrust.com > ---------- > From: Oktay Adalier[SMTP:oadalier@yunus.mam.gov.tr] > Sent: Tuesday, February 09, 1999 5:05 AM > To: ipsec@tis.com > Subject: public key transfer problem. > > The problem is: > In the RFC-2409 (the IKE RFC) in section 5.2 (phasa 1 Authenticated with > Public Key Encryption) it is said that " in order to perform the public > key encryption, the initiator must already have the responder's public > key." > > My quastion is : How one can have the responder's (or vise versa; > initiators) public key. > > From owner-ipsec@portal.ex.tis.com Tue Feb 9 20:05:47 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA22843; Tue, 9 Feb 1999 20:05:47 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA23864 for ipsec-outgoing; Tue, 9 Feb 1999 18:31:33 -0500 (EST) From: Charles.Lo@Notes.airtouch.com X-Lotus-FromDomain: AIRTOUCH To: ipsec@tis.com Message-ID: <88256713.008334DF.00@Notes.airtouch.com> Date: Tue, 9 Feb 1999 15:54:36 -0800 Subject: Internet security conference Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi - can anyone provide more info on this upcoming Internet security conference in San Jose 4/19-23? Thanks, Charles Lo AirTouch Communications ------------------------ At 04:20 PM 4/28/99 -0700, Anita Freeman wrote: >Greetings, > >We are preparing to sign a hotel contract for the next IPSec and PPP Interoperability Workshop for the week of April 19-23, 1999, in Santa Barbara, CA, with arrival and set up on April 18. > >It has been brought to our attention there is an Internet Security Conference taking place April 19-22, 1999, in San Jose, CA. The details are listed below. > >This email is sent for the participants of the interoperability workshop. Will this conference present a conflict in your company's resources to attend the IPSec and PPP interoperability workshop? > >Please respond at your earliest opportunity as this is the only week in April the hotel accommodations are available in Santa Barbara and we would like to complete our contract negotiations promptly if this is a viable week for the workshop. > >Thank you, Anita Freeman > >------------------------------------ From owner-ipsec@portal.ex.tis.com Wed Feb 10 08:58:53 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA21378; Wed, 10 Feb 1999 08:58:52 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA26537 for ipsec-outgoing; Wed, 10 Feb 1999 08:35:21 -0500 (EST) Message-Id: <199902101355.IAA21201@post1.fast.net> X-Sender: lphifer@pop.fast.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 10 Feb 1999 08:57:40 -0500 To: Charles.Lo@Notes.airtouch.com From: Lisa Phifer Subject: Re: Internet security conference Cc: ipsec@tis.com In-Reply-To: <88256713.008334DF.00@Notes.airtouch.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 03:54 PM 2/9/99 -0800, you wrote: >Hi - can anyone provide more info on this upcoming Internet security >conference in San Jose 4/19-23? ------------------------------------------------------ The Internet Security Conference Making the Internet a Safer Place for Electronic Information Assets April 19-23, 1999 * Fairmont Hotel * San Jose CA The 2nd presentation of The Internet Security Conference (TISC, http://tisc.corecom.com) will address the most pressing security issues confronting Internet-enabled organizations today. The most respected experts in nearly every field of security will gather in the Fairmont Hotel, San Jose to present a technical conference and exhibition, April 19-23, 1999. The TISC faculty of over 50 experts, including: * Fred Avolio, security, former product manager for TIS Gauntlet Internet Firewall * Dr. William Hancock, Chief Technology Officer, Network-1 * Charlie Kaufman, Security Architect for Lotus Notes, IBM * Dr. Stephen Kent, Chief Scientist, Information Security, BBN Technologies * Rik Farrow, Internet and UNIX Security consultant and author * Bob Moskowitz, Sr. technical director at the ICSA * Dr. Radia Perlman, Distinguished Engineer, Sun Microsystems * Marcus Ranum, firewall expert, CEO & Founder, Network Flight Recorder, * Dr. Ron Ross, Sr. computer scientist at the Information Technology Laboratory, NIST will join Network Computing Magazine's Technology Editors Dan Backman, Mike Fratto and Dave Willis in presenting workshops, seminars, and a two-day, 30 session Security Symposium. An Interoperability Lab and Vendor Exhibit will complement the education offered at TISC. The Interoperability Lab (http://tisc.corecom.com/lab99.html) will provide attendees an opportunity to witness individual product demonstrations, conducted by vendor *technical* staff. Attendees will see and participate in multi-vendor demonstrations of: * Network Attack, Penetration, and Intrusion Detection * IPSec/IKE and CA Interoperability * IPSec Configuration and Benchmarking * Policy-Based Security Management * Layered VPNs for Remote Access and Extranet Connectivity * Desktop and Internet Application Security * Authentication as an Enabler for Secure E-Commerce coordinated by Aventail, Core Competence, Ernst & Young and Network Computing Magazine. Entrance to the TISC Interoperability Lab is free to all TISC '99 attendees. TISC workshop students will receive a guided walking tour of security technologies on display in the lab A complete program guide is available at http://tisc.corecom.com/programguide.pdf Registration is now open, visit https://secure.mactivity.com/tisc/register.html or call 1-800-798-2928. Space is Limited. The Internet Security Conference is presented by Core Competence, the respected internetworking, fast packet and network management consulting firm founded by Dave Piscitello, and Network Computing, the premier technology solutions magazine. Conference Sponsors include * Compatible Systems * Checkpoint Software Technologies * Ernst & Young * Microsoft * Aventail * RadGuard * Internet Devices * NetScreen * 3Com * enCommerce * RedCreek * RSA Data Security * TimeStep * Xedia * Network Flight Recorder * Covad Communications * Axent Technologies * Kroll-O'Gara ISG* Exodus * Xcert * Network-1 * Internet Week (Visit http://tisc.corecom.com/sponsors.html for new additions to this list.) From owner-ipsec@portal.ex.tis.com Wed Feb 10 09:00:29 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA21418; Wed, 10 Feb 1999 09:00:11 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA26503 for ipsec-outgoing; Wed, 10 Feb 1999 08:21:21 -0500 (EST) Message-ID: <36C18C79.13781683@Certicom.com> Date: Wed, 10 Feb 1999 08:41:13 -0500 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.01 [en] (WinNT; U) MIME-Version: 1.0 To: Wang Huaibo CC: ipsec@tis.com Subject: Re: HELP X-Priority: 3 (Normal) References: <36BF7B1D.709D37CE@mail1.sjtu.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, The shared secret g^xy should be in the form of octet string: MS byte value --> LS byte value [0] [1] [2] ... leading byte In the byte [0] there might be junk bits that must be 0. In case of EC groups, RFC2409 says that you have to use only X-coordinate. Data marshalling must be the same as in case of MODP, since the difference is not mentioned. Unfortunately, RFC2409 does not explain the data format, which should be present. Otherwise, people will be confused about the data format (for the components in the hash function, for instance) and have problems in interoperability of different IKE implementaions. You can take a look at http://grouper.ieee.org/groups/1363/draft.html to learn about data marshalling in other standards. Regards, Yuri Wang Huaibo wrote: > Hi, > I am a student from China, and am interested in IPsec, > I have a question about IKE, followed fragment is cut off > from RFC1409: > > KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | > Nr_b) > where g(qm)^xy is the shared secret from the ephemeral > Diffie-Hellman exchange of this Quick Mode. > > I wonder how to determine the bits of item g(qm)^xy,as to MODP, > the leading(high order or most significant bits) zero should be > trimmed off? as to ECP or EC2N, the item is a point ,say,(X,Y), then > the Y should be compressed, and the leading zero should be trimmed > off? > > THANKS & REGARDS > > Wang Huaibo > > 6/2 From owner-ipsec@portal.ex.tis.com Wed Feb 10 13:35:20 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26119; Wed, 10 Feb 1999 13:35:20 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA28229 for ipsec-outgoing; Wed, 10 Feb 1999 13:44:27 -0500 (EST) Message-Id: <4.2.0.24.19990210110204.00be2cc0@mail.imc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.24 (Beta) Date: Wed, 10 Feb 1999 11:05:18 -0800 To: ipsec@tis.com From: Paul Hoffman Subject: IPsec standards pages Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@ex.tis.com Precedence: bulk Greetings again. In our effort to make the IPsec standards and proposals more comprehensible, VPNC has set up a few pages listing the RFCs and I-Ds. The I-Ds page is automatically updated each day for new versions of current drafts. Please see for more information. (BTW, I'm glad that so many people like the threaded archive of the IPsec mailing list that I announced a little while ago. Let me know if there is anything else that VPNC can add to these pages to make them more useful.) --Paul Hoffman, Director --VPN Consortium From owner-ipsec@portal.ex.tis.com Wed Feb 10 14:51:18 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29291; Wed, 10 Feb 1999 14:51:18 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA28657 for ipsec-outgoing; Wed, 10 Feb 1999 15:11:27 -0500 (EST) Message-ID: From: "Eren, Evren" To: ipsec@tis.com Subject: layer 2 and layer 3 tunneling Date: Wed, 10 Feb 1999 21:32:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk I know, that I am in the wrong area, but I would be grateful if anybody can recommend good references for layer 2 and layer 3 tunneling ? My understanding is the following: PPTP and L2F are Layer 3 tunneling protocols. They directly encapsulate IPX, IP etc. L2TP is a Layer 2 tunneling protocol. It encapsulates PPP, which can encapsulate IPX, IP etc. Thank you. Evren Please also see figure attached. <<...>> From owner-ipsec@portal.ex.tis.com Wed Feb 10 15:46:39 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02274; Wed, 10 Feb 1999 15:46:39 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA28924 for ipsec-outgoing; Wed, 10 Feb 1999 16:03:27 -0500 (EST) Message-Id: <3.0.1.32.19990210161221.00a652c0@bl-mail1.corpeast.baynetworks.com> X-Sender: rshea@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 10 Feb 1999 16:12:21 -0500 To: "Eren, Evren" , ipsec@tis.com From: Rich_Shea@BayNetworks.COM (Rich Shea) Subject: Re: layer 2 and layer 3 tunneling In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 09:32 PM 2/10/99 +0100, Eren, Evren wrote: >I know, that I am in the wrong area, but I would be grateful if anybody can >recommend good references >for layer 2 and layer 3 tunneling ? > >My understanding is the following: > >PPTP and L2F are Layer 3 tunneling protocols. They directly encapsulate IPX, >IP etc. > >L2TP is a Layer 2 tunneling protocol. It encapsulates PPP, which can >encapsulate IPX, IP etc. > PPTP, L2F, and L2TP all encapsulate PPP and so are all layer 2 tunneling. L2F is an informational draft (don't have the number off hand). PPTP was last at draft-ietf-pppext-pptp-04.txt and L2TP is at draft-ietf-pppext-l2tp-12.txt. The PPPEXT WG mailing list (or L2TP mailing list) is the right area for questions about these. The IETF web page has information on the mailing list for PPPEXT and L2TP mailing lists (I haven't looked if the web page has been updated, but the l2tp list recently changed from l2tp@zendo.com to l2tp@ietf.org). Richard. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea, Principal Engineer rshea@BayNetworks.com Nortel Networks / Extranet Access 978-635-2019 From owner-ipsec@portal.ex.tis.com Wed Feb 10 15:46:54 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA02288; Wed, 10 Feb 1999 15:46:53 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA28998 for ipsec-outgoing; Wed, 10 Feb 1999 16:12:28 -0500 (EST) Date: Wed, 10 Feb 1999 16:32:09 -0500 (EST) From: Henry Spencer To: Oktay Adalier cc: ipsec@tis.com Subject: Re: public key transfer problem. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > In the RFC-2409 (the IKE RFC) in section 5.2 (phasa 1 Authenticated with > Public Key Encryption) it is said that " in order to perform the public > key encryption, the initiator must already have the responder's public > key." > > My quastion is : How one can have the responder's (or vise versa; > initiators) public key. Perhaps by prearrangement, e.g. transferring it by FTP. Perhaps by getting it from a KEY record in a DNS entry (see RFC 2065). Perhaps by talking to a key server of some other kind. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@portal.ex.tis.com Wed Feb 10 16:37:22 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA05268; Wed, 10 Feb 1999 16:37:21 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA29118 for ipsec-outgoing; Wed, 10 Feb 1999 16:56:27 -0500 (EST) Message-ID: <19990210220022.26863.rocketmail@send205.yahoomail.com> Date: Wed, 10 Feb 1999 14:00:22 -0800 (PST) From: CNJ CNJ Subject: Tools for attacks To: ipsec@tis.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by clipper.hq.tis.com id RAA24324 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id QAA29100 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello Everyone, I am looking for tools to assure that my application for IPSec is working correctly (NT only) and that no one can “hack” their way in. Perhaps some of you can direct me toward tools that will simulate IP attacks. Debbie _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ipsec@portal.ex.tis.com Wed Feb 10 18:34:02 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA19367; Wed, 10 Feb 1999 18:34:02 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA29487 for ipsec-outgoing; Wed, 10 Feb 1999 18:45:29 -0500 (EST) To: Rich_Shea@BayNetworks.COM Cc: Evren_Eren@BONN.DETECON.DE, ipsec@tis.com Subject: Re: layer 2 and layer 3 tunneling From: Motonori Shindo In-Reply-To: <3.0.1.32.19990210161221.00a652c0@bl-mail1.corpeast.baynetworks.com> References: <3.0.1.32.19990210161221.00a652c0@bl-mail1.corpeast.baynetworks.com> X-Mailer: Mew version 1.94b2 on XEmacs 20.4 (Emerald) X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990211090614X.mshindo@ascend.co.jp> Date: Thu, 11 Feb 1999 09:06:14 +0900 X-Dispatcher: imput version 981124(IM104) Lines: 52 Sender: owner-ipsec@ex.tis.com Precedence: bulk Rich, From: Rich_Shea@BayNetworks.COM (Rich Shea) Subject: Re: layer 2 and layer 3 tunneling Date: Wed, 10 Feb 1999 16:12:21 -0500 > At 09:32 PM 2/10/99 +0100, Eren, Evren wrote: > >I know, that I am in the wrong area, but I would be grateful if anybody can > >recommend good references > >for layer 2 and layer 3 tunneling ? > > > >My understanding is the following: > > > >PPTP and L2F are Layer 3 tunneling protocols. They directly encapsulate IPX, > >IP etc. > > > >L2TP is a Layer 2 tunneling protocol. It encapsulates PPP, which can > >encapsulate IPX, IP etc. > > > > PPTP, L2F, and L2TP all encapsulate PPP and so are all layer 2 tunneling. > > L2F is an informational draft (don't have the number off hand). L2F is now RFC2341 (categorized as 'historic'). > PPTP was last at draft-ietf-pppext-pptp-04.txt It's now draft-ietf-pppext-pptp-07.txt. > and L2TP is at draft-ietf-pppext-l2tp-12.txt. > The PPPEXT WG mailing list (or L2TP mailing list) is the right area for > questions about these. The IETF web page has information on the mailing > list for PPPEXT and L2TP mailing lists (I haven't looked if the web page > has been updated, but the l2tp list recently changed from l2tp@zendo.com to > l2tp@ietf.org). > > Richard. > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Richard Shea, Principal Engineer rshea@BayNetworks.com > Nortel Networks / Extranet Access 978-635-2019 ===================================== Motonori Shindo Systems Engineer Ascend Communications Japan K.K. email: mshindo@ascend.co.jp TEL: +81-3-5325-7306 ===================================== From owner-ipsec@portal.ex.tis.com Wed Feb 10 18:36:15 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA19385; Wed, 10 Feb 1999 18:36:14 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA29439 for ipsec-outgoing; Wed, 10 Feb 1999 18:41:31 -0500 (EST) To: Evren_Eren@BONN.DETECON.DE Cc: ipsec@tis.com Subject: Re: layer 2 and layer 3 tunneling From: Motonori Shindo In-Reply-To: References: X-Mailer: Mew version 1.94b2 on XEmacs 20.4 (Emerald) X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990211085958Y.mshindo@ascend.co.jp> Date: Thu, 11 Feb 1999 08:59:58 +0900 X-Dispatcher: imput version 981124(IM104) Lines: 37 Sender: owner-ipsec@ex.tis.com Precedence: bulk Evren, From: "Eren, Evren" Subject: layer 2 and layer 3 tunneling Date: Wed, 10 Feb 1999 21:32:18 +0100 > I know, that I am in the wrong area, but I would be grateful if anybody can > recommend good references > for layer 2 and layer 3 tunneling ? > > My understanding is the following: > > PPTP and L2F are Layer 3 tunneling protocols. They directly encapsulate IPX, > IP etc. > > L2TP is a Layer 2 tunneling protocol. It encapsulates PPP, which can > encapsulate IPX, IP etc. No. PPTP, L2F, and L2TP are all Layer 2 tunneling protocol. IPsec tunnel mode is Layer 3. > Thank you. > > Evren > > Please also see figure attached. > > <<...>> > ===================================== Motonori Shindo Systems Engineer Ascend Communications Japan K.K. email: mshindo@ascend.co.jp TEL: +81-3-5325-7306 ===================================== From owner-ipsec@portal.ex.tis.com Wed Feb 10 19:58:45 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA03203; Wed, 10 Feb 1999 19:58:45 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA29782 for ipsec-outgoing; Wed, 10 Feb 1999 20:20:32 -0500 (EST) Message-Id: <199902110140.UAA22010@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: New IPSec Monitoring MIB draft In-Reply-To: Your message of "Mon, 01 Feb 1999 15:39:55 +0200." <199902011339.PAA28324@torni.ssh.fi> Date: Wed, 10 Feb 1999 20:40:56 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: Tero> Mostly, because that information can be quite large, and getting it Tero> can be quite hard. Also the management statition etc can do the Tero> same path validation procedures than the ike did if it wants. But, maybe the question is, why isn't the ike getting the path right? Tero> One thing we might want to add is to add table of trusted Tero> CA-certificates in the MIB, so the management station etc can do Tero> that path finding itself. Yes, agreed. Tero> I just don't see currently any reason to include all of the Tero> certificates used in the authentication, and including them doesn't How about just the DN of the certs used? Actually, I've realized that most of what I want in the MIB is information on why an SA *failed* to get setup... Will that fit? :!mcr!: | Network and security consulting/contract programming Michael Richardson | IPsec, VPN, Firewalls, PKI, network design, Unix admin Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html Corporate: http://www.sandelman.ottawa.on.ca/SSW/ ON HUMILITY: To err is human, to moo bovine. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQDVAwUBNsI1AnMJp3VWzPepAQE4oQX/UkDH8z8SNHOS0sLzYF8KY78TuIYbJ5u5 BmAgAnD+Ba9M2eppnD1TooBxEGDuhxLu4BECki8qNHXcPrqok0v+uxdUuZYY3ITS rElz1lBsU/26gQuXTfyF3Crld72qPn/ZvD45OByffdtV7K6WhiQB6W/UDHNTMIZr jvcnklwiyLiY0mtSlX3s2pCyHSMS2MiFbc0WPF8V1BCfxECNxn07a/dcPCUbmh+8 LarucUHBTwSC88C/mvS0wD8qesmdmCGm =Xu6z -----END PGP SIGNATURE----- From owner-ipsec@portal.ex.tis.com Thu Feb 11 02:20:27 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA28074; Thu, 11 Feb 1999 02:20:26 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id CAA00968 for ipsec-outgoing; Thu, 11 Feb 1999 02:14:28 -0500 (EST) Date: Thu, 11 Feb 1999 09:34:58 +0200 (EET) From: Devrim Unal To: CNJ CNJ cc: ipsec@tis.com Subject: Re: Tools for attacks In-Reply-To: <19990210220022.26863.rocketmail@send205.yahoomail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by portal.ex.tis.com id CAA00965 Sender: owner-ipsec@ex.tis.com Precedence: bulk On Wed, 10 Feb 1999, CNJ CNJ wrote: > > Hello Everyone, > > I am looking for tools to assure that my application for IPSec is > working correctly (NT only) and that no one can “hack” their way in. > Perhaps some of you can direct me toward tools that will simulate IP > attacks. > > Debbie > > > > > _________________________________________________________ > DO YOU YAHOO!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > Hi Debbie, You can start by downloading the evaluation version of ISS Internet Scanner. This scanner tries many attacks on host computers and reports their problems. The web site is www.iss.net. Unal From owner-ipsec@portal.ex.tis.com Thu Feb 11 05:30:18 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA02283; Thu, 11 Feb 1999 05:30:18 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA01727 for ipsec-outgoing; Thu, 11 Feb 1999 05:28:26 -0500 (EST) Message-Id: <199902111101.LAA19685@ns0.zergo.com> From: Chris Trobridge To: IPSEC List Subject: Cookie Requirements Date: Thu, 11 Feb 1999 10:48:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Am I missing something or are the requirements for cookie generation more than necessary. RFC2408 Para 2.5.3 states that cookie generation must ensure that cookies depend on specific parties, that only cookies should not be acceptable by other than the issuer. It then goes on to outline a method based on hashing IP addresses, UDP ports, a local secret and time/day to produce the cookie. I don't see what advantage this has over choosing a suitably strong random value. I don't understand the argument in the first requirement. If cookies are associated with a particular negotiation/SA then they are also bound with a particular peer IP address/port - Requests using a 'current' cookie from random ip addresses/UDP ports should be rejected on that ground? I'm not sure about the second argument either. I can see that it must not be possible for an attacker to be able to guess the cookie generated in response to a spoofed negotiation request (as with TCP). I'm not sure why this requires a local secret for verification. The only reason I can think of is if cookies aren't stored locally (initially?) and hence there would have to be some means of verifying them. Even then I'm not sure how it would help as you'd still need to know the time/date when the cookie was created. (The third requirement for the generation to be fast I have no problems with!) The difficulties I've had may result from my thoughts about how I'd implement the protocol. Thanks Chris From owner-ipsec@portal.ex.tis.com Thu Feb 11 07:38:11 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA03405; Thu, 11 Feb 1999 07:38:11 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA02076 for ipsec-outgoing; Thu, 11 Feb 1999 07:29:27 -0500 (EST) Message-Id: <199902111249.HAA22611@newman.gte.com> X-Sender: sjj0@pophost.gte.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 11 Feb 1999 07:47:54 -0500 To: Henry Spencer From: Stuart Jacobs Subject: Re: public key transfer problem. Cc: ipsec@tis.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Regardless of how you obtain a subject's public key, how do you know that the public key you are about to use actually belongs to the intended recipient? I suggest that the only way any public key can be used is by first having validated the key via a trusted third party in a formal web of trust (Certificate Authority and PKI) or by direct communication with the key owner for an informal web of trust (ala PGP). Stu At 2/10/99 04:32 PM, you wrote: >> In the RFC-2409 (the IKE RFC) in section 5.2 (phasa 1 Authenticated with >> Public Key Encryption) it is said that " in order to perform the public >> key encryption, the initiator must already have the responder's public >> key." >> >> My quastion is : How one can have the responder's (or vise versa; >> initiators) public key. > >Perhaps by prearrangement, e.g. transferring it by FTP. Perhaps by >getting it from a KEY record in a DNS entry (see RFC 2065). Perhaps by >talking to a key server of some other kind. > > Henry Spencer > henry@spsystems.net > (henry@zoo.toronto.edu) > ========================== Stuart Jacobs CISSP Network Security GTE Laboratories 40 Sylvan Road Waltham, MA 02454 USA telephone: (781) 466-3076 fax: (781) 466-2838 ========================== From owner-ipsec@portal.ex.tis.com Thu Feb 11 07:58:58 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA03566; Thu, 11 Feb 1999 07:58:58 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA02120 for ipsec-outgoing; Thu, 11 Feb 1999 07:56:26 -0500 (EST) Date: Thu, 11 Feb 1999 08:17:04 -0500 (EST) From: Henry Spencer To: Stuart Jacobs cc: ipsec@tis.com Subject: Re: public key transfer problem. In-Reply-To: <199902111249.HAA22611@newman.gte.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 11 Feb 1999, Stuart Jacobs wrote: > Regardless of how you obtain a subject's public key, how do you know that > the public key you are about to use actually belongs to the intended > recipient? I suggest that the only way any public key can be used is by > first having validated the key via a trusted third party in a formal web of > trust (Certificate Authority and PKI) or by direct communication with the > key owner for an informal web of trust (ala PGP). Or by using Secure DNS -- again, see RFC 2065. Agreed that this is an issue, but in general there's a solution for each possible access route. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@portal.ex.tis.com Thu Feb 11 12:53:49 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA06341; Thu, 11 Feb 1999 12:53:48 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA03772 for ipsec-outgoing; Thu, 11 Feb 1999 12:58:30 -0500 (EST) Message-ID: <5F6AA2CAD4A4D1119C3D00A0C99D6AC6B83D22@ca-exchange2.nai.com> From: "Glawitsch, Gregor" To: "'ipsec@tis.com'" Subject: RE: Tools for attacks Date: Thu, 11 Feb 1999 10:21:41 -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@ex.tis.com Precedence: bulk Debbie, Unal, according to InfoWorld, a better tool is "CyberCop Scanner" from Network Associates. Quote: The answer Both scanners are easy to use and check for hundreds of security risks, but CyberCop offers a tad more functionality for a lot less money than Internet Scanner. Both tools will help you keep your enterprise bug-free, but CyberCop, with its open licensing and frequent vulnerability updates, is our winner. Read the whole review at: http://www.infoworld.com/cgi-bin/displayTC.pl?/990208comp.htm Download CyberCop Scanner from http://www.nai.com/download/downloads/ Regards, Greg > -----Original Message----- > From: Devrim Unal [SMTP:devrimu@yunus.mam.gov.tr] > Sent: Wednesday, February 10, 1999 11:35 PM > To: CNJ CNJ > Cc: ipsec@tis.com > Subject: Re: Tools for attacks > > > > On Wed, 10 Feb 1999, CNJ CNJ wrote: > > > > > Hello Everyone, > > > > I am looking for tools to assure that my application for IPSec is > > working correctly (NT only) and that no one can "hack" their way in. > > Perhaps some of you can direct me toward tools that will simulate IP > > attacks. > > > > Debbie > > > > > > > > > > _________________________________________________________ > > DO YOU YAHOO!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > Hi Debbie, > > You can start by downloading the evaluation version of ISS > Internet Scanner. This scanner tries many attacks on host computers > and reports > their problems. The web site is www.iss.net. > > Unal From owner-ipsec@portal.ex.tis.com Thu Feb 11 15:44:17 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08458; Thu, 11 Feb 1999 15:44:16 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA04519 for ipsec-outgoing; Thu, 11 Feb 1999 15:20:34 -0500 (EST) Message-ID: From: Ricky Charlet To: "'ipsec@tis.com'" Subject: RE: New IPSec Monitoring MIB draft Date: Thu, 11 Feb 1999 12:41:30 -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@ex.tis.com Precedence: bulk Ricky Said > > > > Did/could we consider an approach where we have a table of > > ESP SAs, a table > > of AH SAs, a table of Comp SAs and then a table of ProtSuite > > bundles which > > refers to appropriate values (or formulas of values) from > > those first three? Tim Said > > I did look at this. However, ISAKMP explicitly states that > protection suites > are to be treated as a single unit. The multi-table approach > was much more > complicated, and did not add what I believe significant value. > Ricky Said > > > > Now let me anticipate the question, "What would be the value > > of measuring > > individual SAs?" > > > > First, I acknowledge that measuring statistics on > "protSuites" is very > > useful! This closly paralles link monitoring which is of > > highest concern to > > O&M groups. I certainly believe that protSuite measuring (as > > opposed to > > individual SA measuring) will be the most common application > > for this mib > > and be the most customer demanded feature (just my gut > > feeling, not any > > official survey). > > > > But I see three needs for finer grain visibility into IPSec > devices. > > 1. drill down trouble shootin' for finer fault isolation > > 2. pattern recognition to identify attack profiles > > 3. device capacity monitoring, so that total number of SAs may be > > tracked as well as traffic count summations on comp, > ESP and AH Tim Said > > I'm not sure that multiple tables will give you any > significant benefit for > points 1 and 2, given the nature of protection suites. > > Even for point 3, if you want to measure the total traffic > that has ESP > applied to it across all protections suites, you add up the > traffic serviced > by all protection suites that have ESP. That's because the user level > traffic reported by ESP+AH, ESP, and AH protection suites > should be the > same. (Even with IPCOMP, the user level traffic reported > should still be the > same.) > OK, your points are well reasoned. But I am still having trouble with shutting the door on the ability to observe individual IPSec SAs. The complexity involved in creating three more tables to track individual ESP, AH, and COMP SAs is not much of a problem. When he ISAKMP doc says that "protection suites must be considered as a unit" it means for the purposes of determining the acceptability of a proposal. That sentence should not be taken to imply that ISAKMP requires that the individual security associations making up a proposal not be monitored in their own right. By not allowing the MIB to watch stats on individual IPSec SAs, you have artificially constrained the functionality down from IPSec monitoring to ISAKMP monitoring. Again, please know that I do agree that monitoring stats on a protection suite is probably the most important function of this MIB. It is the "Big Rock" which must be placed in the jar first. If we all go ask our customers if they want to monitor traffic flow stats down protections suites, I posit the answer is a resounding "YES, that's it exactly!!", But if we also ask our customers if it would be ok to NOT monitor individual Security Associations, I posit here the answer would be just as resounding, "NO!". I wonder if I am a 'lone ranger', 'ranting wild man in the wilderness' on this 'individual SA monitoring' issue. Are there others out there who have an opinion? ################################### # Ricky Charlet # rcharlet@RedCreek.com # (510) 795-6903 ################################### end Howdy; From owner-ipsec@portal.ex.tis.com Fri Feb 12 13:04:52 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16333; Fri, 12 Feb 1999 13:04:50 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA08245 for ipsec-outgoing; Fri, 12 Feb 1999 10:22:32 -0500 (EST) Date: Fri, 12 Feb 1999 10:43:08 -0500 Message-Id: <199902121543.KAA21078@brill.shiva.com> From: John Shriver To: rcharlet@redcreek.com CC: ipsec@tis.com In-reply-to: (message from Ricky Charlet on Thu, 11 Feb 1999 12:41:30 -0800) Subject: Re: New IPSec Monitoring MIB draft Sender: owner-ipsec@ex.tis.com Precedence: bulk Oh, I'm in the camp of wanting a table for each type of SA. Indexed by the fields that uniquely identify that SA. (For AH and ESP, that's destination IP address and SPI.) From owner-ipsec@portal.ex.tis.com Fri Feb 12 13:22:08 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16509; Fri, 12 Feb 1999 13:22:04 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA08393 for ipsec-outgoing; Fri, 12 Feb 1999 11:32:34 -0500 (EST) Message-Id: <199902121652.LAA12929@anuxc.mv.lucent.com> X-Sender: dac@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 12 Feb 1999 11:54:00 -0600 To: ipsec@tis.com From: Dave Clark Subject: ADDRESS-NOTIFICATION notify type? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello; What is the meaning of the ADDRESS-NOTIFICATION notify type defined in the ISAKMP RFC? Thanks. _________________________ Dave Clark Secure Technologies Lucent Technologies/Bell Labs 513-624-9360 PGP 5.5 Key ID: 0xE660D187 Fingerprint: 4F14 F76D 8E35 362C CECA 0BCD 21BC 007E E660 D187 From owner-ipsec@portal.ex.tis.com Mon Feb 15 04:23:49 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA14511; Mon, 15 Feb 1999 04:23:48 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id DAA14111 for ipsec-outgoing; Mon, 15 Feb 1999 03:44:29 -0500 (EST) Message-ID: <36C7E407.5EFB279F@dcd.abk.nec.co.jp> Date: Mon, 15 Feb 1999 18:08:23 +0900 From: Hiroki Ishibashi Organization: NEC Corporation X-Mailer: Mozilla 4.5 [ja] (Win95; I) X-Accept-Language: ja MIME-Version: 1.0 To: ipsec@tis.com Subject: Different Encryption Algorithms for Sned and Receive using IKE? Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a simple question that I want to clarify. Using SAs negotiated by IKE phase2, is it possible to use different encryption algorithms for sending and receiving data? By reading ISAKMP and IKE RFCs, encryption algorithms for both directions become the same. It this True? If one wants to use different encryption algorithms, the only way is to use manual keys, right? Thanks in advance, Hiroki I. NEC Corp. From owner-ipsec@portal.ex.tis.com Mon Feb 15 05:26:12 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA14949; Mon, 15 Feb 1999 05:26:12 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA14438 for ipsec-outgoing; Mon, 15 Feb 1999 05:34:29 -0500 (EST) Message-Id: <199902151054.NAA03402@relay2.elvis.ru> Comments: Authenticated sender is From: "Valery Smyslov" Organization: TWS To: ipsec@tis.com Date: Mon, 15 Feb 1999 13:54:03 +3 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Different Encryption Algorithms for Sned and Receive using I In-reply-to: <36C7E407.5EFB279F@dcd.abk.nec.co.jp> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-ipsec@ex.tis.com Precedence: bulk On 15 Feb 99 at 18:08, Hiroki Ishibashi wrote: > I have a simple question that I want to clarify. > Using SAs negotiated by IKE phase2, is it possible to use > different encryption algorithms for sending and receiving data? No. IKE can't negotiate different security attributes (except SPIs, of course) for different directions. > By reading ISAKMP and IKE RFCs, encryption algorithms for > both directions become the same. It this True? Yes. > If one wants to use different encryption algorithms, > the only way is to use manual keys, right? Yes. Or use some other key management protocol. > Thanks in advance, > > Hiroki I. > NEC Corp. Valery Smyslov TrustWorks B.V. From owner-ipsec@portal.ex.tis.com Mon Feb 15 17:13:59 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA21489; Mon, 15 Feb 1999 17:13:58 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA16230 for ipsec-outgoing; Mon, 15 Feb 1999 17:23:27 -0500 (EST) Message-ID: <36C8A343.F2A2B8C4@cs.umass.edu> Date: Mon, 15 Feb 1999 17:44:20 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, University of Massachusetts at Amherst X-Mailer: Mozilla 4.03 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: IP Security WG List Subject: Re: Cookie Requirements References: <199902111101.LAA19685@ns0.zergo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Chris Trobridge writes: > RFC2408 Para 2.5.3 states that cookie generation must ensure that cookies > depend on specific parties, that only cookies should not be acceptable by > other than the issuer. It then goes on to outline a method based on hashing > IP addresses, UDP ports, a local secret and time/day to produce the cookie. > > I don't see what advantage this has over choosing a suitably strong random > value. The cookie generation method in ISAKMP consumes random bits more slowly. This frugality is useful in environments where high-entropy random bits are hard to produce, quickly or at all. [...] > I'm not sure about the second argument either. I can see that it must not > be possible for an attacker to be able to guess the cookie generated in > response to a spoofed negotiation request (as with TCP). I'm not sure why > this requires a local secret for verification. The only reason I can think > of is if cookies aren't stored locally (initially?) and hence there would > have to be some means of verifying them. Even then I'm not sure how it > would help as you'd still need to know the time/date when the cookie was > created. Caching the generation time and a pointer to (the correct version of) the local secret could still save space vs. caching the entire cookie. -Lewis http://www.cs.umass.edu/~lmccarth -- "we have to yet really seriously debate the constitutional issues and whether or not we're willing to give up more freedom in order to have more security" -- U.S. Secretary of Defense William Cohen, 3 Feb 1999 From owner-ipsec@portal.ex.tis.com Mon Feb 15 17:17:50 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA21534; Mon, 15 Feb 1999 17:17:49 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA16281 for ipsec-outgoing; Mon, 15 Feb 1999 17:40:26 -0500 (EST) Message-ID: <36C8A7F0.79E52F79@assured-digital.com> Date: Mon, 15 Feb 1999 18:04:17 -0500 From: Andrew Sweeney X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "ipsec@tis.com" Subject: Proxy IDs and Tunnel mode Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I am running a test to ipsec-wit.antd.nist.gov. I am running in tunnel mode and I am not getting Proxy IDs sent to me during the Quick mode negotiation. It was my understanding that the proxy IDs are required in tunnel mode, how else do you know what net you are actually tunneling to. What happens in the case of a host running tunnel mode? Do you just assume that if there is no proxy ID's and you are in tunnel mode then this a host and not a gateway? In that case what is to stop a person from pretending that they are a host but really acting as a gateway and forwarding all traffic from the tunnel to anywhere? Thanks Andy -- Andrew Sweeney andy@assured-digital.com 9 Goldsmith Street, Littleton, MA 01460 http://www.assured-digital.com/ From owner-ipsec@portal.ex.tis.com Mon Feb 15 20:07:02 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA00160; Mon, 15 Feb 1999 20:07:01 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA16729 for ipsec-outgoing; Mon, 15 Feb 1999 20:11:26 -0500 (EST) Message-Id: <199902160132.RAA24617@sodium.network-alchemy.com> To: Andrew Sweeney cc: "ipsec@tis.com" Subject: Re: Proxy IDs and Tunnel mode Question In-reply-to: Your message of "Mon, 15 Feb 1999 18:04:17 EST." <36C8A7F0.79E52F79@assured-digital.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24614.919128742.1@network-alchemy.com> Date: Mon, 15 Feb 1999 17:32:22 -0800 From: Dan Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 15 Feb 1999 18:04:17 EST you wrote > > I am running a test to ipsec-wit.antd.nist.gov. I am running in > tunnel mode and I am not getting Proxy IDs sent to me during the Quick > mode negotiation. It was my understanding that the proxy IDs are > required in tunnel mode, how else do you know what net you are actually > tunneling to. They're not required and if you're the initiator and you didn't send them then you shouldn't expect them. > What happens in the case of a host running tunnel mode? Do you just > assume that if there is no proxy ID's and you are in tunnel mode then > this a host and not a gateway? Section 5.5 of RFC2409 says: "The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode." So if the encapsulation attribute negoatiated indicates tunnel mode and there are no additional identities passed then the identities are those of the ISAKMP peers from phase 1. (The term "client ID" replaced "proxy ID" because someone-- whose name I forget-- said that proxy was too confusing, but they both refer to the same thing). > In that case what is to stop a person > from pretending that they are a host but really acting as a gateway and > forwarding all traffic from the tunnel to anywhere? The packets (both inner and outer headers) would be addressed to the host so it would have to intentionally misbehave. So if the host is misbehaving then the answer to your question is: nothing. But such (mis)behavior can be done by a host with transport mode too. And it can be done with manually keyed SAs. Dan. From owner-ipsec@portal.ex.tis.com Mon Feb 15 23:14:24 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA10710; Mon, 15 Feb 1999 23:14:23 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id WAA16917 for ipsec-outgoing; Mon, 15 Feb 1999 22:49:24 -0500 (EST) Message-ID: <36C8EFA0.8BB0C3E2@cyphers.net> Date: Mon, 15 Feb 1999 20:10:08 -0800 From: Will Price X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: "ipsec@tis.com" Subject: Re: Proxy IDs and Tunnel mode Question References: <199902160132.RAA24617@sodium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I ran into an interesting case of this recently. If the intiator sends client IDs, and then the responder does *not* send client IDs presumably because they would have been identical to the initiator's or identical to the Phase 1 IDs. This would seem to be a protocol violation, correct? If the initiator sends client IDs, it would seem that the responder should also always send client IDs. Dan Harkins wrote: > > On Mon, 15 Feb 1999 18:04:17 EST Andrew Sweeney wrote > > > > I am running a test to ipsec-wit.antd.nist.gov. I am running in > > tunnel mode and I am not getting Proxy IDs sent to me during the Quick > > mode negotiation. It was my understanding that the proxy IDs are > > required in tunnel mode, how else do you know what net you are actually > > tunneling to. > > They're not required and if you're the initiator and you didn't send > them then you shouldn't expect them. > > > What happens in the case of a host running tunnel mode? Do you just > > assume that if there is no proxy ID's and you are in tunnel mode then > > this a host and not a gateway? > > Section 5.5 of RFC2409 says: > > "The identities of the SAs negotiated in Quick Mode are implicitly > assumed to be the IP addresses of the ISAKMP peers, without any > implied constraints on the protocol or port numbers allowed, unless > client identifiers are specified in Quick Mode." -- Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. From owner-ipsec@portal.ex.tis.com Wed Feb 17 17:10:08 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA13043; Wed, 17 Feb 1999 17:10:08 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA24705 for ipsec-outgoing; Wed, 17 Feb 1999 16:52:14 -0500 (EST) Message-ID: From: "Volpe, Victor" To: "'ipsec@tis.com'" Cc: "Volpe, Victor" Subject: IKE Keep-alives Date: Wed, 17 Feb 1999 17:12:32 -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@ex.tis.com Precedence: bulk All: We are currently using a proprietary IKE keep-alive mechanism between our IPSec client software and our IPSec concentrator. We use the keep-alives to alert the concentrator if a modem connection has dropped or if the Internet link has gone down so that we can clean up the appropriate remote access SAs quickly. My question is: Is there a more standard way of doing this? I could not find anything applicable in any of the RFCs. Thanks in advance, Victor /*************************************************************************** *****/ Victor Volpe Altiga Networks, Inc. Principal Software Engineer 124 Grove Street, Suite 309 vvolpe@altiga.com Franklin, MA 02038 Phone: (508) 541-7300 x105 Fax : (508) 541-7030 www.altiga.com /*************************************************************************** *****/ From owner-ipsec@portal.ex.tis.com Wed Feb 17 23:42:31 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA27166; Wed, 17 Feb 1999 23:42:31 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id AAA25741 for ipsec-outgoing; Thu, 18 Feb 1999 00:05:13 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D30@RED-MSG-50> From: Richard Draves To: "'Mobile IP'" , "'IPng List'" , "'IPsec'" Subject: RE: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Wed, 17 Feb 1999 21:26:03 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk (Is the draft http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-07.txt still under consideration by the IESG?) One of my concerns with the draft is that the interaction between mobility and IPsec is barely mentioned (one paragraph at the end of section 10.1) - not nearly enough is said to ensure interoperability, I think. And yet the spec requires the use of IPsec for mobility. At the interim WG meeting in Grenoble I got into a discussion with Brian Zill, Allison Mankin, Aaron Griggs, & others about the mobility/IPsec interaction. I think it's fairly complex. I'm hoping to start a discussion by looking at routing headers. I couldn't find anything in the IPsec architecture spec mentioning interactions with v6 routing headers or the source routing option in v4. Mobility uses routing headers. How should routing headers interact with IPsec? I believe that an IPsec-enabled node that is processing a routing header with non-zero Segments Left should do inbound IPsec processing (SPD lookup & policy verification) when it gets to the routing header and outbound IPsec processing before sending the updated packet. This should be just the same as a security gateway that is forwarding a packet. The routing header should not make it possible to bypass security policies. Carrying forward the analogy with security gateways, the IPsec processing associated with a routing header should only support tunnel-mode associations. Otherwise it makes life too difficult for the node processing the routing header, because it would have to be finding & removing & inserting headers in strange places. Security gateways must only support tunnel-mode associations. To make this concrete, suppose we have four nodes A, B, C, D. Node A sends a packet with a routing header through nodes B and C to node D. Node A can have tunnel and/or transport mode associations with node D, say for example transport-mode AH. Node A can only have a tunnel mode association with node B, say for example tunnel-mode ESP. The packets sent by node A will look like IPv6 hdr - dst B, src A ESP IPv6 hdr - dst B, src A Routing hdr, segments left = 2, addrs C, D AH Transport hdr There might be further tunnel-mode associations between nodes B & C, nodes C & D but node A won't know about that. Note that this means that outbound IPsec processing on node A has to happen *twice*, first for the final destination node D, and then again for the first intermediate destination node B. Does this sound reasonable? Applying this to the mobility case, there's only one intermediate destination address and the final destination and the intermediate destination address happen to both be assigned to the mobile node. Suppose the correspondent node has an active transport-mode AH association for a TCP connection with the mobile node. Then the mobile node wanders off and acquires a care-of address behind a security gateway. The correspondent node needs to use tunnel-mode ESP to the security gateway to reach the care-of address, and then transport-mode AH for the home address. This demonstrates the example above: when the correspondent node sends to the mobile node, it needs to do outbound IPsec processing twice, first for the home address, then for the care-of address. Thanks, Rich From owner-ipsec@portal.ex.tis.com Thu Feb 18 01:47:32 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA02192; Thu, 18 Feb 1999 01:47:32 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id BAA26017 for ipsec-outgoing; Thu, 18 Feb 1999 01:51:14 -0500 (EST) Message-Id: <3.0.5.32.19990218091235.0091ed40@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 18 Feb 1999 09:12:35 +0200 To: ipsec@tis.com From: Joern Sierwald Subject: Re: IKE Keep-alives In-Reply-To: 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 portal.ex.tis.com id BAA26014 Sender: owner-ipsec@ex.tis.com Precedence: bulk At 17:12 17.2.1999 -0500, you wrote: >All: > >We are currently using a proprietary IKE keep-alive mechanism between our >IPSec client software and our IPSec concentrator. We use the keep-alives to >alert the concentrator if a modem connection has dropped or if the Internet >link has gone down so that we can clean up the appropriate remote access SAs >quickly. > >My question is: Is there a more standard way of doing this? I could not >find anything applicable in any of the RFCs. > >Thanks in advance, > >Victor > What are you keeping alive? ISAKMP or IPsec SAs? If it's ISAKMP, just write a draft. I'd like an interoperable solution. Jörn From owner-ipsec@portal.ex.tis.com Thu Feb 18 07:51:21 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA07419; Thu, 18 Feb 1999 07:51:20 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA27058 for ipsec-outgoing; Thu, 18 Feb 1999 07:54:15 -0500 (EST) Message-Id: <3.0.1.32.19990218185018.0068ca7c@172.16.1.10> X-Sender: srinu@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 18 Feb 1999 18:50:18 +0500 To: ipsec@tis.com From: "S. B. Kulkarni" Subject: Handling of Life Two life times Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, I have some questions multiple life times, - Does the SA attribute of lifetime follow immediatly after lifetype in the SA payload. - If not and two lifetypes come before a lifetime, do we need to reject the proposal or go to next transform. - If two lifetypes are sent in the proposal and the responder supports only one type, reject the proposal (even if lifetimes for the common lifetype are same)? -If lifetime for any type negotiated is zero, is it an error ? -If lifetype is specified but not lifetime, go to next transform or reject proposal ? Thanks - Srinu ****************************************************************** S. B. Kulkarni Rendezvous On Chip Pvt Ltd. First Floor, Plot No. 14, NewVasaviNagar, Kharkhana, SECUNDERABAD - 500015. STATE ANDHRA PRADESH INDIA Ph : Office : +91 - 040 - 7742606/7740406 Home : +91 - 040 - 4065073 email address : srinu@trinc.com ****************************************************************** From owner-ipsec@portal.ex.tis.com Thu Feb 18 09:44:40 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA08773; Thu, 18 Feb 1999 09:44:40 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA27383 for ipsec-outgoing; Thu, 18 Feb 1999 09:40:04 -0500 (EST) Date: Thu, 18 Feb 1999 10:00:58 -0500 Message-Id: <199902181500.KAA24774@brill.shiva.com> From: John Shriver To: ipsec@tis.com Subject: IPsec DOI TC draft Sender: owner-ipsec@ex.tis.com Precedence: bulk My proposal for a Textual Conventions MIB for IPSec was published a while ago. Due to it being offered during a period of indecision whether the IPSec MIB was an IPSec work item, or an IPSecond work item, it was published under my name. Since then, the working group chairs have decided that the MIB is an IPSec work item, so it's really a WG document. Whether we can find the resources to develop a MIB of the style I'd like to see (one that's not a stopgap), I think any IPSec MIB's would benefit to use this DOI. It will make all the magic numbers readable in MIB walkers, while (presumably) solving the revision control problems. I still haven't heard a thing from the IANA taking on the management responsibility, I've sent the IANA mail, I've sent the IANA the I-D, and haven't heard a thing. (The IANA is slow sometimes.) To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shriver-doi-tc-mib-00.txt Date: Fri, 05 Feb 1999 10:23:41 -0500 Sender: cclark@ns.cnri.reston.va.us A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPSec DOI Textual Conventions MIB Author(s) : J. Shriver Filename : draft-shriver-doi-tc-mib-00.txt Pages : 18 Date : 04-Feb-99 This memo defines textual conventions for use in monitoring, status, and configuration MIBs for IPSec. It includes a MIB module that defines those textual conventions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shriver-doi-tc-mib-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-shriver-doi-tc-mib-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-shriver-doi-tc-mib-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. From owner-ipsec@portal.ex.tis.com Thu Feb 18 12:10:59 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA09922; Thu, 18 Feb 1999 12:10:58 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA27842 for ipsec-outgoing; Thu, 18 Feb 1999 11:52:06 -0500 (EST) From: Dan McDonald Message-Id: <199902181712.JAA16111@kebe.Eng.Sun.COM> Subject: Re: Last Call: Mobility Support in IPv6 to Proposed Standard To: richdr@microsoft.com (Richard Draves) Date: Thu, 18 Feb 1999 09:12:25 -0800 (PST) Cc: mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D30@RED-MSG-50> from "Richard Draves" at Feb 17, 99 09:26:03 pm 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.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I'm hoping to start a discussion by looking at routing headers. I couldn't > find anything in the IPsec architecture spec mentioning interactions with v6 > routing headers or the source routing option in v4. Mobility uses routing > headers. How should routing headers interact with IPsec? See the AH spec. Unfortunately, the precise wording of the LSRR option for IPv4 exempts it from inclusion in AH's ICV, but the IPv6 routing header 0 is perfect for AH inclusion. > I believe that an IPsec-enabled node that is processing a routing header > with non-zero Segments Left should do inbound IPsec processing (SPD lookup & > policy verification) when it gets to the routing header and outbound IPsec > processing before sending the updated packet. This should be just the same > as a security gateway that is forwarding a packet. The routing header should > not make it possible to bypass security policies. Why? The proper use of AH allows authenticated source routes. This is why AH still exists, even after ESP had an ICV added to it. Also, how? Are you going to distribute keys along each hop? That's a lot of IKE negotiations. You can do end-to-end AH on a source routed packet in IPv6. It's why we still HAVE AH, y'know. > Carrying forward the analogy with security gateways, the IPsec processing > associated with a routing header should only support tunnel-mode > associations. Otherwise it makes life too difficult for the node processing > the routing header, because it would have to be finding & removing & > inserting headers in strange places. Security gateways must only support > tunnel-mode associations. If you wish to have every intermediate node process the packet, yes, you'll _probably_ need tunnel mode. > To make this concrete, suppose we have four nodes A, B, C, D. Node A sends a > packet with a routing header through nodes B and C to node D. Node A can > have tunnel and/or transport mode associations with node D, say for example > transport-mode AH. Great example! The packet would look like: IPv6 hdr dst B, src A Routing hdr, segments left = 2, addrs C, D AH (with SA residing on D) Transport hdr That's all you need to do! The source route in question can be authenticated using AH. > Does this sound reasonable? It sounds like you're adding levels of complexity where you don't need any. Dan From owner-ipsec@portal.ex.tis.com Thu Feb 18 16:03:00 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA12261; Thu, 18 Feb 1999 16:03:00 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA29193 for ipsec-outgoing; Thu, 18 Feb 1999 15:24:11 -0500 (EST) Message-Id: <36CC7BB0.D2D633E0@xedia.com> Date: Thu, 18 Feb 1999 15:44:32 -0500 From: Eric Bomarsi Organization: xedia.com X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: ipsec@tis.com Subject: Bridging non-IP traffic over IPSec Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Is GRE tunnelling the proposed standard method of bridging non-IP traffic over IPSec tunnels? If so, where is this stated? Thanks in advance, /Eric Bomarsi From owner-ipsec@portal.ex.tis.com Thu Feb 18 16:03:06 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA12286; Thu, 18 Feb 1999 16:03:05 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA29536 for ipsec-outgoing; Thu, 18 Feb 1999 16:45:12 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D3E@RED-MSG-50> From: Richard Draves To: "'Dan McDonald'" Cc: mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: RE: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Thu, 18 Feb 1999 14:05:40 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I'm hoping to start a discussion by looking at routing > headers. I couldn't > > find anything in the IPsec architecture spec mentioning > interactions with v6 > > routing headers or the source routing option in v4. > Mobility uses routing > > headers. How should routing headers interact with IPsec? > > See the AH spec. Unfortunately, the precise wording of the > LSRR option for > IPv4 exempts it from inclusion in AH's ICV, but the IPv6 > routing header 0 is > perfect for AH inclusion. I'm sorry, I wasn't clear. I understand that the AH header's ICV calculation includes the routing header, so it provides end-to-end authentication of the routing header contents. The interaction between routing headers & IPsec & mobility that I'm concerned with is: - what kind of IPsec processing should a node processing a router header do? I think the answer is, it should be analogous to the processing done by a security gateway that is forwarding a packet. - what kind of IPsec processing should a node sending a packet with a routing header do? I think the answer is there should be an outbound SPD lookup based on the final destination address, and the appropriate SAs should be applied to the packet, then there should be another outbound SPD lookup based on the first intermediate destination address, and this could result in additional tunnel-mode SAs that should be applied to the packet. > > To make this concrete, suppose we have four nodes A, B, C, > D. Node A sends a > > packet with a routing header through nodes B and C to node > D. Node A can > > have tunnel and/or transport mode associations with node D, > say for example > > transport-mode AH. > > Great example! The packet would look like: > > IPv6 hdr dst B, src A > Routing hdr, segments left = 2, addrs C, D > AH (with SA residing on D) > Transport hdr > > That's all you need to do! The source route in question can > be authenticated > using AH. But suppose the outbound SPD in node A says that when A sends a packet to B, it should be sent via tunnel-mode ESP to a security gateway SG. Then the packet sent by A will look like: IPv6 hdr dst SG, src A ESP (SA between A and SG) IPv6 hdr dst B, src A AH (SA between A and D) Transport hdr The point being that node A will need to do two separate lookups in its outbound SPD when it sends a packet with a routing header. Thanks, Rich From owner-ipsec@portal.ex.tis.com Thu Feb 18 16:04:05 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA12314; Thu, 18 Feb 1999 16:04:05 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA29436 for ipsec-outgoing; Thu, 18 Feb 1999 16:23:10 -0500 (EST) From: Dan McDonald Message-Id: <199902182143.NAA17010@kebe.Eng.Sun.COM> Subject: Re: Bridging non-IP traffic over IPSec To: ebomarsi@xedia.com (Eric Bomarsi) Date: Thu, 18 Feb 1999 13:43:39 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <36CC7BB0.D2D633E0@xedia.com> from "Eric Bomarsi" at Feb 18, 99 03:44:32 pm 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.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Is GRE tunnelling the proposed standard method of bridging > non-IP traffic over IPSec tunnels? If so, where is this stated? I don't know if this is a proposed _standard_ for doing this, but I don't see why IPsec can't protect GRE-encapsulated traffic. After all, GRE is just another IP protocol (47), why can't it be protected. Dan From owner-ipsec@portal.ex.tis.com Thu Feb 18 17:02:48 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA00726; Thu, 18 Feb 1999 17:02:47 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA29624 for ipsec-outgoing; Thu, 18 Feb 1999 17:08:11 -0500 (EST) From: Dan McDonald Message-Id: <199902182229.OAA17257@kebe.Eng.Sun.COM> Subject: Re: Last Call: Mobility Support in IPv6 to Proposed Standard To: richdr@microsoft.com (Richard Draves) Date: Thu, 18 Feb 1999 14:29:05 -0800 (PST) Cc: danmcd@Eng.Sun.Com, mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D3E@RED-MSG-50> from "Richard Draves" at Feb 18, 99 02:05:40 pm 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.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry for my misunderstanding the question, Richard. > The interaction between routing headers & IPsec & mobility that I'm > concerned with is: > - what kind of IPsec processing should a node processing a router header do? > > I think the answer is, it should be analogous to the processing done by a > security gateway that is forwarding a packet. I can understand sometimes wanting to do this. But do you want this to happen all of the time? > - what kind of IPsec processing should a node sending a packet with a > routing header do? > > I think the answer is there should be an outbound SPD lookup based on the > final destination address, and the appropriate SAs should be applied to the > packet, then there should be another outbound SPD lookup based on the first > intermediate destination address, and this could result in additional > tunnel-mode SAs that should be applied to the packet. Are you sure you want to do this? What problem does protecting the packet a second time solve? If you have IPsec end-to-end, it is supposed to protect you against bad guys along your path, even if the bad guys are explicitly stated in a routing header (or are between your paths in an explicitly stated routing header). > But suppose the outbound SPD in node A says that when A sends a packet to B, > it should be sent via tunnel-mode ESP to a security gateway SG. Then the > packet sent by A will look like: > > IPv6 hdr dst SG, src A > ESP (SA between A and SG) > IPv6 hdr dst B, src A > AH (SA between A and D) > Transport hdr > > The point being that node A will need to do two separate lookups in its > outbound SPD when it sends a packet with a routing header. I understand why you'd want to default to a self-encapsulation if you need to doubly-protect the packet. One _could_, however, do something like: IPv6 hdr dst B, src A ESP (SA dst B) Routing Hdr (B, C, D) AH (SA dst D) Transport but that would get really confusing in an implementation. I may have policy that says protect traffix between A and B with transport ESP (or none-specified, which could default to transport). Let's hear more on this one, folks. Thanks to Richard for bringing it up! Dan From owner-ipsec@portal.ex.tis.com Thu Feb 18 17:05:03 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA00747; Thu, 18 Feb 1999 17:05:02 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA29823 for ipsec-outgoing; Thu, 18 Feb 1999 17:42:10 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D44@RED-MSG-50> From: Richard Draves To: "'Dan McDonald'" Cc: mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: RE: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Thu, 18 Feb 1999 15:03:21 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk > > The interaction between routing headers & IPsec & mobility that I'm > > concerned with is: > > - what kind of IPsec processing should a node processing a > router header do? > > > > I think the answer is, it should be analogous to the > processing done by a > > security gateway that is forwarding a packet. > > I can understand sometimes wanting to do this. But do you > want this to > happen all of the time? Yes I think an IPsec-enabled node should do inbound & outbound IPsec processing when it hits a routing header. Otherwise the routing header will be a mechanism for bypassing the security policies on the node. For example if the node is a security gateway connecting an internal net and an external net, and the security gateway receives a packet with a routing header that directs the packet from the external net to the internal net, then security processing should happen! Just the same as security processing when forwarding packets. > > - what kind of IPsec processing should a node sending a > packet with a > > routing header do? > > > > I think the answer is there should be an outbound SPD > lookup based on the > > final destination address, and the appropriate SAs should > be applied to the > > packet, then there should be another outbound SPD lookup > based on the first > > intermediate destination address, and this could result in > additional > > tunnel-mode SAs that should be applied to the packet. > > Are you sure you want to do this? What problem does > protecting the packet a > second time solve? If you have IPsec end-to-end, it is > supposed to protect > you against bad guys along your path, even if the bad guys > are explicitly > stated in a routing header (or are between your paths in an > explicitly stated > routing header). Yes I'm sure :-) Go back to the mobility example: I (node A) have a security association with a mobile node using its home address HA. My SPD tells me to use transport-mode AH when talking to HA. I have a TCP connection in progress to the mobile node, protected by transport-mode AH. Now the mobile node moves. It goes behind a security gateway SG. It has a care-of address CA. My SPD tells me to use tunnel-mode ESP via SG when talking to address CA. When I send a packet to the mobile node, it needs to look like IPv6 hdr, dst SG, src A ESP (SA with SG) IPv6 hdr, dst CA, src A routing hdr, segments left = 1, addr HA AH (SA with HA) TCP hdr Otherwise the scenario will break. Now how do I generate this packet? The only thing that makes sense to me is to do the outbound IPsec processing twice, first with destination address HA and then with destination address CA. > I understand why you'd want to default to a > self-encapsulation if you need to > doubly-protect the packet. One _could_, however, do something like: > > IPv6 hdr dst B, src A > ESP (SA dst B) > Routing Hdr (B, C, D) > AH (SA dst D) > Transport > > but that would get really confusing in an implementation. Yes, this would be awful to implement. It would be like having a transport-mode SA with a security gateway, which is a painful for a security gateway to support and hence the IPsec arch spec disallows it. I think for the same reason, only tunnel-mode SAs with the intermediate destination should be supported. Note also that this arrangement of headers runs counter to the preferred ordering in the IPv6 arch spec. Rich From owner-ipsec@portal.ex.tis.com Thu Feb 18 17:24:57 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA00885; Thu, 18 Feb 1999 17:24:56 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA29931 for ipsec-outgoing; Thu, 18 Feb 1999 18:18:09 -0500 (EST) From: Dan McDonald Message-Id: <199902182338.PAA17712@kebe.Eng.Sun.COM> Subject: Re: Last Call: Mobility Support in IPv6 to Proposed Standard To: richdr@microsoft.com (Richard Draves) Date: Thu, 18 Feb 1999 15:38:32 -0800 (PST) Cc: mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D44@RED-MSG-50> from "Richard Draves" at Feb 18, 99 03:03:21 pm 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.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Yes I think an IPsec-enabled node should do inbound & outbound IPsec > processing when it hits a routing header. Otherwise the routing header will > be a mechanism for bypassing the security policies on the node. Okay, you got me there... > Yes I'm sure :-) > > Go back to the mobility example: I (node A) have a security association with > a mobile node using its home address HA. My SPD tells me to use > transport-mode AH when talking to HA. I have a TCP connection in progress to > the mobile node, protected by transport-mode AH. > > Now the mobile node moves. It goes behind a security gateway SG. It has a > care-of address CA. My SPD tells me to use tunnel-mode ESP via SG when > talking to address CA. Okay. Your example below... > When I send a packet to the mobile node, it needs to look like > IPv6 hdr, dst SG, src A > ESP (SA with SG) > IPv6 hdr, dst CA, src A > routing hdr, segments left = 1, addr HA > AH (SA with HA) > TCP hdr Was different from your previous example where the inner and outer IPv6 headers had the same destination. I was assuming you were focussing on that case. When you have to transit via a security gateway, you have no choice but to tunnel. > Otherwise the scenario will break. Now how do I generate this packet? The > only thing that makes sense to me is to do the outbound IPsec processing > twice, first with destination address HA and then with destination address > CA. > Yes, this would be awful to implement. It would be like having a > transport-mode SA with a security gateway, which is a painful for a > security gateway to support and hence the IPsec arch spec disallows it. For dst SG != dst CA, you're right, and even dst SG == dst CA, it works. > I think for the same reason, only tunnel-mode SAs with the intermediate > destination should be supported. Note also that this arrangement of headers > runs counter to the preferred ordering in the IPv6 arch spec. I know it runs counter to the IPv6 arch spec, but that spec says that the order is a suggested one, not a mandatory one. Dan From owner-ipsec@portal.ex.tis.com Thu Feb 18 17:35:53 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01029; Thu, 18 Feb 1999 17:35:52 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA29694 for ipsec-outgoing; Thu, 18 Feb 1999 17:23:11 -0500 (EST) Date: Thu, 18 Feb 1999 17:44:00 -0500 Message-Id: <199902182244.RAA24979@brill.shiva.com> From: John Shriver To: ebomarsi@xedia.com CC: ipsec@tis.com In-reply-to: <36CC7BB0.D2D633E0@xedia.com> (message from Eric Bomarsi on Thu, 18 Feb 1999 15:44:32 -0500) Subject: Re: Bridging non-IP traffic over IPSec Sender: owner-ipsec@ex.tis.com Precedence: bulk Well, GRE is an Informational RFC, so GRE is not likely to be part of an IETF Proposed Standard solution. But, if you do it, you sure will be interoperable with Cisco... Certainly, it will work, and you can express GRE in the SPD. But, the SPD (and IKE negotiation) can't really negotiate what goes over the GRE. Is IP allowed over it? IPX? Transparent bridging? One thing that is standards track, and people have been implementing, is L2TP. Put PPP over that, and then you have a place to run non-IP traffic. Again, the SPD can't really control what goes over. But, you can express the L2TP UDP port in the SPD. As above, you will be interoperable with Cisco. Also, with PPP over L2F, there's some way to automate some of the configuration for the protocol that runs over IP, say assign an IPX network number. Of course, you're building a NBMA network, then you have to decide on the model (network addressing, broadcast, routing) that you're going to run on top of it. Then there's reality. If Windows 2000 only has PPTP (not L2TP), then that's going to be very popular, even though it's only an Informational RFC... Is it useful to interoperate with Microsoft? (Where do you want to go today?) From owner-ipsec@portal.ex.tis.com Thu Feb 18 17:37:16 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01040; Thu, 18 Feb 1999 17:37:15 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA00023 for ipsec-outgoing; Thu, 18 Feb 1999 18:37:09 -0500 (EST) Message-Id: <3.0.6.32.19990218185707.0079c9f0@jafar.uqar.uquebec.ca> X-Sender: pfhamste@jafar.uqar.uquebec.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 18 Feb 1999 18:57:07 -0500 To: ipsec@tis.com From: Steve Hammond Subject: L2TP vs IPSec 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 portal.ex.tis.com id SAA00020 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Maybe this is not the right place to post, but just let me know... I read this book 4 month ago: Kosiur, David, " Building and managing Virtual Private Networks ", WILEY, 1998. Somewhere in the text teh author say that L2TP is going to be an accepted standard by the IETF. I want to know if someone here is aware of that and if this is to become another WG aside IPSec (if it is true at all!). Thank you Steve Hammond http://www.uqar.uquebec.ca/pfhamste (Dernière mise-à-jour - last update: 4/01/98) From owner-ipsec@portal.ex.tis.com Thu Feb 18 19:29:05 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA07140; Thu, 18 Feb 1999 19:29:04 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA00319 for ipsec-outgoing; Thu, 18 Feb 1999 20:01:08 -0500 (EST) Message-ID: <36CCBCED.A7B5FA62@redcreek.com> Date: Thu, 18 Feb 1999 17:22:53 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: John Shriver CC: ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec References: <199902182244.RAA24979@brill.shiva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk John Shriver wrote: > > Well, GRE is an Informational RFC, so GRE is not likely to be part of > an IETF Proposed Standard solution. But, if you do it, you sure will > be interoperable with Cisco... > > Certainly, it will work, and you can express GRE in the SPD. But, the > SPD (and IKE negotiation) can't really negotiate what goes over the > GRE. Is IP allowed over it? IPX? Transparent bridging? > This is a timely topic, I guess. I would say that what goes over GRE is a local policy issue, and probably not an ipsec issue per se. That is, it would be up to your GRE subsystem to determine what it is willing to encapsulate, and then up to you ipsec subsystem to determine if policy permits GRE to pass. On the other hand, I guess looking into a GRE packet to see what protocol is being encapsulated is not really that much different than looking into a tcp/udp packet to see what ports are involved, so maybe it's not such a far-fetched idea, at that. > One thing that is standards track, and people have been implementing, > is L2TP. Put PPP over that, and then you have a place to run non-IP > traffic. > > Again, the SPD can't really control what goes over. But, you can > express the L2TP UDP port in the SPD. > > As above, you will be interoperable with Cisco. > I guess the main problem I have with using l2tp in this case has to do with efficiency. Unless l2tp has radically changed in the last 2 years, I think it really is overkill for this particular use. Perhaps it's time to dust off the GRE RFC and rev it... From owner-ipsec@portal.ex.tis.com Fri Feb 19 03:39:11 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA00596; Fri, 19 Feb 1999 03:39:11 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id DAA01798 for ipsec-outgoing; Fri, 19 Feb 1999 03:13:09 -0500 (EST) Date: Fri, 19 Feb 1999 09:29:33 +0100 (MET) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: L2TP vs IPSec To: Steve Hammond Cc: ipsec@tis.com In-Reply-To: "Your message with ID" <3.0.6.32.19990218185707.0079c9f0@jafar.uqar.uquebec.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by portal.ex.tis.com id DAA01795 Sender: owner-ipsec@ex.tis.com Precedence: bulk > Hi, > > Maybe this is not the right place to post, but just let me know... > > I read this book 4 month ago: > > Kosiur, David, " Building and managing Virtual Private Networks ", WILEY, > 1998. > > Somewhere in the text teh author say that L2TP is going to be an accepted > standard by the IETF. I want to know if someone here is aware of that and > if this is to become another WG aside IPSec (if it is true at all!). It is currently in last call, and is part of the PPP-EXT WG. L2TP provides a small set of VPN-like functionality that IPSec currently cannot, but it does not include security (which is an integral part of a VPN). L2TP relies on IPSec for any security. PatC > > Thank you > > Steve Hammond > http://www.uqar.uquebec.ca/pfhamste > (Dernière mise-à-jour - last update: 4/01/98) From owner-ipsec@portal.ex.tis.com Fri Feb 19 08:02:03 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02400; Fri, 19 Feb 1999 08:02:03 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA02459 for ipsec-outgoing; Fri, 19 Feb 1999 07:34:08 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF83E97D@exchange> From: Tim Jenkins To: Fred Baker , ipsec@tis.com, rgm@icsa.net, tytso@MIT.EDU Cc: bound@zk3.dec.com, daniele@zk3.dec.com, deering@cisco.com, hinden@iprg.nokia.com, mccann@zk3.dec.com, rlfink@lbl.gov, tonyhain@microsoft.com Subject: RE: IP6 support in draft-ietf-ipsec-monitor-mib-00.txt Date: Fri, 19 Feb 1999 07:57: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@ex.tis.com Precedence: bulk At this time, all addresses in the MIB are expressed as an OCTET STRING, of length 4 or 16, depending on the environment. There are no other IPV6 specifics. If this is insufficient, or there are other IPV6 considerations necessary, please let me know. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, February 18, 1999 5:43 PM > To: ipsec@tis.com; rgm@icsa.net; tjenkins@timestep.com; tytso@MIT.EDU > Cc: bound@zk3.dec.com; daniele@zk3.dec.com; deering@cisco.com; > hinden@iprg.nokia.com; mccann@zk3.dec.com; rlfink@lbl.gov; > tonyhain@microsoft.com > Subject: IP6 support in draft-ietf-ipsec-monitor-mib-00.txt > > > A question has come up that you may know the answer to. How does > draft-ietf-ipsec-monitor-mib-00.txt address IP6 environments? > Specifically what recommendations do you have for supporting IP6? > From owner-ipsec@portal.ex.tis.com Fri Feb 19 08:18:08 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA02517; Fri, 19 Feb 1999 08:18:07 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA02624 for ipsec-outgoing; Fri, 19 Feb 1999 08:11:58 -0500 (EST) Message-Id: <36CD6813.32D432D7@xedia.com> Date: Fri, 19 Feb 1999 08:33:08 -0500 From: Eric Bomarsi Organization: xedia.com X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: "Scott G. Kelly" Cc: John Shriver , ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec References: <199902182244.RAA24979@brill.shiva.com> <36CCBCED.A7B5FA62@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk For site-to-site LAN bridging over IPSec, the GRE solution seems unnecessarily complex: 1) The redundant headers: IP/ESP/IP/GRE/ 2) The additional administrator config to set up the GRE tunnel. 3) The 2nd redundant pass through the IP forwarder. Instead, why not simply use the "Ethernet-Transparent-Bridging" protocol identifier used in the GRE header in the ESP protocol field and eliminate the GRE tunnel: IP/ESP/ This is far simpler for me to stack in my gateway, more efficient, and eliminates administrator config. Am I missing something? /Eric Bomarsi "Scott G. Kelly" wrote: > John Shriver wrote: > > > > Well, GRE is an Informational RFC, so GRE is not likely to be part of > > an IETF Proposed Standard solution. But, if you do it, you sure will > > be interoperable with Cisco... > > > > Certainly, it will work, and you can express GRE in the SPD. But, the > > SPD (and IKE negotiation) can't really negotiate what goes over the > > GRE. Is IP allowed over it? IPX? Transparent bridging? > > > > This is a timely topic, I guess. I would say that what goes over GRE is > a local policy issue, and probably not an ipsec issue per se. That is, > it would be up to your GRE subsystem to determine what it is willing to > encapsulate, and then up to you ipsec subsystem to determine if policy > permits GRE to pass. On the other hand, I guess looking into a GRE > packet to see what protocol is being encapsulated is not really that > much different than looking into a tcp/udp packet to see what ports are > involved, so maybe it's not such a far-fetched idea, at that. > > > One thing that is standards track, and people have been implementing, > > is L2TP. Put PPP over that, and then you have a place to run non-IP > > traffic. > > > > Again, the SPD can't really control what goes over. But, you can > > express the L2TP UDP port in the SPD. > > > > As above, you will be interoperable with Cisco. > > > > I guess the main problem I have with using l2tp in this case has to do > with efficiency. Unless l2tp has radically changed in the last 2 years, > I think it really is overkill for this particular use. Perhaps it's time > to dust off the GRE RFC and rev it... From owner-ipsec@portal.ex.tis.com Fri Feb 19 09:31:29 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03104; Fri, 19 Feb 1999 09:31:29 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA03038 for ipsec-outgoing; Fri, 19 Feb 1999 09:33:28 -0500 (EST) Message-Id: <36CD7AC6.61962D05@xedia.com> Date: Fri, 19 Feb 1999 09:52:54 -0500 From: Eric Bomarsi Organization: xedia.com X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: "Scott G. Kelly" Cc: John Shriver , ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec References: <199902182244.RAA24979@brill.shiva.com> <36CCBCED.A7B5FA62@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk I agree with Scott that L2TP on the client is overkill. My understanding is that L2TP was intended to bundle many many PPP sessions at a CO or POP and tunnel them over the Internet to the terminating gateway. Initiating the L2TP session from the client will put these long headers over the low-speed/low-mtu dialup link resulting in fragmentation and poor performance, especially if you require security and the additional IPSec headers. The only benefit I can see is in the cable modem business because dialin service will be so bad. I believe the headers for a client initiated L2TP/IPSec tunneled packet would be something like this: IP/ESP/IP/UDP/L2TP/PPP - yikes! I've been trying to figure out why we are not pursuing an IPSec client solution for non-IP traffic, and the only answer I've found is that L2TP will do the job. A recent article from a leading analyst claims that L2TP will be the short term client VPN solution because IPSec currently doesn't handle non-IP traffic, private IP addresses across the internet, and support for RADIUS and other PPP-based authentication mechanisms. The non-IP traffic problem isn't a big deal. We can easily bridge non-IP over IPSec with a GRE tunnel or possibly directly as I suggested in my previous email. Private addresses across the Internet ARE supported simply by using IPSec tunneling mode. And finally, IKE does support RADIUS and I believe support for other user authentication mechanisms are proposed. In fact, arguably the ideal authentication, certificates (in software or on a smartcard) is supported by IKE today and not PPP as far as I know. /Eric Bomarsi "Scott G. Kelly" wrote: > John Shriver wrote: > > > > Well, GRE is an Informational RFC, so GRE is not likely to be part of > > an IETF Proposed Standard solution. But, if you do it, you sure will > > be interoperable with Cisco... > > > > Certainly, it will work, and you can express GRE in the SPD. But, the > > SPD (and IKE negotiation) can't really negotiate what goes over the > > GRE. Is IP allowed over it? IPX? Transparent bridging? > > > > This is a timely topic, I guess. I would say that what goes over GRE is > a local policy issue, and probably not an ipsec issue per se. That is, > it would be up to your GRE subsystem to determine what it is willing to > encapsulate, and then up to you ipsec subsystem to determine if policy > permits GRE to pass. On the other hand, I guess looking into a GRE > packet to see what protocol is being encapsulated is not really that > much different than looking into a tcp/udp packet to see what ports are > involved, so maybe it's not such a far-fetched idea, at that. > > > One thing that is standards track, and people have been implementing, > > is L2TP. Put PPP over that, and then you have a place to run non-IP > > traffic. > > > > Again, the SPD can't really control what goes over. But, you can > > express the L2TP UDP port in the SPD. > > > > As above, you will be interoperable with Cisco. > > > > I guess the main problem I have with using l2tp in this case has to do > with efficiency. Unless l2tp has radically changed in the last 2 years, > I think it really is overkill for this particular use. Perhaps it's time > to dust off the GRE RFC and rev it... From owner-ipsec@portal.ex.tis.com Fri Feb 19 09:31:30 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03105; Fri, 19 Feb 1999 09:31:29 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA03113 for ipsec-outgoing; Fri, 19 Feb 1999 09:37:23 -0500 (EST) Date: Thu, 18 Feb 1999 14:42:42 -0800 (PST) From: Fred Baker Message-Id: <199902182242.OAA02759@irp-view4.cisco.com> To: ipsec@tis.com, rgm@icsa.net, tjenkins@TimeStep.com, tytso@MIT.EDU Subject: IP6 support in draft-ietf-ipsec-monitor-mib-00.txt Cc: bound@zk3.dec.com, daniele@zk3.dec.com, deering@cisco.com, hinden@iprg.nokia.com, mccann@zk3.dec.com, rlfink@lbl.gov, tonyhain@microsoft.com Sender: owner-ipsec@ex.tis.com Precedence: bulk A question has come up that you may know the answer to. How does draft-ietf-ipsec-monitor-mib-00.txt address IP6 environments? Specifically what recommendations do you have for supporting IP6? From owner-ipsec@portal.ex.tis.com Fri Feb 19 09:31:30 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03102; Fri, 19 Feb 1999 09:31:29 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA03126 for ipsec-outgoing; Fri, 19 Feb 1999 09:39:24 -0500 (EST) Date: Thu, 18 Feb 1999 18:59:08 -0500 (EST) From: Mike Fratto To: Eric Bomarsi cc: ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec In-Reply-To: <36CC7BB0.D2D633E0@xedia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk You might wanna try L2TP. On Thu, 18 Feb 1999, Eric Bomarsi wrote: > > Is GRE tunnelling the proposed standard method of bridging > non-IP traffic over IPSec tunnels? If so, where is this stated? > > Thanks in advance, > /Eric Bomarsi > > > From owner-ipsec@portal.ex.tis.com Fri Feb 19 09:31:29 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03103; Fri, 19 Feb 1999 09:31:29 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA03284 for ipsec-outgoing; Fri, 19 Feb 1999 09:46:26 -0500 (EST) Message-Id: <199902191506.KAA23837@anuxc.mv.lucent.com> X-Sender: dac@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 19 Feb 1999 10:08:25 -0600 To: ipsec@tis.com From: Dave Clark Subject: ISAKMP SA situation field Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello; What is the size of the ISAKMP Situation field in the Security Association payload, when the DOI is 0 (generic)? Thanks in advance. _________________________ Dave Clark Secure Technologies Lucent Technologies/Bell Labs dac@lucent.com PGP 5.5 Key ID: 0xE660D187 Fingerprint: 4F14 F76D 8E35 362C CECA 0BCD 21BC 007E E660 D187 From owner-ipsec@portal.ex.tis.com Fri Feb 19 09:42:43 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03200; Fri, 19 Feb 1999 09:42:43 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA03597 for ipsec-outgoing; Fri, 19 Feb 1999 10:08:25 -0500 (EST) Message-Id: <3.0.1.32.19990218191122.00a54850@bl-mail1.corpeast.baynetworks.com> X-Sender: rshea@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 18 Feb 1999 19:11:22 -0500 To: Steve Hammond , ipsec@tis.com From: Rich_Shea@BayNetworks.COM (Rich Shea) Subject: Re: L2TP vs IPSec In-Reply-To: <3.0.6.32.19990218185707.0079c9f0@jafar.uqar.uquebec.ca> 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 portal.ex.tis.com id SAA00087 Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:57 PM 2/18/99 -0500, Steve Hammond wrote: >Hi, > >Maybe this is not the right place to post, but just let me know... > >I read this book 4 month ago: > >Kosiur, David, " Building and managing Virtual Private Networks ", WILEY, >1998. > >Somewhere in the text teh author say that L2TP is going to be an accepted >standard by the IETF. I want to know if someone here is aware of that and >if this is to become another WG aside IPSec (if it is true at all!). > L2TP has been in the works for perhaps about 3 years now. It is part of the PPP extensions WG, not its own WG though. From a VPN customer's point of view they could potentially consider both protocols, but I wouldn't say that they are really playing in the same space (e.g. L2TP is weak on security and specifies the use of transport mode IPSEC protection of L2TP for a secure L2TP tunnel). >Thank you > >Steve Hammond >http://www.uqar.uquebec.ca/pfhamste >(Dernière mise-à-jour - last update: 4/01/98) > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Richard Shea, Development Engineer rshea@NortelNetworks.com Nortel Networks / Extranet Access 978-635-2019 From owner-ipsec@portal.ex.tis.com Fri Feb 19 09:43:32 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA03212; Fri, 19 Feb 1999 09:43:32 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA03271 for ipsec-outgoing; Fri, 19 Feb 1999 09:44:26 -0500 (EST) From: kunzinge@us.ibm.com X-Lotus-FromDomain: IBMUS To: ipsec@tis.com Message-ID: <8525671D.004851CC.00@d54mta05.raleigh.ibm.com> Date: Fri, 19 Feb 1999 08:10:36 -0500 Subject: Strawman Text for Section 3.5 of "IPSec/PKI Req'ts" draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk This is the 2nd of two notes I though I sent out 2 days ago. I apologize if it is a duplicate. **************************** The current internet draft "PKI Requirements for IP Security" (draft-ietf-ipsec-pki-req-02e.txt) has a scetion 3.5 entitled "IKE PRocessing of Certificates", but as yet there is no text for this section. This contribution offers some draft text that may be appropriate for inclusion there. It will address issues such as: a) how does one use the Certifcate Request payload and the Certificate Payload in IKE, b) how does one do matching of IKE's Payload ID field with a certificate's subjects. The material here is simply one suggestion on how to handle these issues, and there certainly other strategies one could implement. Our goal is to simply offer a strawman approach for review and discussion by the IPSec Working Group, in the interests of reaching an informal consensus that will enhance the interoperability across IPSec/IKE implementations. Our strawman text for Section 3.5 is as follows: 3.5 IKE Processing of Certificates Digital certificates are used within the Internet Key Exchange (IKE) protocol's public-key-based Phase 1 exchange modes (Main Mode and Aggressive Mode) to validate the identities of the negotiating parties. Digital certificates are not used in any IKE Phase 2 exchanges, nor are they used in IKE's Phase 1 "preshared key" mode of authentication. Each party to the IKE negotiation MUST validate the IPSec Identification certificate of its peer. Then, depending on the particular method of authentication being used (that is, signatures or encryption), each party uses the other party's public key to either verify the peer's digital signature or decrypt the peer's encrypted data carried within the IKE payload. 3.5.1 Locally Stored PKI Information In order to properly handle digital certificates within the IKE flows, each IPSec-enabled device must: -Possess each of its own private keys and store each one securely. Depending on the IKE authentication modes that it supports, a device might have just a single "digital signature" key, a single "key encipherment" key, or both. Effectively, the device will need to securely store one private key for each digital certificate that has been issued to it. -Possess a copy of each of its IPSec Identification Certificate that it intends to use within the IKE Phase 1 negotiations. An IPSec device may have multiple digital certificates. For example, it may have obtained IPSec Identification certificates from multiple different CAs, or it may wish to support both signature-based and encryption-based modes of IKE authentication, thus requiring one digital certificate for each key usage mode. -The IPSec-device must have a copy of its certificates available to itself locally so that it can respond to any Certificate Request payloads that might occur during the IKE negotiations. -Possess a copy of a "trusted" CA Signing Certificate for each certification path that it may need to trace through. In general, the exact number of "trusted" CA Signing Certificates that an IPSec-capable device must store can not be specified until the details of the VPN (or VPNs) in which the device wishes to participate are known--that is, it is a matter of policy rather than a matter of protocol. 3.5.2 How an IPSec Device Validates Its Peer's Claimed Identity Within the IKE Phase 1 message exchanges, each party announces to the other who it claims to be via the ID Payload in the IKE messages that it originates. The basic rule is relatively simple: the identity claimed by an IPSec-enabled device in its IKE "IP Payload" must match the subject(s) named in the associated IPSec Identification Certificate. If this criterion is not satisfied, then the certificate is not valid and theIKE negotiations MUST be aborted. This criterion says absolutely nothing about the contents of the IP header of the datagram in which the IKE messages flow. The only relevant information is the ID Payload field and named subject(s)in the IPSec Identification Certificate. The rules for determining declaring a match (or a mismatch) depend on the type of identity claimed in the ID Payload field. They are straightforward: -An ID Payload of type "IPv4 Address matches a certificate's subjectAltName that expresses an IPv4 address whenever the two IP addresses are exactly the same -An ID Payload of type "IPv6 Address" matches a certificate's subjectAltName that expresses an IPv6 address whenever the two IP addresses are exactly the same -An ID Payload of type "Fully Qualified Domain Name" matches a certificate's subjectAltName that contains an identical domain name. For example, if the fully qualified domain name in the ID Payload is "joe.raleigh.ibm.com", then the DNS name contained in the certificate's subjAltName extension must also be "joe.raleigh.ibm.com". -An ID Payload of type "User Fully Qualified Domain Name" (email address) matches a certificate's subjectAltName that contains an identical user name. For example, if the fully qualifed domain name in the ID Payload is "Joe@raleigh.ibm.com", then the DNS name contained in the must also be "joe@raleigh.ibm.com". -An ID Payload of type "DER-encoded ASN.1 Distinguished Name" matches a certificate's subject field that carries the same distinguished name. 3.5.3 Exchanging Certificates within the IKE Flows As an alternative to retriveing certificates from an LDAP directory using an "offline" process, the IKE protocols offer a way to exchange certificates "inline" during the IKE message flows using IKE's Certificate Request Payload and its Certificate ayload. Inclusion of a Certificate Request Payload in an IKE message is optional. But, if it is present, the recipient of the request MUST reply to it, using the Certificate Payload. To implement an "inline" exchange of certificates, the following rules are recommended, depending on the box's role as either IKE Initiator or IKE Responder: A) IKE INITIATIOR -- MAIN MODE 1) An IPsec device that is an IKE initiator will include a Certificate Payload in IKE Message 5, even if no Certificate Request has been received from the IKE responder. The IPSec Identification Certificate delivered to the IKE responder will contain the public key that the responder will use to verify the initiator's digital signature, which is also carried in IKE Message 5. 2) An IPSec device that is an IKE initiator will always include a Certificate Request in IKE Message 5. This assures that the IKE responder will deliver a suitable IPSec Identification Certificate to the initiator in IKE Message 6. B) IKE INITIATOR - AGGRESSIVE MODE 1)An IPSec device that is an IKE initiator will include a Certificate Payload in IKE Message 3. The IPSec Identification Certificate delivered to the IKE responder will contain the public key that the responder will use to verify the digital signature that the initiator includes in Message 3. 2) An IPSec device that is an IKE initiator will include a Certificate Request in IKE Message 1. This assures that the IKE responder will deliver a suitable IPSec Identification Certificate to the initiator in IKE Message 2. C) IKE RESPONDER - MAIN MODE 1) An IPSec device that is an IKE responder will include a Certificate Payload in IKE Message 6, even if no Certificate Request has been received from the IKE responder. The certificate delivered to the IKE initiator will be the one that carries the public key that the IKE initiator will use in verifying IKE responder's digital signature, which is also carried in IKE Message 6. 2) An IPSec device that is an IKE responder will always include a Certificate Request in IKE Message 4. This assures that the IKE initiator will deliver a suitable IPSec Identification Certificate to the responder in IKE Message 5. D) IKE RESPONDER - AGGRESSIVE MODE 1) An IPSec device that is an IKE responder will always include a Certificate Payload in IKE Message 2, even in the absence of a prior Certificate Request from the IKE initiator. The certificate delivered to the IKE initiator will be the one that carries the public key that the IKE initiator will use to verify the responder's digital signature, which is also carried in IKE Message 2. 2) An IPSec device that is an IKE responder will always include a Certificate Request in IKE Message 2. This assures that the IKE initiator will deliver a suitable IPSec Identification Certificate to the responder in IKE Message 3. ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) Network Security Product Development, Dept JEUA,, RTP Phone: Tie 8-444-4142 , External 1-919-254-4142 Fax: Tie 8-444-6243, External 1-919-254-6243 From owner-ipsec@portal.ex.tis.com Fri Feb 19 10:12:53 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03436; Fri, 19 Feb 1999 10:12:53 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA03750 for ipsec-outgoing; Fri, 19 Feb 1999 10:38:26 -0500 (EST) Date: Fri, 19 Feb 1999 16:54:35 +0100 (MET) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: Bridging non-IP traffic over IPSec To: Eric Bomarsi Cc: "Scott G. Kelly" , John Shriver , ipsec@tis.com In-Reply-To: "Your message with ID" <36CD7AC6.61962D05@xedia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > I agree with Scott that L2TP on the client is overkill. > > My understanding is that L2TP was intended to bundle many many > PPP sessions at a CO or POP and tunnel them over the Internet > to the terminating gateway. Initiating the L2TP session from the > client will put these long headers over the low-speed/low-mtu > dialup link resulting in fragmentation and poor performance, > especially if you require security and the additional IPSec headers. > The only benefit I can see is in the cable modem business because > dialin service will be so bad. > > I believe the headers for a client initiated L2TP/IPSec tunneled > packet would be something like this: > IP/ESP/IP/UDP/L2TP/PPP - yikes! > > I've been trying to figure out why we are not pursuing an IPSec > client solution for non-IP traffic, and the only answer I've found > is that L2TP will do the job. > > A recent article from a leading analyst claims that L2TP will be > the short term client VPN solution because IPSec currently > doesn't handle non-IP traffic, private IP addresses across the > internet, and support for RADIUS and other PPP-based > authentication mechanisms. > > The non-IP traffic problem isn't a big deal. We can easily bridge > non-IP over IPSec with a GRE tunnel or possibly directly as I > suggested in my previous email. > > Private addresses across the Internet ARE supported simply > by using IPSec tunneling mode. > > And finally, IKE does support RADIUS and I believe support for other > user authentication mechanisms are proposed. In fact, arguably the > ideal authentication, certificates (in software or on a smartcard) is > supported by IKE today and not PPP as far as I know. FYI, PPP's Extensible Authentication Protocol (EAP) supports certificates. PatC > > /Eric Bomarsi > > > "Scott G. Kelly" wrote: > > > John Shriver wrote: > > > > > > Well, GRE is an Informational RFC, so GRE is not likely to be part of > > > an IETF Proposed Standard solution. But, if you do it, you sure will > > > be interoperable with Cisco... > > > > > > Certainly, it will work, and you can express GRE in the SPD. But, the > > > SPD (and IKE negotiation) can't really negotiate what goes over the > > > GRE. Is IP allowed over it? IPX? Transparent bridging? > > > > > > > This is a timely topic, I guess. I would say that what goes over GRE is > > a local policy issue, and probably not an ipsec issue per se. That is, > > it would be up to your GRE subsystem to determine what it is willing to > > encapsulate, and then up to you ipsec subsystem to determine if policy > > permits GRE to pass. On the other hand, I guess looking into a GRE > > packet to see what protocol is being encapsulated is not really that > > much different than looking into a tcp/udp packet to see what ports are > > involved, so maybe it's not such a far-fetched idea, at that. > > > > > One thing that is standards track, and people have been implementing, > > > is L2TP. Put PPP over that, and then you have a place to run non-IP > > > traffic. > > > > > > Again, the SPD can't really control what goes over. But, you can > > > express the L2TP UDP port in the SPD. > > > > > > As above, you will be interoperable with Cisco. > > > > > > > I guess the main problem I have with using l2tp in this case has to do > > with efficiency. Unless l2tp has radically changed in the last 2 years, > > I think it really is overkill for this particular use. Perhaps it's time > > to dust off the GRE RFC and rev it... > From owner-ipsec@portal.ex.tis.com Fri Feb 19 11:23:02 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04060; Fri, 19 Feb 1999 11:23:02 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA03979 for ipsec-outgoing; Fri, 19 Feb 1999 11:30:32 -0500 (EST) Message-ID: <4FC3655B6D7DD21195E208002BB760FB09AB40@ntwikkit> From: Waters Stephen To: ipsec@tis.com Cc: foxda@ctron.com Subject: IPSEC Security Gateway destructive testing software Date: Fri, 19 Feb 1999 16:54:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Does anyone have any tips for software to test the security of IPSEC security gateways? I guess some firewall-bashing stuff would do for starters - an IPSEC SG dealing with just IPSEC traffic should be able to stand up to anything from a firewall test suit (I hope). I guess I need a test suit for Firewall with an IPSEC add-on to launch IPSEC-savvy attacks. I suspect the ICSA is probably the way to go, but I'm after some free/cheap IPSEC SG bashing tools. Thanks in advance, Steve. * Stephen Waters Cabletron Systems Ltd. - R&D Unit 1, Heron Industrial Estate Basingstoke Road, Spencers Wood Reading, Berkshire, RG7 1PJ * External number: +44 118 988 0024 Internal extension: 12024 External fax: +44 118 988 0001 * Stephen.Waters@ctron.com From owner-ipsec@portal.ex.tis.com Fri Feb 19 11:38:36 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04158; Fri, 19 Feb 1999 11:38:35 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA04022 for ipsec-outgoing; Fri, 19 Feb 1999 11:50:31 -0500 (EST) Date: Fri, 19 Feb 1999 12:11:46 -0500 Message-Id: <199902191711.MAA25451@brill.shiva.com> From: John Shriver To: ebomarsi@xedia.com CC: skelly@redcreek.com, ipsec@tis.com In-reply-to: <36CD6813.32D432D7@xedia.com> (message from Eric Bomarsi on Fri, 19 Feb 1999 08:33:08 -0500) Subject: Re: Bridging non-IP traffic over IPSec Sender: owner-ipsec@ex.tis.com Precedence: bulk The problem with any tunneling based on the "next header" field in the ESP header (trailer, really) is that it is one byte, and it is from the same very scarce space that IP Protocol Numbers come from. They've already handed out some values of the IP Protocol Numbers for tunneling protocols that have since become utterly obsolete: in particular XNS. I don't think that the IANA will start handing out any new values anytime soon! GRE does already have a value of the IP Protocol Number byte. The GRE header can be made very small. Maybe IPsecond wants to move GRE onto the standards track, if Cisco is willing to cede revision control. (That would have the IANA assigning the 2-byte protocol ID's, which are the same ones they use in their original proprietary pre-PPP serial line format.) As for MTU issues, at least in a Windows client the NDIS interface allows the interface to present a reduced MTU, so even with all the headers (GRE or L2TP or PPTP), fragmentation can be avoided. But, on a tunnel between security gateways, fragmentation is a very real problem. IPX, for example, doesn't allow small-MTU networks to connect ones with larger MTU. One needs efficient IP reassembly, you may have lots of fragments in mid-reassembly. Another point, if you're using a tunneling protocol (GRE, L2TP, or PPTP) inside ESP, you don't need to run ESP in tunnel mode. You can run it in transport mode with no loss of functionality. Any of these tunnels will require a private SA bundle, so that's not a problem either. But, the people who strongly wanted the Security Policy Database may want to define new IPsec DOI Identification Types that would express (at a minimum) other network layer protocols. It could go all the way to IPX network ranges, and things like that, if desired. (But, this is very IPsecond by now.) One other advantage of L2TP that mustn't be ignored, having to use PPP helps a lot in configuring IPX, etc. Sure, we can add all that to IKE, but that's a lot of new protocol design... From owner-ipsec@portal.ex.tis.com Fri Feb 19 12:18:14 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA04566; Fri, 19 Feb 1999 12:18:13 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA04161 for ipsec-outgoing; Fri, 19 Feb 1999 12:35:31 -0500 (EST) Message-Id: <36CDA5D7.BE4BE5A@xedia.com> Date: Fri, 19 Feb 1999 12:56:39 -0500 From: Eric Bomarsi Organization: xedia.com X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: John Shriver Cc: skelly@redcreek.com, ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec References: <199902191711.MAA25451@brill.shiva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Well, the additional GRE header is only 4 bytes, but I believe you still need the additional and redundant IP header (20 bytes): IP/ESP (ipsec header) IP/GRE (gre header) Furthermore, the issue of hitting the IP lookup table twice is unfortunate, although probably minimal hit with caching. Another issue is that the administrator has to configure the GRE tunnel in addition to the IPSec tunnel policy. They won't like that. And finally, GRE is not standard, so at best we'll have a defacto standard if this becomes practice. I'm not familiar with IETF numbering policies, but if we could just get a 1-byte identifier to specify "bridging", we've solved all these problems. If not, then we pick a bridging identifier or make it user- configurable and we have a defacto standard that's better than GRE bridging and no less standard. But I think it would be much nicer to do this the right way and get an official number. As far as the client is concerned, the MTU and link speed problems seem far worse on the dial-up link than on the backbone between gateways or between the RAS and gateway. I am not familiar with the IPX config, but there are a lot of PPP-like dialup features going into IKE now. It just seems these issues can be solved without putting L2TP on the client. /Eric Bomarsi John Shriver wrote: > The problem with any tunneling based on the "next header" field in the > ESP header (trailer, really) is that it is one byte, and it is from > the same very scarce space that IP Protocol Numbers come from. > > They've already handed out some values of the IP Protocol Numbers for > tunneling protocols that have since become utterly obsolete: in > particular XNS. I don't think that the IANA will start handing out > any new values anytime soon! > > GRE does already have a value of the IP Protocol Number byte. The GRE > header can be made very small. Maybe IPsecond wants to move GRE onto > the standards track, if Cisco is willing to cede revision control. > (That would have the IANA assigning the 2-byte protocol ID's, which > are the same ones they use in their original proprietary pre-PPP > serial line format.) > > As for MTU issues, at least in a Windows client the NDIS interface > allows the interface to present a reduced MTU, so even with all the > headers (GRE or L2TP or PPTP), fragmentation can be avoided. > > But, on a tunnel between security gateways, fragmentation is a very > real problem. IPX, for example, doesn't allow small-MTU networks to > connect ones with larger MTU. One needs efficient IP reassembly, you > may have lots of fragments in mid-reassembly. > > Another point, if you're using a tunneling protocol (GRE, L2TP, or > PPTP) inside ESP, you don't need to run ESP in tunnel mode. You can > run it in transport mode with no loss of functionality. Any of these > tunnels will require a private SA bundle, so that's not a problem > either. > > But, the people who strongly wanted the Security Policy Database may > want to define new IPsec DOI Identification Types that would express > (at a minimum) other network layer protocols. It could go all the way > to IPX network ranges, and things like that, if desired. (But, this > is very IPsecond by now.) > > One other advantage of L2TP that mustn't be ignored, having to use PPP > helps a lot in configuring IPX, etc. Sure, we can add all that to > IKE, but that's a lot of new protocol design... From owner-ipsec@portal.ex.tis.com Fri Feb 19 12:20:11 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA04584; Fri, 19 Feb 1999 12:20:11 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA04284 for ipsec-outgoing; Fri, 19 Feb 1999 12:54:30 -0500 (EST) Date: Fri, 19 Feb 1999 13:15:19 -0500 Message-Id: <199902191815.NAA25494@brill.shiva.com> From: John Shriver To: ebomarsi@xedia.com CC: skelly@redcreek.com, ipsec@tis.com In-reply-to: <36CDA5D7.BE4BE5A@xedia.com> (message from Eric Bomarsi on Fri, 19 Feb 1999 12:56:39 -0500) Subject: Re: Bridging non-IP traffic over IPSec Sender: owner-ipsec@ex.tis.com Precedence: bulk Well, there is NO need for an inner IP header when you use GRE. You can do either: 1. Use ESP in transport mode, with next header value of GRE. 2. Use ESP in tunnel mode, with next header value of GRE. (Maybe this is illegal, and tunnel mode requires the next header to be IP? I don't remember.) The advantage of GRE in this case is that it is an IP-level protocol, not a UDP-level protocol. You don't need an IP/UDP header to navigate there. You have to configure whatever protocol runs over GRE. As I noted, Cisco would have to allow GRE to go standards track. (I don't know if they didn't want it to, or whether working groups rejected it because they thought tunneling is evil.) But, bridging is more evil than tunneling. (Been there.) Plus, if you're briding, you've got to fob in a 14 byte Ethernet header, which is longer than the minimal GRE header. No gain. (Also, complaining about any solution in the IPsec space being too configuration-intensive is "the pot calling the kettle black." IPsec is already massively configuration-intensive.) But, let's remember, the "client" (by the time we cut any more standards) will be whatever Microsoft has already decided to ship in Windows 2000. If that is PPTP, that WILL be how you talk IPX over IPsec to Windows. (Whether that's where you want to go today or not.) The NDIS WAN universe is so hairy that once Microsoft ships IPsec (in Windows 2000), nobody will be willing to install a different IPsec in it. (Who loads an alternate TCP/IP stack into Windows 95, 98, or NT these days? Same will apply to IPsec in Windows 2000.) From owner-ipsec@portal.ex.tis.com Fri Feb 19 13:56:49 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA05299; Fri, 19 Feb 1999 13:56:49 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA04635 for ipsec-outgoing; Fri, 19 Feb 1999 14:24:30 -0500 (EST) Message-Id: <199902191706.JAA16240@kiwi.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 19 Feb 1999 08:45:21 -0800 To: Tim Jenkins From: Fred Baker Subject: RE: IP6 support in draft-ietf-ipsec-monitor-mib-00.txt Cc: ipsec@tis.com, rgm@icsa.net, tytso@MIT.EDU, bound@zk3.dec.com, daniele@zk3.dec.com, deering@cisco.com, hinden@iprg.nokia.com, mccann@zk3.dec.com, rlfink@lbl.gov, tonyhain@microsoft.com In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDF83E97D@exchange> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 07:57 AM 2/19/99 -0500, Tim Jenkins wrote: >At this time, all addresses in the MIB are expressed as an OCTET STRING, of >length 4 or 16, depending on the environment. OK; I note that draft-ietf-ipsec-mib-03.txt has this broken - it has three instances of a 4-or-8 octet string, the latter being for IP6 addresses. I guess my searching routine must have keyed off your use of "IpAddress" in the names of the objects. Thanks for replying. From owner-ipsec@portal.ex.tis.com Fri Feb 19 14:00:50 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA05335; Fri, 19 Feb 1999 14:00:50 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA04548 for ipsec-outgoing; Fri, 19 Feb 1999 14:17:32 -0500 (EST) Date: Fri, 19 Feb 1999 09:57:24 -0800 (PST) From: An Mei Chen X-Sender: amchen@despair.ucsd.edu To: ipsec@tis.com Subject: freeBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Can someone please let me know if IPSec is available with FreeBSD 3.0? I am trying to learn about IPSec. Does anyone have non-proprietary source codes written for IPSec related-application that can share it with me. Thanks. ---An Chen amchen@ece.ucsd.edu From owner-ipsec@portal.ex.tis.com Fri Feb 19 14:23:24 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA05697; Fri, 19 Feb 1999 14:23:24 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA04679 for ipsec-outgoing; Fri, 19 Feb 1999 14:52:30 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D3E@RED-MSG-50> Date: Fri, 19 Feb 1999 10:13:50 -0500 To: Richard Draves From: Stephen Kent Subject: RE: Last Call: Mobility Support in IPv6 to Proposed Standard Cc: "'Dan McDonald'" , mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rich, The IPsec architecture does not envision processing by intermediate nodes in the fashion you allude to. Only end systems and security gateways perform IPsec processing, and they are arranged in pairs to bracket SAs. Steve From owner-ipsec@portal.ex.tis.com Fri Feb 19 14:52:27 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA05969; Fri, 19 Feb 1999 14:52:26 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA04807 for ipsec-outgoing; Fri, 19 Feb 1999 15:26:33 -0500 (EST) Message-ID: <36CDCDCB.4D9BD140@sympatico.ca> Date: Fri, 19 Feb 1999 15:47:07 -0500 From: Sandy Harris Organization: Crash Test Dummies on the Information Highway X-Mailer: Mozilla 4.5 [en]C-SYMPA (Win95; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: An Mei Chen CC: ipsec@tis.com Subject: Re: freeBSD References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk An Mei Chen wrote: > Can someone please let me know if IPSec is available with FreeBSD 3.0? > I am trying to learn about IPSec. Does anyone have non-proprietary > source codes written for IPSec related-application that can share it with me. htpp://www.xs4all.nl/~freeswan Linux FreeS/WAN project. Docs aren't yet on the web, but if you download and unpack the distribution, they'll appear as doc/*.html. doc/WWWref.html has pointers to various things which might be of interest to you:

IPSEC for BSD Unix

  • Naval Research Lab implementation of IPv6 and of IPSEC for IPv4
  • IPSEC for FreeBSD
  • Several large Japanese companies in a co-operative IPv6 and IPSEC project -- "The real aim of current [cryptography] policy is to ensure the continued effectiveness of US information warfare assets against individuals, businesses and governments in Europe and elsewhere" Ross Anderson, Cambridge University From owner-ipsec@portal.ex.tis.com Fri Feb 19 15:24:23 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA06207; Fri, 19 Feb 1999 15:24:23 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA04957 for ipsec-outgoing; Fri, 19 Feb 1999 16:02:33 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D55@RED-MSG-50> From: Richard Draves To: "'Stephen Kent'" Cc: "'Dan McDonald'" , mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: RE: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Fri, 19 Feb 1999 13:23:26 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk > The IPsec architecture does not envision processing by > intermediate nodes > in the fashion you allude to. Only end systems and security gateways > perform IPsec processing, and they are arranged in pairs to > bracket SAs. I'm not suggesting anything that would change the pairwise nature of security associations. I'm suggesting that intermediate destination node that is processing a routing header be treated as a security gateway, so the sending node can have tunnel-mode security associations with the intermediate node and the sending node can have security associations with the final destination node. What alternative are you suggesting? Are you saying that an IPsec-enabled node should drop any packet with a routing header? Or are you saying that an IPsec-enabled node should process the routing header & forward the packet and bypass all IPsec processing? Thanks, Rich From owner-ipsec@portal.ex.tis.com Fri Feb 19 17:58:22 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA07338; Fri, 19 Feb 1999 17:58:22 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA05280 for ipsec-outgoing; Fri, 19 Feb 1999 18:35:34 -0500 (EST) Message-ID: <36CDFA6A.95021DF7@redcreek.com> Date: Fri, 19 Feb 1999 15:57:30 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: John Shriver CC: ebomarsi@xedia.com, ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec References: <199902191815.NAA25494@brill.shiva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk John Shriver wrote: > > Well, there is NO need for an inner IP header when you use GRE. You > can do either: > > 1. Use ESP in transport mode, with next header value of GRE. > 2. Use ESP in tunnel mode, with next header value of GRE. (Maybe this > is illegal, and tunnel mode requires the next header to be IP? I > don't remember.) I think (2) is technically illegal, although an argument exists for special treatment. Presumably, you want to do ESP/GRE at a gateway, and not on a host. If you *are* doing it on a host for some reason, then you can just use transport mode, as in (1). However, RFC2401 requires that security gateways communicate using tunnel mode unless the sgw is terminating the connection. Now, it could be argued that the sgw *is* terminating the GRE connection, in which case transport mode between the GRE endpoints would be acceptable. Not bad, I guess. > > The advantage of GRE in this case is that it is an IP-level protocol, > not a UDP-level protocol. You don't need an IP/UDP header to navigate > there. It's been quite a while since I looked at the L2TP draft, but I'm under the strong impression that it's not a UDP protocol. There may be a UDP control channel associated with it, but I think the protocol itself operates at layer 2. I know we have at least a few l2tp experts lurking here - perhaps they will enlighten us. > But, let's remember, the "client" (by the time we cut any more > standards) will be whatever Microsoft has already decided to ship in > Windows 2000. If that is PPTP, that WILL be how you talk IPX over > IPsec to Windows. (Whether that's where you want to go today or not.) > The NDIS WAN universe is so hairy that once Microsoft ships IPsec (in > Windows 2000), nobody will be willing to install a different IPsec in > it. (Who loads an alternate TCP/IP stack into Windows 95, 98, or NT > these days? Same will apply to IPsec in Windows 2000.) I don't think this is necessarily true. Given that PPTP has been shown to be very broken (by Schneier, et al), and given that ultimately, putting a bunch of extra bits on already overtaxed network wires is frowned upon by most realists, even m$ may have difficulty convincing everyone that their way is the only way, especially if someone comes up with a GRE shim that interoperates with the rest of the world. From owner-ipsec@portal.ex.tis.com Fri Feb 19 19:44:23 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA15206; Fri, 19 Feb 1999 19:44:22 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA05562 for ipsec-outgoing; Fri, 19 Feb 1999 20:42:34 -0500 (EST) From: "Sumit A. Vakil" To: Subject: RE: Bridging non-IP traffic over IPSec Date: Fri, 19 Feb 1999 18:06:06 -0800 Message-ID: <001801be5c75$933b0400$8eec10ac@pc-svakil.internetdevices.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <36CDFA6A.95021DF7@redcreek.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ipsec@ex.tis.com Precedence: bulk > John Shriver wrote: > > > > Well, there is NO need for an inner IP header when you use GRE. You > > can do either: > > > > 1. Use ESP in transport mode, with next header value of GRE. > > 2. Use ESP in tunnel mode, with next header value of GRE. (Maybe this > > is illegal, and tunnel mode requires the next header to be IP? I > > don't remember.) > > I think (2) is technically illegal, although an argument exists for > special treatment. Presumably, you want to do ESP/GRE at a gateway, and > not on a host. If you *are* doing it on a host for some reason, then you > can just use transport mode, as in (1). However, RFC2401 requires that > security gateways communicate using tunnel mode unless the sgw is > terminating the connection. Now, it could be argued that the sgw *is* > terminating the GRE connection, in which case transport mode between the > GRE endpoints would be acceptable. Not bad, I guess. > > > > > The advantage of GRE in this case is that it is an IP-level protocol, > > not a UDP-level protocol. You don't need an IP/UDP header to navigate > > there. > > It's been quite a while since I looked at the L2TP draft, but I'm under > the strong impression that it's not a UDP protocol. There may be a UDP > control channel associated with it, but I think the protocol itself > operates at layer 2. I know we have at least a few l2tp experts lurking > here - perhaps they will enlighten us. L2TP runs over UDP (both data and control channels) in IP networks. It can run directly over a layer 2 protocol like ATM. I think that there's an L2TP over ATM/FR draft somewhere. > > > But, let's remember, the "client" (by the time we cut any more > > standards) will be whatever Microsoft has already decided to ship in > > Windows 2000. If that is PPTP, that WILL be how you talk IPX over > > IPsec to Windows. (Whether that's where you want to go today or not.) > > The NDIS WAN universe is so hairy that once Microsoft ships IPsec (in > > Windows 2000), nobody will be willing to install a different IPsec in > > it. (Who loads an alternate TCP/IP stack into Windows 95, 98, or NT > > these days? Same will apply to IPsec in Windows 2000.) > > I don't think this is necessarily true. Given that PPTP has been shown > to be very broken (by Schneier, et al), and given that ultimately, > putting a bunch of extra bits on already overtaxed network wires is > frowned upon by most realists, even m$ may have difficulty convincing > everyone that their way is the only way, especially if someone comes up > with a GRE shim that interoperates with the rest of the world. > Actually, Schneier makes it very clear that its not PPTP, but the implementation of PPTP they analyzed that is broken. Check out his FAQ on the topic at http://www.counterpane.com/pptp-faq.html. Sumit A. Vakil Internet Devices, Inc. From owner-ipsec@portal.ex.tis.com Sat Feb 20 21:40:08 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA26872; Sat, 20 Feb 1999 21:40:07 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA09733 for ipsec-outgoing; Sat, 20 Feb 1999 21:50:31 -0500 (EST) Message-Id: <3.0.5.32.19990220220754.007b5320@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sat, 20 Feb 1999 22:07:54 -0500 To: "Sumit A. Vakil" From: David Jablon Subject: RE: Bridging non-IP traffic over IPSec Cc: , In-Reply-To: <001801be5c75$933b0400$8eec10ac@pc-svakil.internetdevices.c om> References: <36CDFA6A.95021DF7@redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk I noticed that Scott G. Kelly wrote: >> [...] Given that PPTP has been shown >> to be very broken (by Schneier, et al), and given that ultimately, >> putting a bunch of extra bits on already overtaxed network wires is >> frowned upon by most realists, even m$ may have difficulty convincing >> everyone that their way is the only way [...] To which, Sumit A. Vakil replied: > Actually, Schneier makes it very clear that its not PPTP, but the > implementation of PPTP they analyzed that is broken. Check out his FAQ on > the topic at http://www.counterpane.com/pptp-faq.html. Please be aware that this FAQ does not go nearly far enough in condemning PPTP. MS-PPTP is just one particularly weak version of challenge-hashed-response authentication for passwords (CHRAP), in which, according to the FAQ: "Passwords are protected by hash functions so badly that most can be easily recovered." What the FAQ neglects to say, however, is that even a "good" implementation of PPTP, like all similar methods based on purely symmetric ciphers or hash functions, necessarily exposes *lots* of user passwords to brute-force network attack. In my view, this is completely unacceptable. Given the *many* stronger alternatives today, with IPSEC as merely one example, there is just no good excuse to use PPTP or any similar CHRAP over an otherwise insecure network. ------------------------- David P. Jablon Integrity Sciences, Inc. dpj@world.std.com From owner-ipsec@portal.ex.tis.com Sun Feb 21 15:26:46 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17966; Sun, 21 Feb 1999 15:26:45 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA10928 for ipsec-outgoing; Sun, 21 Feb 1999 15:58:27 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <36CD6813.32D432D7@xedia.com> References: <199902182244.RAA24979@brill.shiva.com> <36CCBCED.A7B5FA62@redcreek.com> Date: Fri, 19 Feb 1999 15:49:36 -0500 To: Eric Bomarsi From: Stephen Kent Subject: Re: Bridging non-IP traffic over IPSec Cc: "Scott G. Kelly" , John Shriver , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Eric, ESP requires the next protocol to be a transport protocol or IP, so carrying an Ethernet frame directky above ESP would not be valid. Steve From owner-ipsec@portal.ex.tis.com Sun Feb 21 16:33:09 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA20990; Sun, 21 Feb 1999 16:33:09 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA11067 for ipsec-outgoing; Sun, 21 Feb 1999 17:17:28 -0500 (EST) Date: Sun, 21 Feb 1999 17:37:59 -0500 Message-Id: <199902212237.RAA26685@brill.shiva.com> From: John Shriver To: dpj@world.std.com CC: svakil@internetdevices.com, ipsec@tis.com, skelly@redcreek.com In-reply-to: <3.0.5.32.19990220220754.007b5320@world.std.com> (message from David Jablon on Sat, 20 Feb 1999 22:07:54 -0500) Subject: Re: Bridging non-IP traffic over IPSec Sender: owner-ipsec@ex.tis.com Precedence: bulk Let's not be distracted bashing the "security" problems of PPTP. Yes, without IPSec, it's a joke security wise. But nobody is even going to know if it even _IS_ PPTP if it's inside ESP. This discussion is about how to tunnel non-IP traffic over IPSec (see the subject), not bashing Microsoft. While PPTP is not a well-loved protocol for many reasons, for the purposes of this discussion it's semantically (if not standards-track-ly) equivalent to L2TP. From owner-ipsec@portal.ex.tis.com Sun Feb 21 16:33:28 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21008; Sun, 21 Feb 1999 16:33:27 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA11053 for ipsec-outgoing; Sun, 21 Feb 1999 17:13:28 -0500 (EST) Date: Sun, 21 Feb 1999 17:34:51 -0500 Message-Id: <199902212234.RAA26683@brill.shiva.com> From: John Shriver To: kent@bbn.com CC: ipsec@tis.com In-reply-to: (message from Stephen Kent on Sun, 21 Feb 1999 14:07:42 -0500) Subject: Re: Bridging non-IP traffic over IPSec Sender: owner-ipsec@ex.tis.com Precedence: bulk Well, in the case where one is running IPX over PPP over L2TP over ESP over IP, the endpoint of the IP traffic is the security gateway at each end. Well, this presumes that the security gateway is also going to rip all the headers off up to the IPX level, and be an IPX router on the internal networks. So, it is the ultimate endpoint of the _IP_ traffic. So, by the semantics, we are OK using ESP transport mode. Of course, the fact that the the security gateway is not the ultimate endpoint of the IPX traffic might be viewed as violating the spirit of RFC 2401. Of course, since Microsoft doesn't have MTU problems in their stack of IPX over PPP over PPTP (or even L2TP) over IP over ESP over IP, they can contently use tunnel or transport mode. IPX's MTU problems don't show when the enpoint of the connection has restricted MTU. From owner-ipsec@portal.ex.tis.com Mon Feb 22 05:16:01 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA18180; Mon, 22 Feb 1999 05:16:00 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id EAA12623 for ipsec-outgoing; Mon, 22 Feb 1999 04:56:27 -0500 (EST) Message-ID: <4FC3655B6D7DD21195E208002BB760FB09AB54@ntwikkit> From: Waters Stephen To: ipsec@tis.com Subject: Question about Extended Authentication in IKE Date: Mon, 22 Feb 1999 10:20:32 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk An extract from the draft : "This protocol can therefore be used in conjunction with any existing basic ISAKMP authentication method as defined in [IKE]. If mutual authentication is not required, then the phase 1 negotiation SHOULD use an authentication method of shared-secret and have that shared-secret be null. This, is however, NOT suggested since the edge-device is NOT authenticated. This authentication MUST be used after a phase 1 exchange has completed and before a phase 2 exchange. The Transaction exchange is therefore attached (appended) to the phase 1 exchanges (MainMode, AggressiveMode). If the extended authentication fails, then the phase 1 SA MUST be deleted." Hi, If I want to use RADIUS to scale my IPSEC remote access, I could use IKECFG messages to do that. Since the draft suggests that NULL Phase-1 authentication is "NOT suggested", then the problem is how to scale the Phase-1 authentication? Assuming I still use pre-sharded secret, then I would HAVE to use Aggresvice-mode, AND have a way of finding the appropriate pre-shard secret for each client. Can I use this same mechanism to retrieve pre-sharded secret information (which I may cache I guess)? If I went for signature authentication (certificates), why should I consider using any other form of authentication? Cheers, Steve. * Stephen Waters Cabletron Systems Ltd. - R&D Unit 1, Heron Industrial Estate Basingstoke Road, Spencers Wood Reading, Berkshire, RG7 1PJ * External number: +44 118 988 0024 Internal extension: 12024 External fax: +44 118 988 0001 * Stephen.Waters@ctron.com From owner-ipsec@portal.ex.tis.com Mon Feb 22 08:13:27 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA20088; Mon, 22 Feb 1999 08:13:26 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA13081 for ipsec-outgoing; Mon, 22 Feb 1999 08:21:23 -0500 (EST) Message-Id: <36D15EC3.38AEDC9A@xedia.com> Date: Mon, 22 Feb 1999 08:42:27 -0500 From: Eric Bomarsi Organization: xedia.com X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: "Scott G. Kelly" Cc: John Shriver , ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec References: <199902191815.NAA25494@brill.shiva.com> <36CDFA6A.95021DF7@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Use of ESP transport mode is for traffic destined to the end system and tunnel mode is for traffic to be forwarded by a gateway. More importantly, it comes back to configuration and management. Look at it from your customer's persective. An ISP wants to configure, monitor and bill on an IPSec tunnel it has created for a company between 2 sites. It defines a security policy, specifies the routes to direct traffic into the tunnel, and configures a monitor to watch the tunnelled traffic between sites. Now there's a need to handle a small fraction of non-IP traffic so our answer is to configure another security policy, establish another IKE session, possibly burn more addresses with a GRE tunnel, configure another monitor and sum the traffic stats. Yes, it is a solution, but the customers aren't going to buy it, and I don't blame them. Just put the bridged traffic through the existing tunnel. BTW, you do need the redundant IP header with GRE inside an IPSec tunnel. A standard GRE tunnel downlinks to IP and uplinks to a bridge, and knows nothing about IPSec and vice versa. Using ESP protocol of GRE would not work with existing GRE equipment. /Eric Bomarsi "Scott G. Kelly" wrote: > John Shriver wrote: > > > > Well, there is NO need for an inner IP header when you use GRE. You > > can do either: > > > > 1. Use ESP in transport mode, with next header value of GRE. > > 2. Use ESP in tunnel mode, with next header value of GRE. (Maybe this > > is illegal, and tunnel mode requires the next header to be IP? I > > don't remember.) > > > > I think (2) is technically illegal, although an argument exists for > special treatment. Presumably, you want to do ESP/GRE at a gateway, and > not on a host. If you *are* doing it on a host for some reason, then you > can just use transport mode, as in (1). However, RFC2401 requires that > security gateways communicate using tunnel mode unless the sgw is > terminating the connection. Now, it could be argued that the sgw *is* > terminating the GRE connection, in which case transport mode between the > GRE endpoints would be acceptable. Not bad, I guess. > > > > > > The advantage of GRE in this case is that it is an IP-level protocol, > > not a UDP-level protocol. You don't need an IP/UDP header to navigate > > there. > > It's been quite a while since I looked at the L2TP draft, but I'm under > the strong impression that it's not a UDP protocol. There may be a UDP > control channel associated with it, but I think the protocol itself > operates at layer 2. I know we have at least a few l2tp experts lurking > here - perhaps they will enlighten us. > > > But, let's remember, the "client" (by the time we cut any more > > standards) will be whatever Microsoft has already decided to ship in > > Windows 2000. If that is PPTP, that WILL be how you talk IPX over > > IPsec to Windows. (Whether that's where you want to go today or not.) > > The NDIS WAN universe is so hairy that once Microsoft ships IPsec (in > > Windows 2000), nobody will be willing to install a different IPsec in > > it. (Who loads an alternate TCP/IP stack into Windows 95, 98, or NT > > these days? Same will apply to IPsec in Windows 2000.) > > I don't think this is necessarily true. Given that PPTP has been shown > to be very broken (by Schneier, et al), and given that ultimately, > putting a bunch of extra bits on already overtaxed network wires is > frowned upon by most realists, even m$ may have difficulty convincing > everyone that their way is the only way, especially if someone comes up > with a GRE shim that interoperates with the rest of the world. From owner-ipsec@portal.ex.tis.com Mon Feb 22 08:37:49 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA20287; Mon, 22 Feb 1999 08:37:49 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA13041 for ipsec-outgoing; Mon, 22 Feb 1999 08:13:23 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF83EE0B@exchange> From: Tim Jenkins To: Waters Stephen , ipsec@tis.com Subject: RE: Question about Extended Authentication in IKE Date: Mon, 22 Feb 1999 08:35:17 -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@ex.tis.com Precedence: bulk To address scalability and not use pre-shared keys, you could use one of the hybrid authentication mechanisms described in . This allows the gateway (the responder) to have a certificate, and be authenticated using that. The client (the initiator) would use extended authentication to be authenticated by the gateway. While the client implementation still has to know how to deal with certificates, it does not actually have to have certificates, allowing remote users to be authenticated using only (perhaps existing) legacy mechanisms. Distribution and management of client certificates becomes unnecessary. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Waters Stephen [mailto:stephen.Waters@cabletron.com] > Sent: Monday, February 22, 1999 5:21 AM > To: ipsec@tis.com > Subject: Question about Extended Authentication in IKE > > > An extract from the draft : > "This protocol can therefore be used in conjunction with any > existing basic > ISAKMP authentication method as defined in [IKE]. If mutual > authentication > is not required, then the phase 1 negotiation SHOULD use an > authentication > method of shared-secret and have that shared-secret be null. This, is > however, NOT suggested since the edge-device is NOT authenticated. > This authentication MUST be used after a phase 1 exchange has > completed and > before a phase 2 exchange. The Transaction exchange is > therefore attached > (appended) to the phase 1 exchanges (MainMode, AggressiveMode). If the > extended authentication fails, then the phase 1 SA MUST be deleted." > > Hi, > If I want to use RADIUS to scale my IPSEC remote access, I > could use IKECFG > messages to do that. Since the draft suggests that NULL Phase-1 > authentication is "NOT suggested", then the problem is how > to scale the > Phase-1 authentication? > Assuming I still use pre-sharded secret, then I would HAVE to use > Aggresvice-mode, AND have a way of finding the appropriate > pre-shard secret > for each client. Can I use this same mechanism to retrieve > pre-sharded > secret information (which I may cache I guess)? > If I went for signature authentication (certificates), why > should I consider > using any other form of authentication? > Cheers, Steve. > > > * Stephen Waters > Cabletron Systems Ltd. - R&D > Unit 1, Heron Industrial Estate > Basingstoke Road, Spencers Wood > Reading, Berkshire, RG7 1PJ > > * External number: +44 118 988 0024 > Internal extension: 12024 > External fax: +44 118 988 0001 > > * Stephen.Waters@ctron.com > > From owner-ipsec@portal.ex.tis.com Mon Feb 22 08:46:47 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA20361; Mon, 22 Feb 1999 08:46:47 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA13207 for ipsec-outgoing; Mon, 22 Feb 1999 08:58:24 -0500 (EST) Message-Id: <36D16764.49543494@xedia.com> Date: Mon, 22 Feb 1999 09:19:17 -0500 From: Eric Bomarsi Organization: xedia.com X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en Mime-Version: 1.0 To: Stephen Kent Cc: "Scott G. Kelly" , John Shriver , ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec References: <199902182244.RAA24979@brill.shiva.com> <36CCBCED.A7B5FA62@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent wrote: > Eric, > > ESP requires the next protocol to be a transport protocol or IP, so > carrying an Ethernet frame directky above ESP would not be valid. > > Steve What about..... In RFC 1700 the IP protocol numbers include: 97 ETHERIP Ethernet-within-IP Encapsulation [RXH1] /Eric Bomarsi From owner-ipsec@portal.ex.tis.com Mon Feb 22 09:38:44 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA20876; Mon, 22 Feb 1999 09:38:43 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA13375 for ipsec-outgoing; Mon, 22 Feb 1999 09:30:25 -0500 (EST) From: Quaizar Vohra Date: Fri, 19 Feb 1999 17:29:09 -0800 (PST) Message-Id: <199902200129.RAA11332@lookout.nsd.3com.com> To: Richard Draves Cc: mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: (IPng 7211) RE: Last Call: Mobility Support in IPv6 to Proposed Standard In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D55@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8100AF81D55@RED-MSG-50> Sender: owner-ipsec@ex.tis.com Precedence: bulk Rich, > > > I believe that an IPsec-enabled node that is processing a routing header > with non-zero Segments Left should do inbound IPsec processing (SPD lookup & > policy verification) when it gets to the routing header and outbound IPsec > processing before sending the updated packet. This should be just the same > as a security gateway that is forwarding a packet. The routing header should > not make it possible to bypass security policies. I would think that if the intermediate dest (defined per the routing hdr) gets an IP packet, it should not do inbound IPsec processing, as it is not the final dest for the packet, i.e it is not one of the endpoints of the IPSEC session. On the otherhand, if the packet was tunnelled to it then it would make sense to do inbound IPSEC processing. Security gateways only operate on tunnelled packets, destined to it. I agree that it is not the final destination, but is in the sense of the IPSEC session. Yes if the intermediate dest (one of the intermediate IP addresses in the routing header) is a security gateway, it should do the outbound IPSEC processing. > > Carrying forward the analogy with security gateways, the IPsec processing > associated with a routing header should only support tunnel-mode > associations. Otherwise it makes life too difficult for the node processing > the routing header, because it would have to be finding & removing & > inserting headers in strange places. Security gateways must only support > tunnel-mode associations. > > To make this concrete, suppose we have four nodes A, B, C, D. Node A sends a > packet with a routing header through nodes B and C to node D. Node A can > have tunnel and/or transport mode associations with node D, say for example > transport-mode AH. Node A can only have a tunnel mode association with node > B, say for example tunnel-mode ESP. > > The packets sent by node A will look like > IPv6 hdr - dst B, src A > ESP > IPv6 hdr - dst B, src A > Routing hdr, segments left = 2, addrs C, D > AH > Transport hdr > I would assume that each associations are related with some policies, which classify based on some fields in the packet. If node A has an association with D for this particular flow, then I am not sure if it needs to have another policy for the same flow which requires a tunnel mode security association with B and vice versa. A default policy which requires a tunnel mode association for any packets between A and B, should not be applicable either, as B is not the actual destination for this packet. > There might be further tunnel-mode associations between nodes B & C, nodes C > & D but node A won't know about that. > > Note that this means that outbound IPsec processing on node A has to happen > *twice*, first for the final destination node D, and then again for the > first intermediate destination node B. I don't understand why it should happen for the intermediate dest B, unless you have a policy which says that for all packets destined to intermediate destination B, use a tunnel mode association with B. Here your processing of the packet looks like as if it was originated twice, once as destined to D, and then destined to B. To me, it seems better to consider the packet as originated once, destined for D. I am not sure if routing header should be given the same semantic as a tunnelling header, in the IPSEC context. Sorry, if I am way offtrack in my understanding of this debate. Quaizar > > Does this sound reasonable? > > Applying this to the mobility case, there's only one intermediate > destination address and the final destination and the intermediate > destination address happen to both be assigned to the mobile node. > > Suppose the correspondent node has an active transport-mode AH association > for a TCP connection with the mobile node. Then the mobile node wanders off > and acquires a care-of address behind a security gateway. The correspondent > node needs to use tunnel-mode ESP to the security gateway to reach the > care-of address, and then transport-mode AH for the home address. > > This demonstrates the example above: when the correspondent node sends to > the mobile node, it needs to do outbound IPsec processing twice, first for > the home address, then for the care-of address. > > Thanks, > Rich From owner-ipsec@portal.ex.tis.com Mon Feb 22 10:53:22 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21633; Mon, 22 Feb 1999 10:53:22 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA13969 for ipsec-outgoing; Mon, 22 Feb 1999 11:03:26 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199902212234.RAA26683@brill.shiva.com> References: (message from Stephen Kent on Sun, 21 Feb 1999 14:07:42 -0500) Date: Mon, 22 Feb 1999 11:23:51 -0500 To: John Shriver From: Stephen Kent Subject: Re: Bridging non-IP traffic over IPSec Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk John, >Well, in the case where one is running IPX over PPP over L2TP over ESP >over IP, the endpoint of the IP traffic is the security gateway at >each end. Well, this presumes that the security gateway is also going >to rip all the headers off up to the IPX level, and be an IPX router >on the internal networks. So, it is the ultimate endpoint of the _IP_ >traffic. Agreed. In that case, if the IP headers are stripped by the gateway, I have no objection to use of transport mode. >So, by the semantics, we are OK using ESP transport mode. > >Of course, the fact that the the security gateway is not the ultimate >endpoint of the IPX traffic might be viewed as violating the spirit of >RFC 2401. But IPsec deals only with IP traffic, so the IPX destination is outside the scope of what we would know/care about. Steve From owner-ipsec@portal.ex.tis.com Mon Feb 22 10:54:47 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21648; Mon, 22 Feb 1999 10:54:47 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA14044 for ipsec-outgoing; Mon, 22 Feb 1999 11:23:25 -0500 (EST) Date: Mon, 22 Feb 1999 11:43:58 -0500 Message-Id: <199902221643.LAA27119@brill.shiva.com> From: John Shriver To: ebomarsi@xedia.com CC: kent@bbn.com, skelly@redcreek.com, ipsec@tis.com In-reply-to: <36D16764.49543494@xedia.com> (message from Eric Bomarsi on Mon, 22 Feb 1999 09:19:17 -0500) Subject: Re: Bridging non-IP traffic over IPSec Sender: owner-ipsec@ex.tis.com Precedence: bulk From: Eric Bomarsi Subject: Re: Bridging non-IP traffic over IPSec Stephen Kent wrote: > ESP requires the next protocol to be a transport protocol or IP, so > carrying an Ethernet frame directky above ESP would not be valid. What about..... In RFC 1700 the IP protocol numbers include: 97 ETHERIP Ethernet-within-IP Encapsulation [RXH1] Yes, that's another putative encapsulation. It boils down to two basic choices: 1. Something that uses UDP, such as L2TP or PPTP 2. Something that is a Transport Protocol over IP, such as GRE and ETHERIP. At least there's an informational RFC on GRE, which is more than can be said about ETHERIP. (Is Russ Housley still at Xerox, and is he willing to document what he did?) The choice of exactly which protocol to use in each case is, to my mind, just a distraction from the real issues. The real issue is what the headers before these encapsulation headers look like. We have reached a point where we believe it's OK to use ESP in transport mode, so long as the security gateway fully decapsulates the inner protocol. So that helps us on headers. Also, let's note that either of these stacks can bridge or route. With PPP on L2TP or PPTP, you use BCP to bridge. With GRE, you use protocol number 0x6558 for Ethernet bridging. (You presumably use some number Cisco hasn't published for 802 bridging for FDDI or Token-Ring.) Of course, if you were briding in GRE, you would have to expand the header to 8 bytes and include the Sequence Number field, since bridging is defined to require non-reordering of packets. (Another nuisance of bridging.) Using the ESP anti-replay counter for reordering protection would be an unacceptable layer violation. From owner-ipsec@portal.ex.tis.com Mon Feb 22 10:56:48 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21668; Mon, 22 Feb 1999 10:56:48 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA13959 for ipsec-outgoing; Mon, 22 Feb 1999 11:02:25 -0500 (EST) Message-ID: <00b701be5e80$863f9010$634cf526@east.isi.edu> From: "Aaron Griggs" To: Cc: , Subject: Re: (IPng 7212) RE: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Mon, 22 Feb 1999 11:29:30 -0500 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.0810.800 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-ipsec@ex.tis.com Precedence: bulk I think there is some confusion to what we are asking in regards to IPSec and routing headers, Rich correct me if I am wrong. Sorry this is so long, I want to make the example clear. A mobile node is in its home network when it first establishes a security policy with some correspondent node. The security policy in the correspondent node uses the "home address" of the mobile node when communicating. At a later time, the mobile node moves to another location. The correspondent node still communicates with the mobile node using the "home address" until the correspondent node discovers that there is a "care of address." The "care of address" is discovered when the correspondent node receives a packet from the mobile node with the source address set to the "care of address" and the packet contains a "Home Address" destination option. The correspondent node caches the binding. The IPSec headers for this packet could come before or after the destination option. If the IPSec is before the destination option, then there must be an association between the "care of address" and the correspondent node. If the IPSec is after the destination header, the "home address" is used in the policy and no association between the "care of address" and the mobile node exists. The latter case is probably the most likely. Lets take the example of the IPSec headers being after the destination option. When the mobile node sends a packet to the correspondent node, there is probably a security gateway protecting outbound traffic. The security gateway communicates with the correspondent node. Here is a diagram: MobileNode("care of address")---->SG---->Internet---->CorrespondentNode The traffic reaches the correspondent node which parses the packet and creates the "care of address" binding. Then, the end-end IPSec between the mobile node and the correspondent node is handled. Remember, the "home address" is the destination address. It was swapped when doing the binding. Now, the correspondent node sends traffic back to the mobile node. At the transport layer, the "home address" is used for the policy lookup. However if this is a TCP connection, the security association is probably cached in the TCP control block so a lookup is not needed. Before the traffic is actually protected by AH (AH because it covers the entire datagram), a check of the binding is done to see if there is a "care of address." Yes, a "care of address" does exist so the destination IP address is changed to the "care of address" and a routing header created containing the "home address." Of course, the routing header and the destination IP address are mutable but predictable. The actual authentication is done on the predicted value. This is one reason AH is so "fun" to implement and will cost in performance. Before the traffic is sent, a policy lookup is performed to see if the traffic is protected by IPSec. If a second policy lookup is not performed, the traffic is dropped when it reaches the security gateway. So in this case, it is necessary for the correspondent node to do a second lookup. Unless of course, the security gateway looks at the routing header and allows the packet to be forwarded to the mobile node. But this means the traffic bypasses security at the security gateway. I doubt this is an option. Aaron Original Message ----- From: Quaizar Vohra To: Richard Draves Cc: ; ; Sent: Friday, February 19, 1999 8:29 PM Subject: (IPng 7212) RE: Last Call: Mobility Support in IPv6 to Proposed Standard > > >Rich, > > >> >> >> I believe that an IPsec-enabled node that is processing a routing header >> with non-zero Segments Left should do inbound IPsec processing (SPD lookup & >> policy verification) when it gets to the routing header and outbound IPsec >> processing before sending the updated packet. This should be just the same >> as a security gateway that is forwarding a packet. The routing header should >> not make it possible to bypass security policies. > >I would think that if the intermediate dest (defined per the routing >hdr) gets an IP packet, it should not do inbound IPsec processing, as >it is not the final dest for the packet, i.e it is not one of the >endpoints of the IPSEC session. On the otherhand, if the packet was >tunnelled to it then it would make sense to do inbound IPSEC >processing. > >Security gateways only operate on tunnelled packets, destined to it. >I agree that it is not the final destination, but is in the sense >of the IPSEC session. > >Yes if the intermediate dest (one of the intermediate IP addresses in >the routing header) is a security gateway, it should do the outbound >IPSEC processing. > >> >> Carrying forward the analogy with security gateways, the IPsec processing >> associated with a routing header should only support tunnel-mode >> associations. Otherwise it makes life too difficult for the node processing >> the routing header, because it would have to be finding & removing & >> inserting headers in strange places. Security gateways must only support >> tunnel-mode associations. >> >> To make this concrete, suppose we have four nodes A, B, C, D. Node A sends a >> packet with a routing header through nodes B and C to node D. Node A can >> have tunnel and/or transport mode associations with node D, say for example >> transport-mode AH. Node A can only have a tunnel mode association with node >> B, say for example tunnel-mode ESP. >> >> The packets sent by node A will look like >> IPv6 hdr - dst B, src A >> ESP >> IPv6 hdr - dst B, src A >> Routing hdr, segments left = 2, addrs C, D >> AH >> Transport hdr >> > >I would assume that each associations are related with some policies, >which classify based on some fields in the packet. > >If node A has an association with D for this particular flow, then I >am not sure if it needs to have another policy for the same flow >which requires a tunnel mode security association with B and vice versa. > >A default policy which requires a tunnel mode association for any >packets between A and B, should not be applicable either, as B is not >the actual destination for this packet. > > >> There might be further tunnel-mode associations between nodes B & C, nodes C >> & D but node A won't know about that. >> >> Note that this means that outbound IPsec processing on node A has to happen >> *twice*, first for the final destination node D, and then again for the >> first intermediate destination node B. > >I don't understand why it should happen for the intermediate dest B, unless >you have a policy which says that for all packets destined to intermediate >destination B, use a tunnel mode association with B. > >Here your processing of the packet looks like as if it was originated >twice, once as destined to D, and then destined to B. To me, it seems >better to consider the packet as originated once, destined for D. > >I am not sure if routing header should be given the same semantic as >a tunnelling header, in the IPSEC context. > >Sorry, if I am way offtrack in my understanding of this debate. > >Quaizar > >> >> Does this sound reasonable? >> >> Applying this to the mobility case, there's only one intermediate >> destination address and the final destination and the intermediate >> destination address happen to both be assigned to the mobile node. >> >> Suppose the correspondent node has an active transport-mode AH association >> for a TCP connection with the mobile node. Then the mobile node wanders off >> and acquires a care-of address behind a security gateway. The correspondent >> node needs to use tunnel-mode ESP to the security gateway to reach the >> care-of address, and then transport-mode AH for the home address. >> >> This demonstrates the example above: when the correspondent node sends to >> the mobile node, it needs to do outbound IPsec processing twice, first for >> the home address, then for the care-of address. >> >> Thanks, >> Rich >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > From owner-ipsec@portal.ex.tis.com Mon Feb 22 11:08:15 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA21754; Mon, 22 Feb 1999 11:08:14 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA14094 for ipsec-outgoing; Mon, 22 Feb 1999 11:36:25 -0500 (EST) Date: Mon, 22 Feb 1999 11:57:43 -0500 Message-Id: <199902221657.LAA27122@brill.shiva.com> From: John Shriver To: ebomarsi@xedia.com CC: skelly@redcreek.com, ipsec@tis.com In-reply-to: <36D15EC3.38AEDC9A@xedia.com> (message from Eric Bomarsi on Mon, 22 Feb 1999 08:42:27 -0500) Subject: Re: Bridging non-IP traffic over IPSec Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Mon, 22 Feb 1999 08:42:27 -0500 From: Eric Bomarsi To: "Scott G. Kelly" Cc: John Shriver , ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec Use of ESP transport mode is for traffic destined to the end system and tunnel mode is for traffic to be forwarded by a gateway. I think we've already sorted out that we can use transport mode. More importantly, it comes back to configuration and management. Look at it from your customer's persective. An ISP wants to configure, monitor and bill on an IPSec tunnel it has created for a company between 2 sites. It defines a security policy, specifies the routes to direct traffic into the tunnel, and configures a monitor to watch the tunnelled traffic between sites. What exactly does it mean for the ISP to configure, monitor, and bill an IPSec tunnel? Will the tunnel start at their premises, not yours? That doesn't protect the traffic on the link between you and the ISP, if you want security, I presume that you want it _secure_. Or will the ISP own the customer-premises router, and configure the SPD for you there? Now there's a need to handle a small fraction of non-IP traffic so our answer is to configure another security policy, establish another IKE session, possibly burn more addresses with a GRE tunnel, configure another monitor and sum the traffic stats. As I read sections 4.4.1 & 4.4.2 of RFC 2401, the SPD is (potentially) very fine-grained. They will have to add another policy to allow this tunnel. It will NOT be another IKE session. Just another SA Bundle in the existing IKE session that exists for the IP traffic. Unless you're using PFS, there isn't even another Diffie-Hellman. Yes, it is a solution, but the customers aren't going to buy it, and I don't blame them. Just put the bridged traffic through the existing tunnel. I think that you average customer probably really does not want to bridge the native windows NETBIOS networking between sites. (How slow do you want Network Neighborhood to be?) Also, if you're paying for QOS under your ESP header, you really don't want to fill up that pricey bandwidth with the "noise" of bridging, such as NETBIOS datagrams, which are all broadcasts on Ethernet... It really doesn't matter whether the tunnel is bridged, routed, or routed over a bridging encapsulation. There simply is more configuration for a multi-protocol bridge/router than for an IP-only router. This burden isn't any different when the connection is over an IP tunnel, or when it's over a leased line. BTW, you do need the redundant IP header with GRE inside an IPSec tunnel. A standard GRE tunnel downlinks to IP and uplinks to a bridge, and knows nothing about IPSec and vice versa. Using ESP protocol of GRE would not work with existing GRE equipment. GRE does not have such a restriction. Both ends can be routers. (Are you possibly thinking of 3Com's old Boundary Routing?) Since we're going to allow GRE over ESP in transport mode, no new IP addresses are needed for the tunnel. You still need a network number for IPX over GRE (in routing mode), but that's something IPXWAN could address. But you would also need a network number for a leased line. No difference! Again, using L2TP instead of GRE allows PPP to automate a lot more of the network-layer configuration. There is more per-packet overhead, however, no free lunch. /Eric Bomarsi From owner-ipsec@portal.ex.tis.com Mon Feb 22 11:36:32 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA21974; Mon, 22 Feb 1999 11:36:31 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA14161 for ipsec-outgoing; Mon, 22 Feb 1999 12:01:24 -0500 (EST) Message-ID: <36D1925E.94EF3D36@redcreek.com> Date: Mon, 22 Feb 1999 09:22:38 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Sumit A. Vakil" CC: ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec References: <001801be5c75$933b0400$8eec10ac@pc-svakil.internetdevices.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk "Sumit A. Vakil" wrote: > > > It's been quite a while since I looked at the L2TP draft, but I'm under > > the strong impression that it's not a UDP protocol. There may be a UDP > > control channel associated with it, but I think the protocol itself > > operates at layer 2. I know we have at least a few l2tp experts lurking > > here - perhaps they will enlighten us. > > L2TP runs over UDP (both data and control channels) in IP networks. It can > run directly over a layer 2 protocol like ATM. I think that there's an L2TP > over ATM/FR draft somewhere. > Thanks for the clarification - I bet knowledgeable l2tp folks could probably infer the last revision of the l2tp draft that I read from this exchange :-) > Actually, Schneier makes it very clear that its not PPTP, but the > implementation of PPTP they analyzed that is broken. Check out his FAQ on > the topic at http://www.counterpane.com/pptp-faq.html. Right, but who else is seriously implementing PPTP, when it's not on any standards track? From owner-ipsec@portal.ex.tis.com Mon Feb 22 11:55:53 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22185; Mon, 22 Feb 1999 11:55:52 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA14267 for ipsec-outgoing; Mon, 22 Feb 1999 12:21:25 -0500 (EST) Message-ID: <36D1972F.F36F3EA1@redcreek.com> Date: Mon, 22 Feb 1999 09:43:11 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: John Shriver CC: ebomarsi@xedia.com, ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec References: <199902221657.LAA27122@brill.shiva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk John Shriver wrote: > Again, using L2TP instead of GRE allows PPP to automate a lot more of > the network-layer configuration. There is more per-packet overhead, > however, no free lunch. Yes, I think this is really what it boils down to. I guess my question at this point is this: exactly what configuration do we want to to using that l2tp that we can't do using gre? From owner-ipsec@portal.ex.tis.com Mon Feb 22 11:56:53 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22196; Mon, 22 Feb 1999 11:56:52 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA14302 for ipsec-outgoing; Mon, 22 Feb 1999 12:26:24 -0500 (EST) From: "Sumit A. Vakil" To: Subject: RE: Bridging non-IP traffic over IPSec Date: Mon, 22 Feb 1999 09:50:54 -0800 Message-ID: <000101be5e8b$e4de6dc0$8eec10ac@pc-svakil.internetdevices.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3.0.5.32.19990220220754.007b5320@world.std.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk > Please be aware that this FAQ does not go nearly far enough > in condemning PPTP. MS-PPTP is just one particularly weak > version of challenge-hashed-response authentication for > passwords (CHRAP), in which, according to the FAQ: > > "Passwords are protected by hash functions > so badly that most can be easily recovered." > > What the FAQ neglects to say, however, is that even a "good" > implementation of PPTP, like all similar methods based on > purely symmetric ciphers or hash functions, necessarily > exposes *lots* of user passwords to brute-force network attack. > In my view, this is completely unacceptable. I agree that any PAP or CHAP like authentication scheme is weak. But PAP and CHAP are PPP protocols and not PPTP. PPP's EAP, through the use of auth schemes other than PAP/CHAP, provides for stronger authentication. Sumit > > Given the *many* stronger alternatives today, with IPSEC as > merely one example, there is just no good excuse to use PPTP > or any similar CHRAP over an otherwise insecure network. > > ------------------------- > David P. Jablon > Integrity Sciences, Inc. > dpj@world.std.com > > > From owner-ipsec@portal.ex.tis.com Mon Feb 22 11:59:15 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22239; Mon, 22 Feb 1999 11:59:15 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA14224 for ipsec-outgoing; Mon, 22 Feb 1999 12:15:25 -0500 (EST) Message-ID: <36D195C0.A33D18AC@redcreek.com> Date: Mon, 22 Feb 1999 09:37:04 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: John Shriver CC: dpj@world.std.com, svakil@internetdevices.com, ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec References: <199902212237.RAA26685@brill.shiva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk John Shriver wrote: > > Let's not be distracted bashing the "security" problems of PPTP. Yes, > without IPSec, it's a joke security wise. But nobody is even going to > know if it even _IS_ PPTP if it's inside ESP. > > This discussion is about how to tunnel non-IP traffic over IPSec (see > the subject), not bashing Microsoft. I don't think anyone meant to get off on a m$-bashing track. The original comment I made was meant to counter the notion that pptp would be the defacto standard. The fact that it is not a standard (and not on any sort of standard track) should be enough to persuade one that it is not bound for defacto-standard-hood. > While PPTP is not a well-loved protocol for many reasons, for the > purposes of this discussion it's semantically (if not > standards-track-ly) equivalent to L2TP. While you could probably conjure up an argument regarding functional equivalence, pptp is *not* equivalent to l2tp in terms of standards. L2tp is on the standards track, and is far superior to pptp. The real question, the one we're actually concerned with here, is this: We have a need to tunnel non-IP traffic between private networks using the public internet; should we use pptp, l2tp, gre, or some other mechanism to accomplish this? I submit that pptp is not really an alternative, given the reasons above. I suggested earlier that l2tp might be overkill for this application, given all the overhead that goes with it, and wondered if we shouldn't be reviving GRE for this application. There are probably good arguments for both points of view (l2tp vs gre), and there may even be a third or fourth alternative which makes more sense. This should be the thrust of our discussion. From owner-ipsec@portal.ex.tis.com Mon Feb 22 14:27:15 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA23612; Mon, 22 Feb 1999 14:27:14 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA14842 for ipsec-outgoing; Mon, 22 Feb 1999 14:25:28 -0500 (EST) Date: Mon, 22 Feb 1999 14:45:47 -0500 Message-Id: <199902221945.OAA27930@brill.shiva.com> From: John Shriver To: skelly@redcreek.com CC: dpj@world.std.com, svakil@internetdevices.com, ipsec@tis.com In-reply-to: <36D195C0.A33D18AC@redcreek.com> (skelly@redcreek.com) Subject: Re: Bridging non-IP traffic over IPSec Sender: owner-ipsec@ex.tis.com Precedence: bulk The only point about "de-facto" on PPTP is that it may be the only way Windows 2000 clients will do IPX VPN IPSec over remote access. (Unless Microsoft adds L2TP to Windows 2000.) Also, if you put IPSec under Windows 95/98 DUN 1.3, PPTP is free. This may make the point that "PPP is too much baggage" VERY moot. (It's up to the market to decide if they want to install a third-party L2TP or GRE on Windows 2000, or use PPTP.) I certainly see GRE as the lightest-weight solution. Certainly the lowest byte overhead. The configuration cost may be higher than L2TP, due to the absence of PPP negotiation. But, it may well be up to Cisco to cede revision control over GRE to the IETF/IANA. The things that PPP (over L2TP or PPTP) can negotiate for us are network layer addressing for IPX and AppleTalk. In particular, IPXCP can be setup to use IPXWAN to negotiate network numbers. The nodes have pools of network numbers, and hand one out for each connection. Also, IPXCP can do some smart header compression for us. It's smart enough that the advantages won't be lost with IPCOMP. We need to remember that there are two problem spaces. One is routing IPX (or briding) over a tunnel between security gateways. There we have an decision-making impact. The other is connection from a Windows 95/89/2000 IPX client to a security gateway. There, I think the decision may already be made. For the inter-security-gateway connection, GRE is less overhead, more configuration. L2TP is more overhead, less configuration. From owner-ipsec@portal.ex.tis.com Mon Feb 22 15:04:12 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA23973; Mon, 22 Feb 1999 15:04:11 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA15055 for ipsec-outgoing; Mon, 22 Feb 1999 15:16:30 -0500 (EST) Message-ID: <976F7C55E3B2D111A0720008C728549CE94D8A@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: John Shriver , "'Scott G. Kelly'" Cc: dpj@world.std.com, svakil@internetdevices.com, ipsec@tis.com Subject: RE: Bridging non-IP traffic over IPSec Date: Mon, 22 Feb 1999 19:56:18 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk > The real question, the one we're actually concerned with here, is this: > We have a need to tunnel non-IP traffic between private networks using > the public internet; should we use pptp, l2tp, gre, or some other > mechanism to accomplish this? I submit that pptp is not really an > alternative, given the reasons above. I suggested earlier that l2tp > might be overkill for this application, given all the overhead that goes > with it, and wondered if we shouldn't be reviving GRE for this > application. There are probably good arguments for both points of view > (l2tp vs gre), and there may even be a third or fourth alternative which > makes more sense. This should be the thrust of our discussion. > Mobile IP and the Tunnel Establishment Protocol (TEP) use GRE for multiprotocol support. Mobile IP is a proposed standard, TEP is a draft submitted to the MIP WG and it is a WG document. So there is a couple of protocols (actually sharing most of the messages and of the code) which are going to use GRE as the mechanism you are talking about. Alessio > ----------------- > > Alessio Casati > GSM/UMTS Advanced Development, Swindon,UK > http://www.lucent.com/wirelessnet > > <<...>> > From owner-ipsec@portal.ex.tis.com Mon Feb 22 15:23:44 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA24178; Mon, 22 Feb 1999 15:23:43 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA15319 for ipsec-outgoing; Mon, 22 Feb 1999 15:54:30 -0500 (EST) Message-Id: <199902222114.NAA21061@potassium.network-alchemy.com> To: John Shriver cc: skelly@redcreek.com, dpj@world.std.com, svakil@internetdevices.com, ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec In-reply-to: Your message of "Mon, 22 Feb 1999 14:45:47 EST." <199902221945.OAA27930@brill.shiva.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21058.919718095.1@network-alchemy.com> Date: Mon, 22 Feb 1999 13:14:55 -0800 From: Dan Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk It's already in the Win00 beta. The last bakeoff was a joint IPSec and L2TP bakeoff. The groups pretty much kept to themselves but there were a few vendors who did both (and did both together). Microsoft was one. I understand that the plan is to have both IPSec and L2TP in Win00. Things could change though. Or worse, we could get MS-L2TP and/or MS-IPSec. Dan. On Mon, 22 Feb 1999 14:45:47 EST you wrote > The only point about "de-facto" on PPTP is that it may be the only way > Windows 2000 clients will do IPX VPN IPSec over remote access. > (Unless Microsoft adds L2TP to Windows 2000.) Also, if you put IPSec > under Windows 95/98 DUN 1.3, PPTP is free. This may make the point > that "PPP is too much baggage" VERY moot. (It's up to the market to > decide if they want to install a third-party L2TP or GRE on Windows > 2000, or use PPTP.) From owner-ipsec@portal.ex.tis.com Mon Feb 22 15:30:38 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA24215; Mon, 22 Feb 1999 15:30:38 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA15381 for ipsec-outgoing; Mon, 22 Feb 1999 16:14:29 -0500 (EST) Date: Mon, 22 Feb 1999 16:35:13 -0500 Message-Id: <199902222135.QAA28027@brill.shiva.com> From: John Shriver To: dharkins@network-alchemy.com CC: skelly@redcreek.com, dpj@world.std.com, svakil@internetdevices.com, ipsec@tis.com In-reply-to: <199902222114.NAA21061@potassium.network-alchemy.com> (message from Dan Harkins on Mon, 22 Feb 1999 13:14:55 -0800) Subject: Re: Bridging non-IP traffic over IPSec Sender: owner-ipsec@ex.tis.com Precedence: bulk Well, if L2TP will be in Windows 2000, that means that anyone who wants to support mobile multiprotocol IPSec clients can do PPP, L2TP, ESP, and the appropriate PPP NCP's. It's all standards-track. I'm not sure if a different solution for inter-security-gateway connections is called for? Can vendors of that solution ignore Windows 2000, and not implement PPP/L2TP? On the other hand, the larger header overhead of L2TP/UDP makes the fragmentation mess worse, and with IPX you can't prevent fragmentation in the intra-security-gateway configuration. GRE does address that. That's a very real advantage to GRE. Well, it's also a lot simpler to implement than PPP/L2TP. Another approach to fixing the L2TP overhead issue would be to resume the efforts to get a IP Protocol Number that can be used for the L2TP data channel. It was an area that got attention before, but then was abandoned due to arguing that L2TP wasn't a general-purpose enough protocol to deserve an IP Protocol Number. If it becomes important enough in the IPSec arena, that restriction may no longer hold. Let's remember that PPP NCP option negotiation is a real operational benefit. From owner-ipsec@portal.ex.tis.com Mon Feb 22 16:04:09 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA24495; Mon, 22 Feb 1999 16:04:09 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA15490 for ipsec-outgoing; Mon, 22 Feb 1999 16:39:28 -0500 (EST) Message-ID: <3C3175FCC945D211B65100805F158089E905EE@RED-MSG-07> From: Chun Ye To: "'John Shriver'" Cc: ipsec@tis.com Subject: RE: Bridging non-IP traffic over IPSec Date: Mon, 22 Feb 1999 14:00:30 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk L2TP and IPSec are both in Windows 2000. --Chun -----Original Message----- From: John Shriver [mailto:jas@shiva.com] Sent: Monday, February 22, 1999 11:46 AM To: skelly@redcreek.com Cc: dpj@world.std.com; svakil@internetdevices.com; ipsec@tis.com Subject: Re: Bridging non-IP traffic over IPSec The only point about "de-facto" on PPTP is that it may be the only way Windows 2000 clients will do IPX VPN IPSec over remote access. (Unless Microsoft adds L2TP to Windows 2000.) Also, if you put IPSec under Windows 95/98 DUN 1.3, PPTP is free. This may make the point that "PPP is too much baggage" VERY moot. (It's up to the market to decide if they want to install a third-party L2TP or GRE on Windows 2000, or use PPTP.) I certainly see GRE as the lightest-weight solution. Certainly the lowest byte overhead. The configuration cost may be higher than L2TP, due to the absence of PPP negotiation. But, it may well be up to Cisco to cede revision control over GRE to the IETF/IANA. The things that PPP (over L2TP or PPTP) can negotiate for us are network layer addressing for IPX and AppleTalk. In particular, IPXCP can be setup to use IPXWAN to negotiate network numbers. The nodes have pools of network numbers, and hand one out for each connection. Also, IPXCP can do some smart header compression for us. It's smart enough that the advantages won't be lost with IPCOMP. We need to remember that there are two problem spaces. One is routing IPX (or briding) over a tunnel between security gateways. There we have an decision-making impact. The other is connection from a Windows 95/89/2000 IPX client to a security gateway. There, I think the decision may already be made. For the inter-security-gateway connection, GRE is less overhead, more configuration. L2TP is more overhead, less configuration. From owner-ipsec@portal.ex.tis.com Mon Feb 22 16:26:59 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA24740; Mon, 22 Feb 1999 16:26:59 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA15549 for ipsec-outgoing; Mon, 22 Feb 1999 17:04:26 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <36D16764.49543494@xedia.com> References: <199902182244.RAA24979@brill.shiva.com> <36CCBCED.A7B5FA62@redcreek.com> Date: Mon, 22 Feb 1999 17:27:20 -0500 To: Eric Bomarsi From: Stephen Kent Subject: Re: Bridging non-IP traffic over IPSec Cc: "Scott G. Kelly" , John Shriver , ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Eric, Well, I have to admit that I was not familair with protocol number 97. However, that does not change the fact that ESP requires either IP or a transport protocol. Just because you got a protocol number assigned for use in the IP next protocol field, doesn't make it appropriate to use here. We have a number of examples of such protocols, many experimental, etc. Steve From owner-ipsec@portal.ex.tis.com Mon Feb 22 20:36:37 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA09367; Mon, 22 Feb 1999 20:36:36 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA16158 for ipsec-outgoing; Mon, 22 Feb 1999 20:53:30 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D8C@RED-MSG-50> From: Richard Draves To: "'Quaizar Vohra'" Cc: mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: RE: (IPng 7211) RE: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Mon, 22 Feb 1999 18:14:36 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk > I would think that if the intermediate dest (defined per the routing > hdr) gets an IP packet, it should not do inbound IPsec processing, as > it is not the final dest for the packet, i.e it is not one of the > endpoints of the IPSEC session. On the otherhand, if the packet was > tunnelled to it then it would make sense to do inbound IPSEC > processing. See example below arguing that inbound IPsec processing should be required for intermediate destinations. > Security gateways only operate on tunnelled packets, destined to it. > I agree that it is not the final destination, but is in the sense > of the IPSEC session. > > Yes if the intermediate dest (one of the intermediate IP addresses in > the routing header) is a security gateway, it should do the outbound > IPSEC processing. There are two approaches to my questions about the interaction of routing headers and IPsec - the first is to think generically about routing headers, and the second is to think specifically about mobility scenarios. The mobility scenarios are good because they are very concrete, but they use the routing header in a very stylized way. In a later message I'll examine some more mobility scenarios. To get back to this particular thread, which is about more generic routing header scenarios: I don't understand how it can be legitimate for an IPsec-enabled node that is receiving a packet with a routing header to bypass inbound IPsec processing. A very concrete, simple example: consider a node SG. SG has two interfaces, an interface to the public network and an interface on a private network. Node A is on the public network and node B is on the private network. The SPD on SG requires all traffic through it to & from the public network to be protected with tunnel-mode ESP. This is a classic security gateway scenario. So in the normal case when node A sends a packet to node B, it will look like IPv6 hdr - src A, dst SG ESP IPv6 hdr - src A, dst B Transport hdr This packet will arrive at SG. The outer IPv6 header will be processed. The ESP header will be processed. The inner IPv6 header will be processed and SG will realize it needs to forward the packet. It will do an inbound SPD lookup and verify that the packet was protected with the appopriate tunnel-mode ESP security association, which it was. Then it will do outbound SPD processing, which will find a policy allowing the packet to be sent without further protection, and it will send the packet as IPv6 hdr - src A, dst B Transport hdr That's all well and good and I hope we are in agreement so far. Now suppose SG receives a packet that looks like IPv6 hdr - src A, dst SG Routing hdr - segs left = 1, B Transport hdr Now you are saying that SG should not perform any inbound IPsec processing?!? This would mean that SG will send the packet on to B without having verified that it was properly protected, bypassing the intended security policy. Rich From owner-ipsec@portal.ex.tis.com Mon Feb 22 22:07:06 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA15743; Mon, 22 Feb 1999 22:07:05 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id WAA16473 for ipsec-outgoing; Mon, 22 Feb 1999 22:45:31 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D91@RED-MSG-50> From: Richard Draves To: "'Quaizar Vohra'" Cc: mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: RE: (IPng 7222) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Mon, 22 Feb 1999 20:06:41 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk > I am sorry I was unclear in my last mail. When I said that SG will not > do inbound IPSEC processing, I did not mean that it will not check its > policies to see if the packet should have come encrypted to it > If it has such a policy, it should drop the packet. > > Eric already clarified this. > > The intention of my previous mail was to say that the presence > of source routing header in a packet should not change the IPSEC > behavior either at the inbound or outbound. While a routing > header might be considered as part of policy lookup, if an > implementation allowed defining IPsec policies filtering on > intermediate destination. I'm trying to keep things "simple" and not even consider policies that filter on routing headers. So are we in agreement that an IPsec-enabled node that is processing a routing header should do inbound & outbound IPsec processing, much like a security gateway that is forwarding a packet? Then I don't understand the point you are trying to make. One thought that occurs to me: to revisit the example of a node SG that receives a packet IPv6 hdr - src A, dst SG Routing hdr - segs left = 1, B Transport hdr When node SG is doing its inbound SPD lookup, what selectors should it use? Should the destination address selector be SG or B? In my first email on this subject I argued for SG, but now I'm thinking perhaps the destination address selector in inbound processing should be B (the destination address after routing header processing). Thanks, Rich From owner-ipsec@portal.ex.tis.com Mon Feb 22 23:06:34 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA18450; Mon, 22 Feb 1999 23:06:33 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA16581 for ipsec-outgoing; Mon, 22 Feb 1999 23:36:30 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D94@RED-MSG-50> From: Richard Draves To: "'Quaizar Vohra'" Cc: mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: RE: (IPng 7222) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Mon, 22 Feb 1999 20:57:39 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk > The point I was trying to make in my first mail, was that if A > is communicating with D via B and C, the resulting packet > looks like > > IPv6 hdr - src A, dst B > Routing hdr - segs left = 1, C, D > Transport hdr [I think you mean segs left = 2 in this example.] > Then it does IPSEC processing. Depending on the policy (irrespective > of how detailed the selector list) lookup, chooses a policy, which > directs it to either do tunnel mode IPsec with an SG or transport > mode IPSEC with D. > > In the 1st case, the packet will look like : > > IPv6 hdr - src A, dst SG > ESP Tunnel mode with SG > IPv6 hdr - src A, dst B > Routing hdr - segs left = 1, C, D > Transport hdr > > In the later case, it will be > > IPv6 hdr - src A, dst B > ESP transport mode with D > Routing hdr - segs left = 1, C, D > Transport hdr Surely you mean IPv6 hdr - src A, dst B Routing hdr - segs left = 2, C, D ESP transport mode with D Transport hdr ? > The secure gateway processes the 1st case by doing inbound IPSEC, > processing the ESP header. Next it processes the routing header > and forwards the packet to C. > > In the 2nd case, if SG had an IPSEC policy that expected anything > received on the interface this packet is received as ESP tunnelled, > then it would drop the packet. > > All I was trying to say is that a routing header should not mean that > IPSEC outbound processing be done twice, one with selector D, and next > with selector B. IPsec processing should be done once, with both B and > D as part of selectors. Or only D, if selectors containing > intermediate > dests are not supported. Consider the following scenario. Nodes A and C are on a public network. Their security policies let them communicate without a security association. Node B is on a private network, connected to the public network by a security gateway SG. The security policies on SG mandate that any traffic between the two networks must be protected with tunnel-mode ESP on the public side. Now for some reason, node A wants to send a packet to C with a routing header that will take the packet from A to B to C. The packet will need to look like: IPv6 hdr - src A, dst SG ESP tunnel mode, association A -> SG IPv6 hdr - src A, dst B Routing hdr - segs left = 1, C Transport hdr When this packet arrives at B, it will look like IPv6 hdr - src A, dst B Routing hdr - segs left = 1, C Transport hdr Node B will process the routing header and send this packet: IPv6 hdr - src A, dst C Routing hdr - segs left = 0, B Transport hdr The packet will get to SG again because SG is the router between B and C. SG will send the following packet: IPv6 hdr - src SG, dst C ESP tunnel mode, association SG -> C IPv6 hdr - src A, dst C Routing hdr - segs left = 0, B Transport hdr How does all that sound? Now go back to the packet sent by A. How will it know to do the tunnel-mode ESP to SG? It will need to do outbound IPsec processing with a destination address selector of B, and pick out the security association with SG. > So when a mobile node moves beyond a SG, how does a correspondent know > that and hence configures a policy to do IPSEC tunnel mode with SG ? > Rather, I would assume that such SGs who expect mobile nodes to enter > their domain, would have policies which would allow traffic which is > IPSECed (by the presence of IPSEC headers) but not destined for them. If a mobile node moves beyond a SG, then a correspondent can know that because the correspondent will learn a care-of address for the mobile and the correspondent can have a security policy that tells it how to send to the care-of address. Thanks, Rich From owner-ipsec@portal.ex.tis.com Tue Feb 23 08:05:39 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01702; Tue, 23 Feb 1999 08:05:38 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18099 for ipsec-outgoing; Tue, 23 Feb 1999 08:10:32 -0500 (EST) From: Quaizar Vohra Date: Mon, 22 Feb 1999 19:45:33 -0800 (PST) Message-Id: <199902230345.TAA00668@lookout.nsd.3com.com> To: Richard Draves Cc: "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: (IPng 7222) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D8C@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8100AF81D8C@RED-MSG-50> Sender: owner-ipsec@ex.tis.com Precedence: bulk Richard Draves writes: > > I would think that if the intermediate dest (defined per the routing > > hdr) gets an IP packet, it should not do inbound IPsec processing, as > > it is not the final dest for the packet, i.e it is not one of the > > endpoints of the IPSEC session. On the otherhand, if the packet was > > tunnelled to it then it would make sense to do inbound IPSEC > > processing. > > See example below arguing that inbound IPsec processing should be required > for intermediate destinations. > > > Security gateways only operate on tunnelled packets, destined to it. > > I agree that it is not the final destination, but is in the sense > > of the IPSEC session. > > > > Yes if the intermediate dest (one of the intermediate IP addresses in > > the routing header) is a security gateway, it should do the outbound > > IPSEC processing. > > There are two approaches to my questions about the interaction of routing > headers and IPsec - the first is to think generically about routing headers, > and the second is to think specifically about mobility scenarios. The > mobility scenarios are good because they are very concrete, but they use the > routing header in a very stylized way. > > In a later message I'll examine some more mobility scenarios. To get back to > this particular thread, which is about more generic routing header > scenarios: > > I don't understand how it can be legitimate for an IPsec-enabled node that > is receiving a packet with a routing header to bypass inbound IPsec > processing. > > A very concrete, simple example: consider a node SG. SG has two interfaces, > an interface to the public network and an interface on a private network. > Node A is on the public network and node B is on the private network. The > SPD on SG requires all traffic through it to & from the public network to be > protected with tunnel-mode ESP. This is a classic security gateway scenario. > So in the normal case when node A sends a packet to node B, it will look > like > IPv6 hdr - src A, dst SG > ESP > IPv6 hdr - src A, dst B > Transport hdr > > This packet will arrive at SG. The outer IPv6 header will be processed. The > ESP header will be processed. The inner IPv6 header will be processed and SG > will realize it needs to forward the packet. It will do an inbound SPD > lookup and verify that the packet was protected with the appopriate > tunnel-mode ESP security association, which it was. Then it will do outbound > SPD processing, which will find a policy allowing the packet to be sent > without further protection, and it will send the packet as > IPv6 hdr - src A, dst B > Transport hdr > > That's all well and good and I hope we are in agreement so far. > Now suppose SG receives a packet that looks like > IPv6 hdr - src A, dst SG > Routing hdr - segs left = 1, B > Transport hdr > > Now you are saying that SG should not perform any inbound IPsec > processing?!? This would mean that SG will send the packet on to B without > having verified that it was properly protected, bypassing the intended > security policy. > I am sorry I was unclear in my last mail. When I said that SG will not do inbound IPSEC processing, I did not mean that it will not check its policies to see if the packet should have come encrypted to it If it has such a policy, it should drop the packet. Eric already clarified this. The intention of my previous mail was to say that the presence of source routing header in a packet should not change the IPSEC behavior either at the inbound or outbound. While a routing header might be considered as part of policy lookup, if an implementation allowed defining IPsec policies filtering on intermediate destination. Quaizar From owner-ipsec@portal.ex.tis.com Tue Feb 23 08:06:35 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01718; Tue, 23 Feb 1999 08:06:34 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18072 for ipsec-outgoing; Tue, 23 Feb 1999 08:05:28 -0500 (EST) Date: Mon, 22 Feb 1999 18:33:35 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: (IPng 7221) Re: Last Call: Mobility Support in IPv6 to Proposed Standard To: Aaron Griggs Cc: ipng@sunroof.eng.Sun.COM, mobile-ip@smallworks.com, ipsec@tis.com In-Reply-To: "Your message with ID" <00b701be5e80$863f9010$634cf526@east.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk A small clarification: > The "care of address" is discovered when the correspondent node receives a > packet from the mobile node with the source address set to the "care of > address" and the packet contains a "Home Address" destination option. The > correspondent node caches the binding. The binding is only cached when the packet contains both a "binding update" destination option and a "home address" destination option. And the packet must include "either an AH or ESP header providing sender authentication, data integrity protection, and replay protection." Erik From owner-ipsec@portal.ex.tis.com Tue Feb 23 08:08:40 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01734; Tue, 23 Feb 1999 08:08:40 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18192 for ipsec-outgoing; Tue, 23 Feb 1999 08:12:29 -0500 (EST) From: Quaizar Vohra Date: Mon, 22 Feb 1999 21:55:05 -0800 (PST) Message-Id: <199902230555.VAA00754@lookout.nsd.3com.com> To: Richard Draves Cc: "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: RE: (IPng 7222) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D94@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8100AF81D94@RED-MSG-50> Sender: owner-ipsec@ex.tis.com Precedence: bulk > > The point I was trying to make in my first mail, was that if A > > is communicating with D via B and C, the resulting packet > > looks like > > > > IPv6 hdr - src A, dst B > > Routing hdr - segs left = 1, C, D > > Transport hdr > > [I think you mean segs left = 2 in this example.] You are right. > > > Then it does IPSEC processing. Depending on the policy (irrespective > > of how detailed the selector list) lookup, chooses a policy, which > > directs it to either do tunnel mode IPsec with an SG or transport > > mode IPSEC with D. > > > > In the 1st case, the packet will look like : > > > > IPv6 hdr - src A, dst SG > > ESP Tunnel mode with SG > > IPv6 hdr - src A, dst B > > Routing hdr - segs left = 1, C, D > > Transport hdr > > > > In the later case, it will be > > > > IPv6 hdr - src A, dst B > > ESP transport mode with D > > Routing hdr - segs left = 1, C, D > > Transport hdr > > Surely you mean > IPv6 hdr - src A, dst B > Routing hdr - segs left = 2, C, D > ESP transport mode with D > Transport hdr > ? You are right. > > > The secure gateway processes the 1st case by doing inbound IPSEC, > > processing the ESP header. Next it processes the routing header > > and forwards the packet to C. > > > > In the 2nd case, if SG had an IPSEC policy that expected anything > > received on the interface this packet is received as ESP tunnelled, > > then it would drop the packet. > > > > All I was trying to say is that a routing header should not mean that > > IPSEC outbound processing be done twice, one with selector D, and next > > with selector B. IPsec processing should be done once, with both B and > > D as part of selectors. Or only D, if selectors containing > > intermediate > > dests are not supported. > > Consider the following scenario. Nodes A and C are on a public network. > Their security policies let them communicate without a security association. > Node B is on a private network, connected to the public network by a > security gateway SG. The security policies on SG mandate that any traffic > between the two networks must be protected with tunnel-mode ESP on the > public side. > > Now for some reason, node A wants to send a packet to C with a routing > header that will take the packet from A to B to C. The packet will need to > look like: > IPv6 hdr - src A, dst SG > ESP tunnel mode, association A -> SG > IPv6 hdr - src A, dst B > Routing hdr - segs left = 1, C > Transport hdr > > When this packet arrives at B, it will look like > IPv6 hdr - src A, dst B > Routing hdr - segs left = 1, C > Transport hdr > > Node B will process the routing header and send this packet: > IPv6 hdr - src A, dst C > Routing hdr - segs left = 0, B > Transport hdr > > The packet will get to SG again because SG is the router between B and C. SG > will send the following packet: > IPv6 hdr - src SG, dst C > ESP tunnel mode, association SG -> C > IPv6 hdr - src A, dst C > Routing hdr - segs left = 0, B > Transport hdr > > How does all that sound? Now go back to the packet sent by A. How will it > know to do the tunnel-mode ESP to SG? It will need to do outbound IPsec > processing with a destination address selector of B, and pick out the > security association with SG. > > > So when a mobile node moves beyond a SG, how does a correspondent know > > that and hence configures a policy to do IPSEC tunnel mode with SG ? > > Rather, I would assume that such SGs who expect mobile nodes to enter > > their domain, would have policies which would allow traffic which is > > IPSECed (by the presence of IPSEC headers) but not destined for them. > > If a mobile node moves beyond a SG, then a correspondent can know that > because the correspondent will learn a care-of address for the mobile and > the correspondent can have a security policy that tells it how to send to > the care-of address. > I see your point. So it might be useful to do outbound IPSEC processing again after appending the routing header. It would be interesting to understand the applications of such a model. Thanks, Quaizar From owner-ipsec@portal.ex.tis.com Tue Feb 23 08:09:36 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01746; Tue, 23 Feb 1999 08:09:35 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18255 for ipsec-outgoing; Tue, 23 Feb 1999 08:14:29 -0500 (EST) From: kunzinge@us.ibm.com X-Lotus-FromDomain: IBMUS To: ipsec@tis.com Message-ID: <85256721.0047E589.00@d54mta05.raleigh.ibm.com> Date: Tue, 23 Feb 1999 08:06:06 -0500 Subject: Comments/Observations on IPSec/PKI Requirements Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk This is the first of 2 notes that I thought I mailed a few days ago, but it does not appear to me that it was ever sent. I apologize in advance if this is a duplicate. ******************************************* In reviewing the "draft-ietf-ipsec-pki-req-02e.txt" (denoted "IPSec-PKI"), we found several areas of confusion or imprecision which we offer to the working group for their comment and feedback. They all center around terminology differences between the multiple IPSec documents and multiple PKIX documents. The PKIX documents that we looked at while developing these comments are: a) RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", b) draft-ietf-pkix-roadmap-00.txt, "Internet X.509 Public Key Infrastructure PKIX Roadmap" (denoted as "Roadmap", and c) draft-ietf-pkix-ipki3cmp-09.txt, "Internet X.509 Public Key Infrastructure Certificate Management Protocols" (denoted as "CMP"). Our comments are as follows: 1. Recent discussions on the PKIX mailing list have discussed the definition of a "root CA". It appears that both "Roadmap" and "CMP" will not use a definition that a "root CA" is one whose certificate is self-signed. Instead the CMP group is converging on a trust-based definition rather than one based on a CA's relative position in the certification chain. The "CMP" definition is: "We use the term "root CA" to indicate a CA that is directly trusted by an end entity; that is, securely acquiring the value of a root CA public key requires some out-of-band step(s). This term is not meant to imply that a root CA is necessarily at the top of any hierarchy, simply that the CA in question is trusted directly." (See CMP, section 1.2.2). In RFC 2459, there is a rudimentary concept of a "most trusted CA" (see RFC 2459, section 3.2) which seems to map into the CMP definition of "root CA": "As a result, this document supports a more flexible architecture, including:(a) Certification paths may start with a public key of a CA in a user's own domain, or with the public key of the top of a hierarchy. Starting with the public key of a CA in a user's own domain has certain advantages. In some environments, the local domain is the most trusted." RFC 2459 also goes on to say in section 6 that "The 'most-trusted CA' is a matter of policy: it could be a root CA in a hierarchical PKI; the CA that issued the verifier's own certificate(s); or any other CA in a network PKI. The path validation procedure is the same regardless of the choice of 'most-trusted CA'." I may have misunderstood things, but when I read through our IPSec-PKI document the first time, I had assumed that the "root CA" and the "trusted CA" were one and the same, which apparently is not the case. And I got the impression that a certification chain always had to be traced back to its "root CA". Having reviewed the PKI documents, I now believe that the key concept for our work is the "most trusted CA", regardless of its relative position within a certification chain"--for example, if I were tracing through a certification chain, I would stop when I locate a "most trusted CA", even if that CA was not at the very top of the certification heirarchy. It also appears that the definition of a root CA as one with a self-signed certificate is largely irrelevant. In summary, then, can we amend the IPSec-PKI document to clarify "root CA" and "most trusted CA", and explicitly note whether or not the terms are synonymous? My preference would be to use the trust-based definition of "root CA" as in the PKI documents, and to drop the "self-signed" definition entirely as it appears to be largely irrelevant. 2. "IPsec-PKI" implies that an IPSec Identification Certificate should contain a non-empty "subject" field and also a "subjectAltName" field carrying an IP Address, a DNS Name, or an RFC822 Name. Our products will declare a match between the ID Payload field of the IKE messages whenever there is a match with either the certificate's "subject" field or with its "subjectAltName" field. Hence, we feel that the subjectAltName field must be marked as "non-critical" whenever the "subject" field is non-empty. However, we did not find a statement in IPSec-PKI to corroborate this approach. 3. A related issue is the matter of matching certificate subjects and IKE ID Payloads. When one uses the public-key based IKE authentication methods, the contents of the ID Payload from IKE MUST match with at least one of named subjects of the IPSec Identification certificate. However, I couldn't find an explicit statement of this fact in "IPSec-PKI", nor does it define any explicit rules for determining a mathc (or mismatch). We will try to offer some draft text for "IPSec-PKI" section 3.5 in a separate posting to address this and other issues within the next few days. 4. Since an entity can associate the same public key with several different identities, RFC 2459 allows "subjectAltName" field to name multiple identities within a given certificate (see RFC 2459, section 4.3.1.7 for example). Note also that the "Roadmap" in section 5.1.1.2 expressly permits the "subjectAltName" field to carry multiple name forms, and also allows multiple instances of any given name form. Section 4.1.2 if IPSec-PKI appears to permit multiple name forms within the subjectAltName field, but appears to denigrate the appearance of multiple instances of a given name form ("This field SHOULD contain at most one of each of these values..."). Why the strong recommendation against using multiple instances of the same name form? For example, a given person may have multiple e-mail addresses, and it would be convenient to be able to include all of them within the "subjectAltName" field of a given certificate. 4. We do not see value in the ExtendedKeyUsage extension outlined in IPSec-PKI. Imposing a granularity at the level of a end node or an intermediate node is not realistic. A given Security Gateway, for example, may play the role of intermediate node when it is acting as proxy for systems located behind it, but may also play the role of end node when it is exchanging information on a peer basis with another Gateway box. We do not wish to have to obtain multiple certificates to accommodate this situation. If the IPSec working group elects to retain this extension in IPSec Identification certificates, then as a minimum it should be marked as "non-critical". 5. "IPSec-PKI" does not discuss the use of "wildcard" name forms in the subjectAltName field of the certificate (section 4.1.2 discusses only non-wildcard name forms), but the "Roadmap" states that after due deliberation, the PKIX WG will permit the use of wildcards in name forms (see "Roadmap" section 5.1.5). We are uncertain about the value of allowing wildcard name forms in IPSec Identification certificates, and would appreciate feedback from working group members on this topic. 6. RFC2459 describes a critical extension for CA certificates("basicConstraints", section 4.2.1.10). This field indicates if the subject is (or is not) a CA, and it also places a limit on the number of subordinate CA that can be in a certification chain between itself and the IPSec device. Should "IPSec-PKI" require that this field be checked during certificate validation--that is, should we reject a peer's IPSec Identification certificate if its certification path is too long? ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) Network Security Product Development, Dept JEUA,, RTP Phone: Tie 8-444-4142 , External 1-919-254-4142 Fax: Tie 8-444-6243, External 1-919-254-6243 From owner-ipsec@portal.ex.tis.com Tue Feb 23 08:10:17 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01766; Tue, 23 Feb 1999 08:10:16 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18172 for ipsec-outgoing; Tue, 23 Feb 1999 08:11:32 -0500 (EST) From: Quaizar Vohra Date: Mon, 22 Feb 1999 20:35:47 -0800 (PST) Message-Id: <199902230435.UAA00683@lookout.nsd.3com.com> To: Richard Draves Cc: "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: RE: (IPng 7222) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D91@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8100AF81D91@RED-MSG-50> Sender: owner-ipsec@ex.tis.com Precedence: bulk > > I am sorry I was unclear in my last mail. When I said that SG will not > > do inbound IPSEC processing, I did not mean that it will not check its > > policies to see if the packet should have come encrypted to it > > If it has such a policy, it should drop the packet. > > > > Eric already clarified this. > > > > The intention of my previous mail was to say that the presence > > of source routing header in a packet should not change the IPSEC > > behavior either at the inbound or outbound. While a routing > > header might be considered as part of policy lookup, if an > > implementation allowed defining IPsec policies filtering on > > intermediate destination. > > I'm trying to keep things "simple" and not even consider policies that > filter on routing headers. > > So are we in agreement that an IPsec-enabled node that is processing a > routing header should do inbound & outbound IPsec processing, much like a > security gateway that is forwarding a packet? Then I don't understand the > point you are trying to make. Yes I agree, but only that it should not consider SG as part of the selector, but the final destination, unless policies have capabilties to include intermediate destinations as part of the selector list. I guess this is implementation dependent. The point I was trying to make in my first mail, was that if A is communicating with D via B and C, the resulting packet looks like IPv6 hdr - src A, dst B Routing hdr - segs left = 1, C, D Transport hdr Then it does IPSEC processing. Depending on the policy (irrespective of how detailed the selector list) lookup, chooses a policy, which directs it to either do tunnel mode IPsec with an SG or transport mode IPSEC with D. In the 1st case, the packet will look like : IPv6 hdr - src A, dst SG ESP Tunnel mode with SG IPv6 hdr - src A, dst B Routing hdr - segs left = 1, C, D Transport hdr In the later case, it will be IPv6 hdr - src A, dst B ESP transport mode with D Routing hdr - segs left = 1, C, D Transport hdr The secure gateway processes the 1st case by doing inbound IPSEC, processing the ESP header. Next it processes the routing header and forwards the packet to C. In the 2nd case, if SG had an IPSEC policy that expected anything received on the interface this packet is received as ESP tunnelled, then it would drop the packet. All I was trying to say is that a routing header should not mean that IPSEC outbound processing be done twice, one with selector D, and next with selector B. IPsec processing should be done once, with both B and D as part of selectors. Or only D, if selectors containing intermediate dests are not supported. So when a mobile node moves beyond a SG, how does a correspondent know that and hence configures a policy to do IPSEC tunnel mode with SG ? Rather, I would assume that such SGs who expect mobile nodes to enter their domain, would have policies which would allow traffic which is IPSECed (by the presence of IPSEC headers) but not destined for them. Quaizar > > One thought that occurs to me: to revisit the example of a node SG that > receives a packet > IPv6 hdr - src A, dst SG > Routing hdr - segs left = 1, B > Transport hdr > > When node SG is doing its inbound SPD lookup, what selectors should it use? > Should the destination address selector be SG or B? In my first email on > this subject I argued for SG, but now I'm thinking perhaps the destination > address selector in inbound processing should be B (the destination address > after routing header processing). > > Thanks, > Rich From owner-ipsec@portal.ex.tis.com Tue Feb 23 08:14:48 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01815; Tue, 23 Feb 1999 08:14:47 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18234 for ipsec-outgoing; Tue, 23 Feb 1999 08:13:32 -0500 (EST) Message-ID: <029701be5f32$07bf8cb0$634cf526@east.isi.edu> From: "Aaron Griggs" To: "Erik Nordmark" , "Aaron Griggs" Cc: , , Subject: Re: (IPng 7223) Re: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Tue, 23 Feb 1999 08:40:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0810.800 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-ipsec@ex.tis.com Precedence: bulk > >A small clarification: > >> The "care of address" is discovered when the correspondent node receives a >> packet from the mobile node with the source address set to the "care of >> address" and the packet contains a "Home Address" destination option. The >> correspondent node caches the binding. > >The binding is only cached when the packet contains both a "binding update" >destination option and a "home address" destination option. >And the packet must include > "either an AH or ESP header providing sender authentication, data integrity > protection, and replay protection." > Right, thanks for the clarrification. My main point was to describe why a node would want to do a second policy lookup when a routing header is inserted for mobility. It appeared there was some confusion about this. Althought this is an implementation detail, the handling of routing headers by both hosts and security gateways with respect to IPSec processing should be addressed in the relavent documents (mobility, security architecture). Rich began the thread with this point. Thanks, Aaron From owner-ipsec@portal.ex.tis.com Tue Feb 23 09:32:07 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA02482; Tue, 23 Feb 1999 09:32:06 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA19054 for ipsec-outgoing; Tue, 23 Feb 1999 09:42:29 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D91@RED-MSG-50> Date: Tue, 23 Feb 1999 06:35:42 -0800 To: Richard Draves From: Steve Deering Subject: Re: (IPng 7227) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Cc: mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk At 8:06 PM -0800 2/22/99, Richard Draves wrote: > So are we in agreement that an IPsec-enabled node that is processing a > routing header should do inbound & outbound IPsec processing, ... Rich, I've only had a chance to skim these messages, but it occurs to me that some might be confused by your phrase "do IPsec processing", thinking that it means "process the IPsec header(s)", when what you really mean is "perform security policy enforcement", e.g., verify that the packet under consideration arrived via a secure tunnel, or encapsulate the packet in a secure tunnel for the next leg of its route, depending on arrival/departure interface. An IPsec header itself should never be "processed" by anyone other than its original source and its final destination. Steve From owner-ipsec@portal.ex.tis.com Tue Feb 23 11:26:05 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03518; Tue, 23 Feb 1999 11:26:05 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA19409 for ipsec-outgoing; Tue, 23 Feb 1999 11:16:30 -0500 (EST) Message-ID: <36D2D92A.131D5644@cs.stanford.edu> Date: Tue, 23 Feb 1999 08:37:00 -0800 From: Brian Korver Reply-To: briank@CS.Stanford.EDU X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: kunzinge@us.ibm.com CC: ipsec@tis.com Subject: Re: Comments/Observations on IPSec/PKI Requirements References: <85256721.0047E589.00@d54mta05.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk kunzinge@us.ibm.com wrote: > > This is the first of 2 notes that I thought I mailed a few days ago, but it > does not appear to me that it was ever sent. I apologize in advance if > this is a duplicate. > > ******************************************* > > In reviewing the "draft-ietf-ipsec-pki-req-02e.txt" (denoted "IPSec-PKI"), > we found several areas of confusion or imprecision which we offer to the > working group for their comment and feedback. They all center around > terminology differences between the multiple IPSec documents and multiple > PKIX documents. The PKIX documents that we looked at while developing > these comments are: > > a) RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL > Profile", > b) draft-ietf-pkix-roadmap-00.txt, "Internet X.509 Public Key > Infrastructure PKIX Roadmap" (denoted as "Roadmap", and > c) draft-ietf-pkix-ipki3cmp-09.txt, "Internet X.509 Public Key > Infrastructure Certificate Management Protocols" (denoted as "CMP"). > > Our comments are as follows: > > 1. Recent discussions on the PKIX mailing list have discussed the > definition of a "root CA". It appears that both "Roadmap" and "CMP" will > not use a definition that a "root CA" is one whose certificate is > self-signed. Instead the CMP group is converging on a trust-based > definition rather than one based on a CA's relative position in the > certification chain. The "CMP" definition is: "We use the term "root CA" > to indicate a CA that is directly trusted by an end entity; that is, > securely acquiring the value of a root CA public key requires some > out-of-band step(s). This term is not meant to imply that a root CA is > necessarily at the top of any hierarchy, simply that the CA in question is > trusted directly." (See CMP, section 1.2.2). > In RFC 2459, there is a rudimentary concept of a "most trusted CA" (see > RFC 2459, section 3.2) which seems to map into the CMP definition of "root > CA": "As a result, this document supports a more flexible architecture, > including:(a) Certification paths may start with a public key of a CA in a > user's own domain, or with the public key of the top of a hierarchy. > Starting with the public key of a CA in a user's own domain has certain > advantages. In some environments, the local domain is the most trusted." > RFC 2459 also goes on to say in section 6 that "The 'most-trusted CA' is a > matter of policy: it could be a root CA in a hierarchical PKI; the CA that > issued the verifier's own certificate(s); or any other CA in a network PKI. > The path validation procedure is the same regardless of the choice of > 'most-trusted CA'." > I may have misunderstood things, but when I read through our IPSec-PKI > document the first time, I had assumed that the "root CA" and the "trusted > CA" were one and the same, which apparently is not the case. And I got the > impression that a certification chain always had to be traced back to its > "root CA". Having reviewed the PKI documents, I now believe that the key > concept for our work is the "most trusted CA", regardless of its relative > position within a certification chain"--for example, if I were tracing > through a certification chain, I would stop when I locate a "most trusted > CA", even if that CA was not at the very top of the certification > heirarchy. It also appears that the definition of a root CA as one with a > self-signed certificate is largely irrelevant. > > In summary, then, can we amend the IPSec-PKI document to clarify "root CA" > and "most trusted CA", and explicitly note whether or not the terms are > synonymous? My preference would be to use the trust-based definition of > "root CA" as in the PKI documents, and to drop the "self-signed" definition > entirely as it appears to be largely irrelevant. Agreed. > > 2. "IPsec-PKI" implies that an IPSec Identification Certificate should > contain a non-empty "subject" field and also a "subjectAltName" field > carrying an IP Address, a DNS Name, or an RFC822 Name. Our products will > declare a match between the ID Payload field of the IKE messages whenever > there is a match with either the certificate's "subject" field or with its > "subjectAltName" field. Hence, we feel that the subjectAltName field must > be marked as "non-critical" whenever the "subject" field is non-empty. > However, we did not find a statement in IPSec-PKI to corroborate this > approach. Whether SubjectAltName is marked critical or not is irrelevant to IPsec/IKE. The criticality bit says "if you don't understand this field, you cannot use this certificate." Therefore, since it is mandatory for all IPsec/IKE implementations must at least "understand" this field (whether or not they actually use the contents), this particular bit is irrelevant in the context of IPsec/IKE. That said, PKIX states: If subject naming information is present only in the subjectAltName extension ..., then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical. So, if SubjectName is empty, SubjectAltName MUST be critical. If SubjectName is not empty, it doesn't matter if SubjectAltName is critical or not. I guess it wouldn't hurt to state this in the draft.... > 3. A related issue is the matter of matching certificate subjects and IKE > ID Payloads. When one uses the public-key based IKE authentication > methods, the contents of the ID Payload from IKE MUST match with at least > one of named subjects of the IPSec Identification certificate. However, I > couldn't find an explicit statement of this fact in "IPSec-PKI", nor does > it define any explicit rules for determining a mathc (or mismatch). We > will try to offer some draft text for "IPSec-PKI" section 3.5 in a separate > posting to address this and other issues within the next few days. > > 4. Since an entity can associate the same public key with several different > identities, RFC 2459 allows "subjectAltName" field to name multiple > identities within a given certificate (see RFC 2459, section 4.3.1.7 for > example). Note also that the "Roadmap" in section 5.1.1.2 expressly permits > the "subjectAltName" field to carry multiple name forms, and also allows > multiple instances of any given name form. Section 4.1.2 if IPSec-PKI > appears to permit multiple name forms within the subjectAltName field, but > appears to denigrate the appearance of multiple instances of a given name > form ("This field SHOULD contain at most one of each of these values..."). > Why the strong recommendation against using multiple instances of the same > name form? For example, a given person may have multiple e-mail addresses, > and it would be convenient to be able to include all of them within the > "subjectAltName" field of a given certificate. Or more importantly, a device may have multiple interfaces. I agree. This restriction in section 4.1.2 is probably not correct. > > 4. We do not see value in the ExtendedKeyUsage extension outlined in > IPSec-PKI. Imposing a granularity at the level of a end node or an > intermediate node is not realistic. A given Security Gateway, for example, > may play the role of intermediate node when it is acting as proxy for > systems located behind it, but may also play the role of end node when it > is exchanging information on a peer basis with another Gateway box. We do > not wish to have to obtain multiple certificates to accommodate this > situation. If the IPSec working group elects to retain this extension in > IPSec Identification certificates, then as a minimum it should be marked as > "non-critical". > > 5. "IPSec-PKI" does not discuss the use of "wildcard" name forms in the > subjectAltName field of the certificate (section 4.1.2 discusses only > non-wildcard name forms), but the "Roadmap" states that after due > deliberation, the PKIX WG will permit the use of wildcards in name forms > (see "Roadmap" section 5.1.5). We are uncertain about the value of > allowing wildcard name forms in IPSec Identification certificates, and > would appreciate feedback from working group members on this topic. > > 6. RFC2459 describes a critical extension for CA > certificates("basicConstraints", section 4.2.1.10). This field indicates > if the subject is (or is not) a CA, and it also places a limit on the > number of subordinate CA that can be in a certification chain between > itself and the IPSec device. Should "IPSec-PKI" require that this field be > checked during certificate validation--that is, should we reject a peer's > IPSec Identification certificate if its certification path is too long? If this extension is critical (and RFC2459 says it MUST be), then implementations MUST reject certificate chains that violate this extension. Such chains represent a security violation. From owner-ipsec@portal.ex.tis.com Tue Feb 23 11:48:12 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA03736; Tue, 23 Feb 1999 11:48:12 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA19709 for ipsec-outgoing; Tue, 23 Feb 1999 12:14:29 -0500 (EST) Message-ID: From: Ken Powell To: "'Richard Draves'" Cc: mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: RE: (IPng 7222) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Tue, 23 Feb 1999 12:30:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Rich, >> A very concrete, simple example: consider a node SG. SG has two >> interfaces, an interface to the public network and an interface on >> a private network. Node A is on the public network and node B is >> on the private network. The SPD on SG requires all traffic through >> it to & from the public network to be protected with tunnel-mode >> ESP. This is a classic security gateway scenario. So in the normal >> case when node A sends a packet to node B, it will look >> like >> IPv6 hdr - src A, dst SG >> ESP >> IPv6 hdr - src A, dst B >> Transport hdr I thought that a tunnel interface would have a separate address from the public interface on node A. Therefore the message above would become: IPv6 hdr - src A, dst SG ESP with SG IPv6 hdr - src Atunnel, dst B Transport hdr As A moves around the public internet, it has to tell SG it's new location, not B. Its tunnel interface address never changes. If node B moves, it tells "Atunnel" what routing header to use. The resulting message from A would look like: IPv6 hdr - src A, dst SG ESP with SG IPv6 hdr - src Atunnel, dst B's care-of-addr Routing hdr - segs left = 1, B Transport hdr I don't see the problem when node's A and B move. I haven't thought the details of what happens when a node moves across the internet/intranet boundary, or when SG renumbers on either interface. You do run into problems when the "Atunnel" address is derived from "A". In such a case, "Atunnel" would have to change at the same time "A" changes, forcing two routing headers, one before the ESP and one after. Ken From owner-ipsec@portal.ex.tis.com Tue Feb 23 12:01:15 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA03901; Tue, 23 Feb 1999 12:01:15 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA19744 for ipsec-outgoing; Tue, 23 Feb 1999 12:26:30 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D8C@RED-MSG-50> Date: Tue, 23 Feb 1999 12:48:35 -0500 To: Richard Draves From: Stephen Kent Subject: RE: (IPng 7211) RE: Last Call: Mobility Support in IPv6 to Propos ed Standard Cc: "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Richard, > >I don't understand how it can be legitimate for an IPsec-enabled node that >is receiving a packet with a routing header to bypass inbound IPsec >processing. There is no contradiction here if the node is not a party to an SA associated with the IPsec headers in the packet in question. A security policy at an intermediate node could allow traffic to transit without Ipsec processing, if it "appeared" that such processing had been applied already. I'm not suggesting that this is good or bad, just making an observation about what it means to implement IPsec at an SG vs. what it implies for processing of transit traffic. I don'ty necessarily think we're in disagreement here, but I didn't agree with your characterization of the situation, in the cited paragraph. Steve From owner-ipsec@portal.ex.tis.com Tue Feb 23 13:58:40 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA04993; Tue, 23 Feb 1999 13:58:39 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA20329 for ipsec-outgoing; Tue, 23 Feb 1999 14:28:34 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D9D@RED-MSG-50> From: Richard Draves To: "'Ken Powell'" Cc: mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: RE: (IPng 7222) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Tue, 23 Feb 1999 11:49:25 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk > >> A very concrete, simple example: consider a node SG. SG has two > >> interfaces, an interface to the public network and an interface on > >> a private network. Node A is on the public network and node B is > >> on the private network. The SPD on SG requires all traffic through > >> it to & from the public network to be protected with tunnel-mode > >> ESP. This is a classic security gateway scenario. So in the normal > >> case when node A sends a packet to node B, it will look > >> like > >> IPv6 hdr - src A, dst SG > >> ESP > >> IPv6 hdr - src A, dst B > >> Transport hdr > > I thought that a tunnel interface would have a separate > address from the public interface on node A. Therefore the > message above would become: > > IPv6 hdr - src A, dst SG > ESP with SG > IPv6 hdr - src Atunnel, dst B > Transport hdr Ken, this is a generic IPsec security gateway example with no routing header or mobility involved at this point. So I hope we can agree :-). I don't see why node A needs two addresses? Although node A has a tunnel-mode security association with SG, this does not imply that A has some kind of tunnel interface with a separate address assigned to the tunnel interface. Maybe some implementations will work that way, but it's certainly not required or usual, I believe. Thanks, Rich From owner-ipsec@portal.ex.tis.com Tue Feb 23 14:00:21 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA05013; Tue, 23 Feb 1999 14:00:20 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA20368 for ipsec-outgoing; Tue, 23 Feb 1999 14:34:31 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D9E@RED-MSG-50> From: Richard Draves To: "'Stephen Kent'" Cc: "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Subject: RE: (IPng 7211) RE: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Tue, 23 Feb 1999 11:55:24 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk > >I don't understand how it can be legitimate for an > IPsec-enabled node that > >is receiving a packet with a routing header to bypass inbound IPsec > >processing. > > There is no contradiction here if the node is not a party to an SA > associated with the IPsec headers in the packet in question. > A security > policy at an intermediate node could allow traffic to transit > without Ipsec > processing, if it "appeared" that such processing had been > applied already. > I'm not suggesting that this is good or bad, just making an > observation > about what it means to implement IPsec at an SG vs. what it > implies for > processing of transit traffic. I don'ty necessarily think we're in > disagreement here, but I didn't agree with your > characterization of the > situation, in the cited paragraph. Steve, perhaps Steve Deering is correct and my use of "IPsec processing" is confusing. Would you agree with this statement: "An IPsec-enabled node that is processing a routing header must perform inbound and outbound security policy checks, analogous to the checks performed by security gateways." If we are in agreement on this, then I'd like to move on to considering the IPsec processing performed by a node generating a packet with a routing header, with the case of a correspondent node sending a packet to a mobile node being one example. Thanks, Rich From owner-ipsec@portal.ex.tis.com Tue Feb 23 16:22:12 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA06372; Tue, 23 Feb 1999 16:22:11 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA20775 for ipsec-outgoing; Tue, 23 Feb 1999 16:53:31 -0500 (EST) From: pau@watson.ibm.com Date: Tue, 23 Feb 1999 17:16:18 -0500 Message-Id: <9902232216.AA15524@secpwr.watson.ibm.com> To: ipsec@tis.com Subject: IPSEC sessions in Minneapolis IETF Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Md5: hosgS1J2i5wTC3c2QcJQ5w== Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, will there be IPSEC sessions in the coming IETF ? Thanks. Regards, Pau-Chen From owner-ipsec@portal.ex.tis.com Tue Feb 23 17:37:11 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA07195; Tue, 23 Feb 1999 17:37:11 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA21166 for ipsec-outgoing; Tue, 23 Feb 1999 18:18:35 -0500 (EST) Message-Id: <199902232339.SAA19868@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com@tis.com;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-gkmframework-01.txt Date: Tue, 23 Feb 1999 18:39:32 -0500 Sender: owner-ipsec@ex.tis.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) : B. Cain, N. Doraswamy, T. Hardjono Filename : draft-ietf-ipsec-gkmframework-01.txt Pages : 23 Date : 19-Feb-99 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-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-gkmframework-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-gkmframework-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990223180501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-gkmframework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-gkmframework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990223180501.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@portal.ex.tis.com Wed Feb 24 08:17:44 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA16237; Wed, 24 Feb 1999 08:17:43 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA23078 for ipsec-outgoing; Wed, 24 Feb 1999 07:51:31 -0500 (EST) From: kunzinge@us.ibm.com X-Lotus-FromDomain: IBMUS To: ipsec@tis.com Message-ID: <85256722.0047FE58.00@d54mta05.raleigh.ibm.com> Date: Wed, 24 Feb 1999 08:07:13 -0500 Subject: IPSec in Minneapolis? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@ex.tis.com Precedence: bulk I haven't seen time scheduled yet on the Minneapolis for the IPSec WG. Do we know if we will be asking for a slot? As an agenda suggestion, I'd like to see some time scheduled for discussing the IPSec/PKI requirements draft, since I think this will become a key "interoperability" item for IPSec(ond) as we move forward, and would certainly be willing to share my comments on the draft with the group. ____________________________ Charles A Kunzinger (kunzinge@us.ibm.com) Network Security Product Development, Dept JEUA,, RTP Phone: Tie 8-444-4142 , External 1-919-254-4142 Fax: Tie 8-444-6243, External 1-919-254-6243 From owner-ipsec@portal.ex.tis.com Wed Feb 24 09:52:51 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA17056; Wed, 24 Feb 1999 09:52:51 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id JAA24085 for ipsec-outgoing; Wed, 24 Feb 1999 09:29:31 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D9E@RED-MSG-50> Date: Wed, 24 Feb 1999 09:49:03 -0500 To: Richard Draves From: Stephen Kent Subject: RE: (IPng 7211) RE: Last Call: Mobility Support in IPv6 to Propos ed Standard Cc: mobile-ip@smallworks.com, ipng@sunroof.Eng.Sun.COM, ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Richard, > >Would you agree with this statement: > >"An IPsec-enabled node that is processing a routing header must perform >inbound and outbound security policy checks, analogous to the checks >performed by security gateways." > >If we are in agreement on this, then I'd like to move on to considering the >IPsec processing performed by a node generating a packet with a routing >header, with the case of a correspondent node sending a packet to a mobile >node being one example. The critical issue is whether the node is a party to an SA for the packet and IPsec header in question. The fact that this is not mentioned in your concise statement makes me feel that we may still not be on the same wavelength. Steve From owner-ipsec@portal.ex.tis.com Wed Feb 24 11:55:39 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA18254; Wed, 24 Feb 1999 11:55:38 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA24777 for ipsec-outgoing; Wed, 24 Feb 1999 11:48:31 -0500 (EST) Message-ID: <36D43274.820E1264@redcreek.com> Date: Wed, 24 Feb 1999 09:10:12 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: kunzinge@us.ibm.com CC: ipsec@tis.com Subject: Re: IPSec in Minneapolis? References: <85256722.0047FE58.00@d54mta05.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk kunzinge@us.ibm.com wrote: > > I haven't seen time scheduled yet on the Minneapolis for the IPSec WG. Do > we know if we will be asking for a slot? As an agenda suggestion, I'd like > to see some time scheduled for discussing the IPSec/PKI requirements draft, > since I think this will become a key "interoperability" item for IPSec(ond) > as we move forward, and would certainly be willing to share my comments on > the draft with the group. > I agree. We have a bakeoff tentatively scheduled for May, and this discussion is necessary. Scott From owner-ipsec@portal.ex.tis.com Wed Feb 24 17:14:49 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA28750; Wed, 24 Feb 1999 17:14:48 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA26480 for ipsec-outgoing; Wed, 24 Feb 1999 17:37:35 -0500 (EST) Message-Id: <199902242258.RAA27372@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com@tis.com;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.txt Date: Wed, 24 Feb 1999 17:58:40 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-RIPEMD-160-96 within ESP and AH Author(s) : A. Keromytis, N. Provos Filename : draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.txt Pages : 6 Date : 22-Feb-99 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.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-auth-hmac-ripemd-160-96-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990224173804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990224173804.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@portal.ex.tis.com Wed Feb 24 17:56:24 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01989; Wed, 24 Feb 1999 17:56:24 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA26448 for ipsec-outgoing; Wed, 24 Feb 1999 17:24:37 -0500 (EST) Date: Wed, 24 Feb 1999 14:43:06 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: (mobile-ip) RE: (IPng 7211) RE: Last Call: Mobility Support in IPv6 to Propos ed Standard To: Richard Draves Cc: "'Stephen Kent'" , "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.eng.Sun.COM, ipsec@tis.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8100AF81D9E@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Would you agree with this statement: > > "An IPsec-enabled node that is processing a routing header must perform > inbound and outbound security policy checks, analogous to the checks > performed by security gateways." In interpret your statement that routing headers are somehow different than regular forwarding. Is this what you intend? Or do you intend? "An router forwarding packets (whether using routing headers or not) might implement security policy checks." I still don't see why routing headers need to be any different. Erik From owner-ipsec@portal.ex.tis.com Wed Feb 24 18:12:57 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA02661; Wed, 24 Feb 1999 18:12:57 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA26610 for ipsec-outgoing; Wed, 24 Feb 1999 18:47:37 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <85256721.0047E589.00@d54mta05.raleigh.ibm.com> Date: Wed, 24 Feb 1999 19:07:27 -0500 To: kunzinge@us.ibm.com From: Stephen Kent Subject: Re: Comments/Observations on IPSec/PKI Requirements Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Charles, >2. "IPsec-PKI" implies that an IPSec Identification Certificate should >contain a non-empty "subject" field and also a "subjectAltName" field >carrying an IP Address, a DNS Name, or an RFC822 Name. Our products will >declare a match between the ID Payload field of the IKE messages whenever >there is a match with either the certificate's "subject" field or with its >"subjectAltName" field. Hence, we feel that the subjectAltName field must >be marked as "non-critical" whenever the "subject" field is non-empty. >However, we did not find a statement in IPSec-PKI to corroborate this >approach. It is solely up to the CA to determine whether the subjectAltName is critical, or not. For example, if the CA is issuing a cert to represent a DNS name, nut also includes a DN because of some requirement for LDAP directory storage, it would not be unreasonable to mark the subjectAltName critical. >3. A related issue is the matter of matching certificate subjects and IKE >ID Payloads. When one uses the public-key based IKE authentication >methods, the contents of the ID Payload from IKE MUST match with at least >one of named subjects of the IPSec Identification certificate. However, I >couldn't find an explicit statement of this fact in "IPSec-PKI", nor does >it define any explicit rules for determining a mathc (or mismatch). We >will try to offer some draft text for "IPSec-PKI" section 3.5 in a separate >posting to address this and other issues within the next few days. Matching should be controlled by the rules for the name type in question. IKE supports DNs, DNS names, Ip addresses, and RFC822 names. Each has different matching rules, e.g., DNS and RFC822 names are case insensitive, whereas DNS have an elaborate set of matching rules inherited from the directory. >4. Since an entity can associate the same public key with several different >identities, RFC 2459 allows "subjectAltName" field to name multiple >identities within a given certificate (see RFC 2459, section 4.3.1.7 for >example). Note also that the "Roadmap" in section 5.1.1.2 expressly permits >the "subjectAltName" field to carry multiple name forms, and also allows >multiple instances of any given name form. Section 4.1.2 if IPSec-PKI >appears to permit multiple name forms within the subjectAltName field, but >appears to denigrate the appearance of multiple instances of a given name >form ("This field SHOULD contain at most one of each of these values..."). >Why the strong recommendation against using multiple instances of the same >name form? For example, a given person may have multiple e-mail addresses, >and it would be convenient to be able to include all of them within the >"subjectAltName" field of a given certificate. I always recommend use of the NameConstraints extension with certs, to minimize the damage done by a CA error, or by a malicious CA. Although one c an use this extension with a cert that contains multiple names and name forms, the processing becomes more complex as a result. Thus, I would recommend against trying to put too many names in the same cert. For example, if I have a BBN e-mail address, it is fine for a BBN CA to issue a cert for that, but it would be inappropriate for the BBN CA to put in my Erol's e-mail address too, since that CA is NOT authoritative for e-mail addresses in the Erol's domain. Thus one could have a simgle cert with multiple e-mail addresses, but it would be a bad idea unless these addresses were all in the same domain. >4. We do not see value in the ExtendedKeyUsage extension outlined in >IPSec-PKI. Imposing a granularity at the level of a end node or an >intermediate node is not realistic. A given Security Gateway, for example, >may play the role of intermediate node when it is acting as proxy for >systems located behind it, but may also play the role of end node when it >is exchanging information on a peer basis with another Gateway box. We do >not wish to have to obtain multiple certificates to accommodate this >situation. If the IPSec working group elects to retain this extension in >IPSec Identification certificates, then as a minimum it should be marked as >"non-critical". Why do you worry about obtaining multiple certs for the example you cited? Increasiningly people don't vharge on a per-cert basis (or don't charge much). I'm not arguing that this is very important, but I didn't see the example you cited as persuasive as a reason for not using EKU. >5. "IPSec-PKI" does not discuss the use of "wildcard" name forms in the >subjectAltName field of the certificate (section 4.1.2 discusses only >non-wildcard name forms), but the "Roadmap" states that after due >deliberation, the PKIX WG will permit the use of wildcards in name forms >(see "Roadmap" section 5.1.5). We are uncertain about the value of >allowing wildcard name forms in IPSec Identification certificates, and >would appreciate feedback from working group members on this topic. The Roadmap is wrong in this case. If you look at the RFC you will see NO support for wildcard name forms. >6. RFC2459 describes a critical extension for CA >certificates("basicConstraints", section 4.2.1.10). This field indicates >if the subject is (or is not) a CA, and it also places a limit on the >number of subordinate CA that can be in a certification chain between >itself and the IPSec device. Should "IPSec-PKI" require that this field be >checked during certificate validation--that is, should we reject a peer's >IPSec Identification certificate if its certification path is too long? Compliant processing relative to RFC 2459 requires such checking. If you want to be able to say that an IPsec device complies with this RFC (as a certificate consumer or relying party) as part of your marketing literature, then you must perform all the checks called for, if you receive a cert with such extensions. Since this is an extension that MUST appear in a CA cert, and MUST NOT appear in an end entity cert, you really ought to check that the cert paths you process conform to these requirements. Steve From owner-ipsec@portal.ex.tis.com Wed Feb 24 18:43:30 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA04025; Wed, 24 Feb 1999 18:43:29 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id TAA26680 for ipsec-outgoing; Wed, 24 Feb 1999 19:20:36 -0500 (EST) Date: Wed, 24 Feb 1999 19:41:28 -0500 (EST) Message-Id: <199902250041.TAA26599@dcl> From: "Theodore Y. Ts'o" To: ipsec@tis.com Subject: IPSEC meeting scheduled for Minneapolis Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk For those folks who were asking when the IPSEC meeting would be scheduled in Minneapolis, I just received the following word from the Secretariat: >I have tentatively scheduled IPSEC for Monday at 1300-1500. Other >groups scheduled at that time are: ion, rmonmib, idr, megaco, uswg. Folks who would like time on the IPSEC agenda should send mail to me and Bob. I expect that most of our time will be spent discussing MIB issues and problems/clarifications needed with the existing IPSEC documents. (Note that there will be a separate BOF to handle remote configuration, and in general new IPSEC work items will likely be done in new working groups. Please talk to me or Bob or the Security AD's if you want to talk about starting a new working group.) - Ted From owner-ipsec@portal.ex.tis.com Thu Feb 25 02:14:25 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18114; Thu, 25 Feb 1999 02:14:24 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id CAA27583 for ipsec-outgoing; Thu, 25 Feb 1999 02:18:34 -0500 (EST) Message-Id: <199902242258.RAA27372@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com@tis.com;;;;;;;; Cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.txt Date: Wed, 24 Feb 1999 17:58:40 -0500 X-Rcpt-To: aalok@bisquare.com X-UIDL: 04fddc5bdfe219acd0fde77ee5a9f8c5 Status: O Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Use of HMAC-RIPEMD-160-96 within ESP and AH Author(s) : A. Keromytis, N. Provos Filename : draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.txt Pages : 6 Date : 22-Feb-99 This draft describes the use of the HMAC algorithm [RFC-2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.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-auth-hmac-ripemd-160-96-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990224173804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-auth-hmac-ripemd-160-96-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990224173804.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@portal.ex.tis.com Thu Feb 25 10:37:42 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24899; Thu, 25 Feb 1999 10:37:42 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA29631 for ipsec-outgoing; Thu, 25 Feb 1999 10:07:37 -0500 (EST) Message-ID: <1FC459ADA4B6D211ACE600A0C9F031DC0BB4D3@hq320ex1.bonn.detecon.de> From: "Eren, Evren" To: ipsec@tis.com Subject: ipsec software for nt Date: Thu, 25 Feb 1999 16:30:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Is there any testable ipsec software for nt available before nt v5 will be released ? thanks regards evren _______________________________________________________ > Dr. E. Eren > DETECON GmbH (Subsidiary of Deutsche Telekom AG) (Telecommunications Engineering and Management Consultancy) _______________________________________________________ From owner-ipsec@portal.ex.tis.com Thu Feb 25 13:05:55 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26505; Thu, 25 Feb 1999 13:05:54 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA00306 for ipsec-outgoing; Thu, 25 Feb 1999 13:07:39 -0500 (EST) Message-ID: <29752A74B6C5D211A4920090273CA3DC031E91@new-exc1.ctron.com> From: "Waters, Stephen" To: "'ipsec@tis.com'" Subject: IPSEC stress tester? Date: Thu, 25 Feb 1999 18:27:40 -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@ex.tis.com Precedence: bulk I'm not sure if my last mail got out, so.... I'm looking for a test suite that will stress-test an IPSEC security gateway. Can anyone recommend something? If the product doesn't exist, maybe a service does? I would prefer a product that I can re-use at my leisure as part of a regression test program. Thanks, Steve. From owner-ipsec@portal.ex.tis.com Thu Feb 25 14:43:14 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27354; Thu, 25 Feb 1999 14:43:14 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA00754 for ipsec-outgoing; Thu, 25 Feb 1999 15:07:45 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81DE2@RED-MSG-50> From: Richard Draves To: "'Mobile IP'" , "'IPsec'" , "'IPng List'" Cc: "'Stephen Kent'" Subject: RE: (IPng 7211) RE: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Thu, 25 Feb 1999 12:28:29 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve Kent and I have talked this over off-line and come to agreement. (Actually, I think we were already in agreement, we just weren't communicating effectively via email.) We agree on the following two points: 1. A node will only process an ESP or AH header if it is participating in the relevant security association. In particular, a node processing a routing header will not "snoop" into ESP & AH headers that are not associated with the node. For example, node A receives a packet IPv6 hdr - src X, dst A ESP tunnel-mode assoc X -> A IPv6 hdr - src X, dst A Routing hdr - segs left = 1, B Transport hdr In this case node A WILL process the ESP header. IPv6 hdr - src X, dst A Routing hdr - segs left = 1, B ESP transport-mode assoc X -> B Transport hdr In this case node A will NOT process the ESP header. 2. In any case, an IPsec-enabled node that is processing a routing header (with segs left != 0) and hence forwarding a packet must perform inbound and outbound security policy checks. The IPsec processing in this situation is the same as the IPsec processing performed by a security gateway that is forwarding a packet not destined for itself. Thanks, Rich From owner-ipsec@portal.ex.tis.com Thu Feb 25 15:56:43 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA28129; Thu, 25 Feb 1999 15:56:42 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA00912 for ipsec-outgoing; Thu, 25 Feb 1999 16:20:43 -0500 (EST) Message-Id: <4.2.0.25.19990225132925.00b12e10@mail.imc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.25 (Beta) Date: Thu, 25 Feb 1999 13:40:54 -0800 To: "Waters, Stephen" , "'ipsec@tis.com'" From: Paul Hoffman Subject: Re: IPSEC stress tester? In-Reply-To: <29752A74B6C5D211A4920090273CA3DC031E91@new-exc1.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@ex.tis.com Precedence: bulk >I'm looking for a test suite that will stress-test an IPSEC security >gateway. >Can anyone recommend something? If the product doesn't exist, maybe a >service does? I would prefer a product that I can re-use at my leisure as >part of a regression test program. Depends on what you mean by "stress test". There are at least two orthogonal types of stress tests people have proposed: speed and number/type of SAs. Creating software/hardware to test either type of stress is easy; creating tests that are useful in the real world is probably difficult without discussion from many vendors and customers. A few companies have suggested that VPNC create some standard stress-testing regimen, not so that someone can say "Product A runs faster under stress than Product B", but so they ca say "if you put Product C on one end of an Internet connection with a line speed of N, you can be sure that the line speed will limit you sooner than the processing power of Product C". Once VPNC gets up and running, I hope that the members will want to discuss this more, and that we make the results public so that anyone can run the tests themselves. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@portal.ex.tis.com Thu Feb 25 18:26:26 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA00445; Thu, 25 Feb 1999 18:26:25 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA01474 for ipsec-outgoing; Thu, 25 Feb 1999 18:21:44 -0500 (EST) Message-ID: <36D5DFC4.FC04DD49@cs.stanford.edu> Date: Thu, 25 Feb 1999 15:42:18 -0800 From: Brian Korver Reply-To: briank@CS.Stanford.EDU X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: kunzinge@us.ibm.com CC: ipsec@tis.com Subject: Re: Strawman Text for Section 3.5 of "IPSec/PKI Req'ts" draft References: <8525671D.004851CC.00@d54mta05.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk kunzinge@us.ibm.com wrote: > > This is the 2nd of two notes I though I sent out 2 days ago. I apologize > if it is a duplicate. > > **************************** > > The current internet draft "PKI Requirements for IP Security" > (draft-ietf-ipsec-pki-req-02e.txt) has a scetion 3.5 entitled "IKE > PRocessing of Certificates", but as yet there is no text for this section. > This contribution offers some draft text that may be appropriate for > inclusion there. It will address issues such as: a) how does one use the > Certifcate Request payload and the Certificate Payload in IKE, b) how does > one do matching of IKE's Payload ID field with a certificate's subjects. > The material here is simply one suggestion on how to handle these issues, > and there certainly other strategies one could implement. Our goal is to > simply offer a strawman approach for review and discussion by the IPSec > Working Group, in the interests of reaching an informal consensus that will > enhance the interoperability across IPSec/IKE implementations. > > Our strawman text for Section 3.5 is as follows: > > 3.5 IKE Processing of Certificates > > Digital certificates are used within the Internet Key Exchange (IKE) > protocol's public-key-based Phase 1 exchange modes (Main Mode and > Aggressive > Mode) to validate the identities of the negotiating parties. Digital > certificates are not used in any IKE Phase 2 exchanges, nor are they used > in IKE's Phase 1 "preshared key" mode of authentication. > > Each party to the IKE negotiation MUST validate the IPSec Identification > certificate of its peer. Then, depending on the particular method of > authentication being used (that is, signatures or encryption), each > party uses the other party's public key to either verify the peer's > digital signature or decrypt the peer's encrypted data carried within the > IKE payload. > > 3.5.1 Locally Stored PKI Information > > In order to properly handle digital certificates within the IKE flows, each > IPSec-enabled device must: > > -Possess each of its own private keys and store each one securely. > Depending on the IKE authentication modes that it supports, a device > might have just a single "digital signature" key, a single "key > encipherment" key, or both. Effectively, the device will need to > securely store one private key for each digital certificate that has > been issued to it. > > -Possess a copy of each of its IPSec Identification Certificate that it > intends to use within the IKE Phase 1 negotiations. An IPSec device > may > have multiple digital certificates. For example, it may have obtained > IPSec Identification certificates from multiple different CAs, or it > may wish to support both signature-based and encryption-based modes of > IKE authentication, thus requiring one digital certificate for each > key usage mode. > > -The IPSec-device must have a copy of its certificates available to > itself > locally so that it can respond to any Certificate Request payloads > that > might occur during the IKE negotiations. > > -Possess a copy of a "trusted" CA Signing Certificate for each > certification path that it may need to trace through. In general, > the exact number of "trusted" CA Signing Certificates that an > IPSec-capable device must store can not be specified until the > details of the VPN (or VPNs) in which the device wishes to > participate are known--that is, it is a matter of policy rather > than a matter of protocol. > I'm not sure I agree that the above 2 paragraphs are requirements. Imagine two devices in a corporate environment where the certificates are available via a corporate LDAP server. Must each device obtain a local copy of its certificate chains, even though the device will never be responding to a CERTREQ message? I would be in favor of the above requirements if they were made conditional by stating something like: Unless an IPSec device is configured with specific knowledge that all possible peers will never send CERTREQ messages (in other words, all possible peers already have access to the keying materials for this IPSec device), then.... If we state the above requirements for certificates, then I think that a similar requirement should be stated for CRLs, something like: Unless an is configured with specific knowledge that all possible peers will never send CRL CERTREQ messages (in other words, all possible peers already have access to the relevant revocation status of the keying materials for this IPsec device), then the IPsec device MUST have a copy of a current the CRL for each CA Signing Certificate in all of the device's Identity Certificate certificate chains. > 3.5.2 How an IPSec Device Validates Its Peer's Claimed Identity > > Within the IKE Phase 1 message exchanges, each party announces to the other > who it claims to be via the ID Payload in the IKE messages that it > originates. > The basic rule is relatively simple: the identity claimed by an > IPSec-enabled > device in its IKE "IP Payload" must match the subject(s) named in > the associated IPSec Identification Certificate. If this criterion is > not satisfied, then the certificate is not valid and theIKE negotiations > MUST be aborted. Failure of the identities match is an auditable event. > > This criterion says absolutely nothing about the contents of the IP > header of the datagram in which the IKE messages flow. The only relevant > information is the ID Payload field and named subject(s)in the IPSec > Identification Certificate. The relevant information also includes whatever is in the IPsec policy. That is, the contents of the ID Payload (and, of course, certificate), must be matched against the contents of the IPsec policy. > > The rules for determining declaring a match (or a mismatch) depend on > the type of identity claimed in the ID Payload field. They are > straightforward: I'd suggest numbering these rules.... > -An ID Payload of type "IPv4 Address matches a certificate's > subjectAltName that expresses an IPv4 address whenever the > two IP addresses are exactly the same I think that multiple IP addresses in SubjectAltName should be permitted. There are cases, such as for security gateways, where a IPsec device may have multiple "external" interfaces. I realize that the current draft explicitly prohibits this. Perhaps this is an appropriate time to discuss this constraint.... I propose: 3.5.2.1 An ID Payload of type "IPv4 Address" matches a certificate's subjectAltName that expresses an IPv4 address whenever the IPv4 address in the ID Payload is identical to any of the IP addresses in subjectAltName. > -An ID Payload of type "IPv6 Address" matches a certificate's > subjectAltName that expresses an IPv6 address whenever the > two IP addresses are exactly the same Similarly: 3.5.2.2 An ID Payload of type "IPv6 Address" matches a certificate's subjectAltName that expresses an IPv6 address whenever the IPv6 address in the ID Payload is identical to any of the IP addresses in subjectAltName. > -An ID Payload of type "Fully Qualified Domain Name" matches a > certificate's subjectAltName that contains an identical > domain name. For example, if the fully qualified domain name in the > ID Payload is "joe.raleigh.ibm.com", then the DNS name contained in > the > certificate's subjAltName extension must also be > "joe.raleigh.ibm.com". > -An ID Payload of type "User Fully Qualified Domain Name" (email > address) > matches a certificate's subjectAltName that contains an identical > user name. For example, if the fully qualifed domain name in the > ID Payload is "Joe@raleigh.ibm.com", then the DNS name contained in > the > must also be "joe@raleigh.ibm.com". > -An ID Payload of type "DER-encoded ASN.1 Distinguished Name" matches > a certificate's subject field that carries the same distinguished > name. Also, what about the other ID Payload types? I propose: 3.5.2.6 An ID Payload of type "DER-encoded ASN.1 GeneralName" matches a certificate's subjectAltName whenever the GeneralName in the ID Payload is identical to any of the GeneralNames in subjectAltName. No other ID Payload type is to match the identity in an Identity Certificate. Therefore, by definition, any other ID Payload type will fail to match the certificate's subjectAltName. > > 3.5.3 Exchanging Certificates within the IKE Flows > > As an alternative to retriveing certificates from an LDAP directory using > an "offline" process, the IKE protocols offer a way to exchange > certificates > "inline" during the IKE message flows using IKE's Certificate Request > Payload and its Certificate ayload. Inclusion of a Certificate Request > Payload in an IKE message is optional. But, if it is present, the > recipient > of the request MUST reply to it, using the Certificate Payload. > To implement an "inline" exchange of certificates, the following rules are > recommended, depending on the box's role as either IKE Initiator or IKE > Responder: > > A) IKE INITIATIOR -- MAIN MODE > 1) An IPsec device that is an IKE initiator will include > a Certificate Payload in IKE Message 5, even if no Certificate Request > has been received from the IKE responder. The IPSec Identification > Certificate delivered to the IKE responder will contain the public key > that the responder will use to verify the initiator's digital > signature, which is also carried in IKE Message 5. > > 2) An IPSec device that is an IKE initiator will always include > a Certificate Request in IKE Message 5. This assures that the > IKE responder will deliver a suitable IPSec Identification Certificate > to the initiator in IKE Message 6. > > B) IKE INITIATOR - AGGRESSIVE MODE > 1)An IPSec device that is an IKE initiator will include a > Certificate Payload in IKE Message 3. The IPSec Identification > Certificate delivered to the IKE responder will contain the > public key that the responder will use to verify the digital signature > that the initiator includes in Message 3. > > 2) An IPSec device that is an IKE initiator will include a Certificate > Request in IKE Message 1. This assures that the IKE responder will > deliver a suitable IPSec Identification Certificate to the initiator > in IKE Message 2. > > C) IKE RESPONDER - MAIN MODE > 1) An IPSec device that is an IKE responder will include > a Certificate Payload in IKE Message 6, even if no Certificate Request > has been received from the IKE responder. The certificate delivered > to the IKE initiator will be the one that carries the public key > that the IKE initiator will use in verifying IKE responder's digital > signature, which is also carried in IKE Message 6. > 2) An IPSec device that is an IKE responder will always > include a Certificate Request in IKE Message 4. This assures that the > IKE initiator will deliver a suitable IPSec Identification Certificate > to the responder in IKE Message 5. > > D) IKE RESPONDER - AGGRESSIVE MODE > 1) An IPSec device that is an IKE responder will always include a > Certificate Payload in IKE Message 2, even in the absence of a > prior Certificate Request from the IKE initiator. The > certificate delivered to the IKE initiator will be the one that > carries the public key that the IKE initiator will use to verify > the responder's digital signature, which is also carried in > IKE Message 2. > 2) An IPSec device that is an IKE responder will always include a > Certificate Request in IKE Message 2. This assures that the IKE > initiator will deliver a suitable IPSec Identification Certificate > to the responder in IKE Message 3. I think the above rules are overkill. Unfortunately, ISAKMP doesn't completely spell out the semantics of the CERTREQ messages. I'm not sure that this draft is the appropriate place to clarify this issue (perhaps DOI or the IKE draft is?), but I believe the rules are thus (some of which are explicitly stated in ISAKMP, some of which I'm proposing): 1) If a device wants to receive keying materials from a peer, the device MUST send a CERTREQ message. In other words, a device that does not receive a CERTREQ message is not obligated to send any CERT messages. 2) In response to a CERTREQ message of any of the non-X.509 certificate types, a device MUST respond with CERT message of identical type ("cert encoding"). For all of the X.509 certificate types ("PKCS#7 wrapped X.509 cert", "X.509 cert - signature", "X.509 cert - key exchange", and "CRL"), a device MAY respond with either CERT message(s) of identical type, or with CERT message(s) of type "PKCS#7 wrapped X.509 cert". Rather than sending multiple X.509 CERT messages, a device MAY combine the certificates and/or CRLs from those messages into a CERT message(s) of type "PKCS#7 wrapped X.509 cert". Conversely, rather than sending a CERT message of type "PKCS#7 wrapped X.509 cert" that contains multiple certs and/or CRLs, a device MAY send multiple CERT messages. However, a device MUST NOT send a non-signature certificate in a "X.509 cert - signature" CERT message and MUST NOT send a non-key-exchange certificate in a "X.509 cert - key exchange" message. Any type of certificate is permitted in a CERT message of type "PKCS#7 wrapped X.509 cert". 3) Devices MUST must be able to receive CERT messages in all of the combinations implied by (2). 4) In response to a CERTREQ message of one of the X.509 "certificate" types ("PKCS#7 wrapped X.509 cert", "X.509 cert - signature", and "X.509 cert - key exchange"), a device SHOULD NOT send CRLs (unless CRLs were also requested in a separate CERTREQ message). Similarly, in response to CERTREQ message of type CRL, a device SHOULD NOT send certificates (unless certificates were also requested in a separate CERTREQ message). In other words, if a device wants to receive both certs and CRLs, the device MUST send a CERTREQ messages that requests certificates and another that requests CRLs. 5) In response to a CERTREQ message, a device MUST send CERT messages for all of the keying materials (of the requested type) that are "below" the CA that is identified in the CERTREQ message. Note, for CRL CERTREQ messages, the CRL of the identified CA is considered "below" that CA, as are the CRLs of all the CAs "beneath" the identified CA. 6) As a result of (5), a device SHOULD construct a CERTREQ message by including the identity of the "lowest" CA in the hierarchy for which the device already has available the associated keying materials. 7) In response to a CERTREQ message that does not contain a Certificate Authority field, a device with multiple Identity Certificates MAY respond with any of its identities. However, devices SHOULD implement local heuristics to determine which identity to send, rather than picking an identity at random. In response to multiple, *related* CERTREQ messages (such as one requesting certificates and one requesting CRLs), a device MUST respond with related keying materials. That is, in this situation, it is incorrect for a device to respond with a certificate hierarchy of one CA but the CRL(s) from a different hierarchy. 8) A device MAY send multiple CERTREQ messages containing different Certificate Authories in order to express that any of those CAs is acceptable. In response to these multiple CERTREQ messages, the device MAY respond with any local identity that matches one of the CERTREQ messsages. 9) Devices MUST support receiving multiple CERT messages in response to to each CERTREQ message that was sent. 10) Devices MUST support receiving CERT messages without ever having sent a CERTREQ message. 11) Devices MAY elect not to use keying materials contained in CERT messages, if preferable keying materials are available to the device. For instance, the device may already have a CRL which is newer than one that was received from the peer. > > ____________________________ > Charles A Kunzinger (kunzinge@us.ibm.com) > Network Security Product Development, Dept JEUA,, RTP > Phone: Tie 8-444-4142 , External 1-919-254-4142 > Fax: Tie 8-444-6243, External 1-919-254-6243 From owner-ipsec@portal.ex.tis.com Thu Feb 25 18:29:06 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA00484; Thu, 25 Feb 1999 18:29:06 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA01473 for ipsec-outgoing; Thu, 25 Feb 1999 18:21:44 -0500 (EST) Message-ID: <29752A74B6C5D211A4920090273CA3DC031E94@new-exc1.ctron.com> From: "Waters, Stephen" To: "'Paul Hoffman'" Cc: "'ipsec@tis.com'" Subject: RE: IPSEC stress tester? Date: Thu, 25 Feb 1999 23:42:30 -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@ex.tis.com Precedence: bulk Thanks for all the replies. I guess what I'm looking for is a test suite that has knowledge of the IPSEC/IKE protocols and tries to expose weaknesses. Some simple examples could be: - sending ESP/AH packets to various SPI values - creating IPSEC-SA with IKE, and then sending corrupted ESP/AH packet (man-in-the-middle tests) - replay attacks - pre-shared key guessing for Phase1 break-in attempts - sending in ESP packets that contain IP packets not covered by the Phase-2 negotiation - 'exploding' IPCOMP packets We could probably come up with a fairly long list between us. I would like to see such a tool so that VPN CPE customers can sleep at nights knowing their CPE has passed these tests. So far, I've tried tools intended for firewall testing, and, as you would expect, they don't do much with a router that is armed with IPSEC. This sounds like an opportunity for someone. From the number of holes I've had to fix in our IPSEC implementation, this someone probably works for a company with IPSEC products. Steve. -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Thursday, February 25, 1999 9:41 PM To: Waters, Stephen; 'ipsec@tis.com' Subject: Re: IPSEC stress tester? >I'm looking for a test suite that will stress-test an IPSEC security >gateway. >Can anyone recommend something? If the product doesn't exist, maybe a >service does? I would prefer a product that I can re-use at my leisure as >part of a regression test program. Depends on what you mean by "stress test". There are at least two orthogonal types of stress tests people have proposed: speed and number/type of SAs. Creating software/hardware to test either type of stress is easy; creating tests that are useful in the real world is probably difficult without discussion from many vendors and customers. A few companies have suggested that VPNC create some standard stress-testing regimen, not so that someone can say "Product A runs faster under stress than Product B", but so they ca say "if you put Product C on one end of an Internet connection with a line speed of N, you can be sure that the line speed will limit you sooner than the processing power of Product C". Once VPNC gets up and running, I hope that the members will want to discuss this more, and that we make the results public so that anyone can run the tests themselves. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@portal.ex.tis.com Thu Feb 25 20:52:18 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA11139; Thu, 25 Feb 1999 20:52:17 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA02111 for ipsec-outgoing; Thu, 25 Feb 1999 21:01:40 -0500 (EST) From: suresh@livingston.com (Pyda Srisuresh) Message-Id: <199902260222.SAA09018@kc.livingston.com> Subject: Looking for an IPsec packet analyzer To: ipsec@tis.com Date: Thu, 25 Feb 1999 18:22:56 -0800 (PST) Cc: suresh@livingston.com (Pyda Srisuresh) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, Can someone point me to one or more vendors that provide IPsec and IKE trafiic decoding in their traffic analyser software? Specifically, I am looking for the following: 1. IPSec AH and ESP header decoding 2. IKE header and payload decoding (while in the clear) Thanks. cheers, suresh From owner-ipsec@portal.ex.tis.com Fri Feb 26 11:31:56 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04705; Fri, 26 Feb 1999 11:31:56 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA04504 for ipsec-outgoing; Fri, 26 Feb 1999 11:39:41 -0500 (EST) Message-ID: From: Jason Devine To: "Waters, Stephen" , "'Paul Hoffman'" Cc: "'ipsec@tis.com'" Subject: RE: IPSEC stress tester? Date: Fri, 26 Feb 1999 10:56:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk The tests outlined below I would consider IPSEC compliance tests. I believe that the Anvil product from Midnight Networks now supports these type of tests. However, the original question appeared to address performance metrics for various IPSEC solutions. I agree with Paul that these tests fall into two main categories, throughput and SAs. Throughput testing is pretty straight forward. All you need is something to generate traffic (i.e. SmartBits) at various packet sizes and rates through an SA. The results will tell you both packet forwarding and bulk encryption limitations. The max SA test is the tricky one. I am familiar with some larger vendors that have built rooms with over a hundred PCs each running scripts to establish 10 to 20 SAs. This is not practical for most organizations. Therefore, I am forced to take the word of the vendor that a particular box can handle X number of simultaneous SAs. This is becoming an increasingly critical issue as service providers look for solutions to support 10s of thousands of simultaneous encrypted connections. There must be someone out there who has come up with a reasonably elegant solution to this problem. Jason Devine, jdevine@technicacorp.com Manager, Information Systems Technica Corporation, www.technicacorp.com > -----Original Message----- > From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com] > Sent: Thursday, February 25, 1999 6:43 PM > To: 'Paul Hoffman' > Cc: 'ipsec@tis.com' > Subject: RE: IPSEC stress tester? > > > > Thanks for all the replies. I guess what I'm looking for is a > test suite > that has knowledge of the IPSEC/IKE protocols and tries to expose > weaknesses. > > Some simple examples could be: > > - sending ESP/AH packets to various SPI values > - creating IPSEC-SA with IKE, and then sending corrupted ESP/AH packet > (man-in-the-middle tests) > - replay attacks > - pre-shared key guessing for Phase1 break-in attempts > - sending in ESP packets that contain IP packets not covered > by the Phase-2 > negotiation > - 'exploding' IPCOMP packets > > We could probably come up with a fairly long list between us. > I would like > to see such a tool so that VPN CPE customers can sleep at > nights knowing > their CPE has passed these tests. > > So far, I've tried tools intended for firewall testing, and, > as you would > expect, they > don't do much with a router that is armed with IPSEC. > > This sounds like an opportunity for someone. From the number > of holes I've > had to fix in our IPSEC implementation, this someone probably > works for a > company with IPSEC products. > Steve. > > > > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Thursday, February 25, 1999 9:41 PM > To: Waters, Stephen; 'ipsec@tis.com' > Subject: Re: IPSEC stress tester? > > > > >I'm looking for a test suite that will stress-test an IPSEC security > >gateway. > >Can anyone recommend something? If the product doesn't exist, maybe a > >service does? I would prefer a product that I can re-use at > my leisure as > >part of a regression test program. > > Depends on what you mean by "stress test". There are at least two > orthogonal types of stress tests people have proposed: speed and > number/type of SAs. Creating software/hardware to test either type of > stress is easy; creating tests that are useful in the real world is > probably difficult without discussion from many vendors and customers. > > A few companies have suggested that VPNC create some standard > stress-testing regimen, not so that someone can say "Product > A runs faster > under stress than Product B", but so they ca say "if you put > Product C on > one end of an Internet connection with a line speed of N, you > can be sure > that the line speed will limit you sooner than the processing > power of > Product C". Once VPNC gets up and running, I hope that the > members will > want to discuss this more, and that we make the results > public so that > anyone can run the tests themselves. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@portal.ex.tis.com Fri Feb 26 11:56:36 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04975; Fri, 26 Feb 1999 11:56:35 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA04833 for ipsec-outgoing; Fri, 26 Feb 1999 12:36:39 -0500 (EST) Message-Id: <3.0.5.32.19990226195853.00b21990@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 26 Feb 1999 19:58:53 +0200 To: ipsec@tis.com From: Joern Sierwald Subject: RE: IPSEC stress tester? In-Reply-To: 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 portal.ex.tis.com id MAA04830 Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:56 26.2.1999 -0500, you wrote: >The tests outlined below I would consider IPSEC compliance tests. I believe >that the Anvil product from Midnight Networks now supports these type of >tests. However, the original question appeared to address performance >metrics for various IPSEC solutions. I agree with Paul that these tests fall >into two main categories, throughput and SAs. Throughput testing is pretty >straight forward. All you need is something to generate traffic (i.e. >SmartBits) at various packet sizes and rates through an SA. The results will >tell you both packet forwarding and bulk encryption limitations. > >The max SA test is the tricky one. I am familiar with some larger vendors >that have built rooms with over a hundred PCs each running scripts to >establish 10 to 20 SAs. This is not practical for most organizations. >Therefore, I am forced to take the word of the vendor that a particular box >can handle X number of simultaneous SAs. This is becoming an increasingly >critical issue as service providers look for solutions to support 10s of >thousands of simultaneous encrypted connections. There must be someone out >there who has come up with a reasonably elegant solution to this problem. > You simply use a host-to-gateway setup, two computers. You generate a policy that says that behind the gateway there are a lot of networks, say 10.0.0.1/32, 10.0.0.2/32...... Now ping all networks from the client. One pair of IPsec SAs is generated for each ping. This generates only one ISAKMP SA, though. Jörn From owner-ipsec@portal.ex.tis.com Fri Feb 26 11:57:59 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA04997; Fri, 26 Feb 1999 11:57:59 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA04800 for ipsec-outgoing; Fri, 26 Feb 1999 12:24:39 -0500 (EST) Date: Fri, 26 Feb 1999 20:40:35 +0900 (JST) From: Shoichi Sakane Message-Id: <199902261140.UAA00608@Israel.cct.ydc.co.jp> To: suresh@livingston.com Cc: ipsec@tis.com Subject: Re: Looking for an IPsec packet analyzer In-Reply-To: Your message of "Thu, 25 Feb 1999 18:22:56 -0800 (PST)" <199902260222.SAA09018@kc.livingston.com> References: <199902260222.SAA09018@kc.livingston.com> X-Mailer: Cue version 0.5 (990225-2313/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipsec@ex.tis.com Precedence: bulk > Can someone point me to one or more vendors that provide IPsec and > IKE trafiic decoding in their traffic analyser software? > Specifically, I am looking for the following: > 1. IPSec AH and ESP header decoding > 2. IKE header and payload decoding (while in the clear) There is tcpdump in KAME that is IPv6/IPsec stack for BSD*. KAME's tcpdump can decode some packet of both IKE in part of phase 1 and IPsec. Please refer to http://www.kame.net/ /Shoichi `NE' Sakane/ From owner-ipsec@portal.ex.tis.com Fri Feb 26 12:16:45 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA05143; Fri, 26 Feb 1999 12:16:44 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA04678 for ipsec-outgoing; Fri, 26 Feb 1999 11:59:44 -0500 (EST) Message-Id: <3.0.5.32.19990226113241.00831a90@bl-mail2.corpeast.baynetworks.com> X-Sender: thardjon@bl-mail2.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Fri, 26 Feb 1999 11:32:41 -0800 To: ipsec@tis.com From: Thomas_Hardjono@BayNetworks.COM (Thomas Hardjono) Subject: draft-irtf-smug-gsadef-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk --------------------------------------------------------------------------- Internet Engineering Task Force Indermohan Monga INTERNET-DRAFT Thomas Hardjono draft-irtf-smug-gsadef-00.txt Nortel Networks February 25, 1999 Expires August 25, 1999 Group Security Association (GSA) Definition for IP Multicast Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document provides a definition of the Group Security Association (GSA) for IP multicast, derived from the Security Association (SA) definition for unicast. The document describes the motivations of a GSA and other issues related to the GSA usage in the context of the existing IPsec implementations. 1. Introduction The current document delves into the issue of the use of IPsec [KA98a] security associations (SA) in the context of IP multicast. Unlike the traditional unicast IPsec, multicast groups can have one or more senders, and one or more receivers. In the unicast IPsec, the SA parameters are negotiated between the sender and the receiver, where the receiver selects the Security Parameters Index (SPI) that make-up the SA. Monga, Hardjono [Page 1] INTERNET DRAFT 25 February 1999 The concept of an IPsec Security Association cannot be easily mapped without modifications to the multicast environment due the nature of group-oriented communications. As an example, in the unicast case it is the receiver that selects the SPI related to that instance of communications. In multicast, however, there can be more than one receiver, and hence arises the issue of who selects the SPI. In the remainder of the document we present the concepts and motivations underlying the current proposal for a GSA aimed at the 1-to-Many multicast. Other issues related to the 1-to-Many and Many-to-Many multicast, and issues specific to a "Multicast IPsec" (MIPsec) are also discussed. 2. Multicast Security Associations: Concept The concept of multicast Security Associations was introduced in the Security Architecture document of [KA98a] and further elucidated in the group key management proposal of [HCM98]. The idea is that unlike security associations for one-to-one unicast communications, the security association for a collection of communicating entities will be shared by more than two entities. Hence the notion of a "Group" Security Association (GSA). In the current document we focus on the unidirectional 1-to-Many (1-to-M) multicast applications type, since it represents the simplest group communications behavior. This does not preclude further developments to address the Many-to-Many multicast application type. In the current document we propose the design and composition of a GSA that will make most use of the previous unicast Security Association (SA) definition of [KA98a] for one-to-one communications. The motivation behind this philosophy is to allow the existing developments of IPsec to be employed for IP multicast with minimum modification. Unlike the security association in unicast communications where a well-defined entity (eg. the receiver) selects some of the parameters (eg. algorithm, security parameters index or SPI) that make-up the security association, in multicast groups consisting of multiple senders and receivers there is need for a single entity to choose the parameters that make-up the group security association (GSA). In the current document we propose that the security parameter index (SPI) of the GSA for a 1-to-Many multicast be selected by an entity involved in the initial steps of the multicast group creation and group key management. The SA parameters are either chosen by the sender or are well known fixed properties of the group. For example, a multicast group A.B.C.D started by a sender E.F.G.H might have fixed security characteristics of 3DES encryption with MD5 authentication. Monga, Hardjono [Page 2] INTERNET DRAFT 25 February 1999 Two possible entities can be defined to select the SPI and/or the group-key: (a) The single sender in the 1-to-Many multicast (b) A key-management entity, such as the Domain Key Distributor (DKD) in [HCM98]. Regardless of which entity selects the SPI and the group-key, one fundamental issue that remains is the dissemination of the selected parameters to the other members (receivers) of the multicast group. Since the key-management entities involved in the group-key management (GKM) protocol will be disseminating the group-key to the group members, we relegate the task of disseminating the GSA to these same entities, either through (or part of) the same GKM protocol or through a different GSA distribution protocol executed by these entities. 3. GSA for Multicast The current work proposes a definition of a GSA based on the source IP address. A GSA will be uniquely identified by the tuple (source IP address, SPI and protocol). This mirrors the tuple (destination IP address, SPI and protocol) used to uniquely identify unicast SAs (USA). There are a number motivating reasons for using the source IP address in a GSA: 1. The current work seeks to address the demand today for IP multicast, which in most cases (if not all) consists of the 1- to-Many multicast. 2. Using the source IP address approach ensures that existing IPsec implementations will not need to change their storage or access mechanisms to their SA Database (SAD). 3. Some multicast routing protocols only admit the creation of 1- to-Many multicast groups (eg. PIMv2), with a unidirectional distribution tree towards the receivers at the leafs of the tree. Assuming a 1-to-Many multicast routing protocol (eg. PIMv2) is deployed, then source-authentication is provided as an inherent part of a (GSA, group-key) pair. Since the underlying 1-to-M multicast routing protocol only admits a single sender as part of its source access-control and since only the valid single sender knows the group-key for that 1-to-Many multicast, it follows that sender-authentication to the receivers is achieved. Even if a dishonest receiver holding the group-key attempts to send to the group, the multicast distribution tree itself may not permit this. Monga, Hardjono [Page 3] INTERNET DRAFT 25 February 1999 4. The anti-replay features of IPsec can still be deployed. Since there is only a single source per GSA, consistency and monotonicity of the sequence number can be guaranteed. Note, that, if a host is a sender for more than one 1-to-M multicast groups, the sender needs to make sure that the SPI is different for each GSA is uses. Note also, that the current approach to defining the GSA solves some of the issues raised by [CCP99] (Section 6). There are two general types of multicast: one-to-many and many-to- many. The one-to-many multicast involves one sender sending data via multicast to the members (receivers) of the group. The many-to-many multicast group assumes that each member of the multicast group can become a sender of data to the multicast group if it so chooses. The two cases are discussed in the sections below in the context of the GSA usage. 3.1 One-to-Many Multicast Only one fixed sender sends multicast data using one GSA for the group. The receivers in the multicast group save the (received) GSA in the inbound SAD. On receiving an encrypted packet, the source IP address, SPI and protocol from the packet are used to retrieve the proper GSA from the inbound SAD to decrypt the packet. 3.2 Many-to-Many Multicast The case of the Many-to-Many multicast is more complex since multiple senders may exist and thus a mechanism to determine (negotiate) the parameters among the multiple senders must be employed. Unlike the 1-to-Many multicast, the Many-to-Many can involve more than one sender, and in reality the number of active receivers can even be less than the number of sender (ie. some senders are not receivers). The current document places the issue of Many-to-Many for later work. Some points of consideration concern the behavior of the underlying multicast routing protocol with respect to the current definition of security associations for groups. As mentioned above, some multicast routing protocols only admit the creation of 1-to-Many multicast groups, with a unidirectional distribution tree towards the receivers at the leafs of the tree. With such multicast routing protocols, the creation of a M-to-M multicast can be effected through the overlaying M of the 1-to-M multicast. Monga, Hardjono [Page 4] INTERNET DRAFT 25 February 1999 If such is the case with the multicast routing protocol, then each of the M layers (consisting of a 1-to-M multicast) can be served with a separate GSA. In essence, each receiver must maintain M GSAs (and M group-keys) corresponding to the M individual sources/senders. Although at first this may appear to be a possible overhead, there are some advantages of using M layers of the 1-to- Many multicast. The first advantage, as mentioned previously, is that source- authentication is provided as an inherent part of a (GSA, group-key) pair. The second advantage, is that having M separate 1-to-Many multicasts allows a receiver to choose particular sources from which it wishes to hear. This selective reception of sources can be done by the receiver simply opting not to join one (or several) 1-to-M multicast, or it can be performed on a policy-basis by the local administration. This approach also falls inline with the future promise of IGMPv3 [CDT99] in which a host has the option of specifying with sources of a multicast group it wishes to listen to, through IGMPv3. The third advantage, which ties into the first, is that the anti- replay features of IPsec can still be deployed in each of the 1-to-M multicast layers of the M-to-M multicast. 3.3 Dissemination of 1-to-Many GSAa In the context of a 1-to-M multicast group, an important issue that needs to be addressed is that of the dissemination of the GSA to the M receivers in the group. Assuming that the sender is already in possession of the GSA, one possible mechanism to deliver the GSA to the M receivers is through the same method as the group-key delivery. The motivation here is that since the GKM protocol is already delivering a crucial piece of information (the group-key) and is trusted to do so, then it makes sense for the delivery of the GSA to be coupled to the delivery of the group-key matching the GSA. Note a GSA must be coupled with its respective group-key. Thus, when a group-key is to be re-keyed, a new SPI must be created, and thus a new GSA. Hence, in the current work we propose the delivery of the group-key and its GSA as a single unit. 3.4 GSA Parameters This sections discusses certain unicast SA parameters [KA98a] which have a direct bearing on MIPsec. Monga, Hardjono [Page 5] INTERNET DRAFT 25 February 1999 - IPsec Protocol Mode: The IP security architecture describes two different types of IPsec SAs: tunnel and transport. A transport mode SA is used to securely communicate between two hosts. A tunnel mode SA is used to protect communication between two security gateways or between a security gateway and a host. Since members of a multicast group are assumed to be end-hosts, we propose that GSAs be defined for transport mode only. Note that this decision does not prevent multicast traffic being tunneled over a set of unicast IPSec SAs. Furthermore, this does not preclude the possibility of a gateway entity in itself becoming an "end-host" of a multicast group. - Anti-replay window: All multicast receivers are REQUIRED to implement this window. - AH Authentication algorithm, keys, ESP Encryption algorithm, authentication algorithm, keys etc: Unlike IPSec SAs, these parameters are not negotiated but generated by the sender(s) of the multicast group or a DKD entity [HCM98] and propagated to the multicast receivers using GKM protocol. - Lifetime of GSA: The sender MUST choose the time interval the GSAs are valid, whether they be time based or kilobyte based. The sender is responsible for taking the appropriate action, either creating a new GSA or terminating the existing GSA, when the existing GSA expires. The receivers are NOT REQUIRED to track the lifetime of the GSA. The GSA lifetime must be constrained by the validity of the senders certificate, if that is provided in the GSA. 3.5 Combining GSAs Multicast senders and receivers MUST support transport adjacency of GSAs as described in Section 4.3 of IPsec Security Architecture [KA98a]. They are NOT REQUIRED to support iterated tunneling. 4. Security Association Database The concept of GSAs integrates seamlessly with the SAD concept described in the IPSec Security Architecture document[KA98a]. Since GSAs have the same number of unique parameters which are of same/similar type, GSAs can be stored/accessed from the same SAD meant for unicast IPSec SAs. This reduces the complexity of multicast security implementation in the client. Monga, Hardjono [Page 6] INTERNET DRAFT 25 February 1999 5. References [HCM98] T. Hardjono, B. Cain and I. Monga, "Intra-Domain Group Key Management Protocol", Internet Draft, July 1998. draft-ietf-ipsec-intragkm-00.txt [KA98a] S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol", IETF, RFC 2401, 1998. [CDT99] B. Cain, S. Deering and A. Thyagarajan, "Internet Group Management Protocol, Version 3", Internet Draft, February 1999. draft-ietf-idmr-igmp-v3-01.txt [CCP99] R. Canetti, P-C. Cheng, D. Pendarakis, J.R. Rao, P.Rohatgi and D. Saha, "An Architecture for Secure Internet Multicast". Internet Draft, February 1999. draft-irtf-smug-sec-mcast-arch-00.txt 6. Author Addresses Inder Monga Email: imonga@baynetworks.com Thomas Hardjono Email: thardjono@baynetworks.com Nortel Networks 3 Federal Street, Bl3-03 Billerica, MA 01821, USA Tel: +1-978-916-4538 Monga, Hardjono [Page 7] --------------------------------------------------------------------------- From owner-ipsec@portal.ex.tis.com Fri Feb 26 12:49:09 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA05521; Fri, 26 Feb 1999 12:49:09 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA05048 for ipsec-outgoing; Fri, 26 Feb 1999 13:26:40 -0500 (EST) Message-ID: <36D6ED25.CC4DDC78@assured-digital.com> Date: Fri, 26 Feb 1999 13:51:17 -0500 From: Andrew Sweeney X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "ipsec@tis.com" Subject: Client ID 0.0.0.0 Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, I am a gateway running in tunnel mode. What does an advertised client ID of 0.0.0.0 type IPV4_ADDR or 0.0.0.0/0.0.0.0 type IPV4_SUBNET mean? It is my belief that this is telling me that the SA being established allows access to all networks that my gateway knows about. Is this correct? Andy -- Andrew Sweeney andy@assured-digital.com 9 Goldsmith Street, Littleton, MA 01460 http://www.assured-digital.com/ From owner-ipsec@portal.ex.tis.com Fri Feb 26 15:16:02 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA06953; Fri, 26 Feb 1999 15:16:02 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA05752 for ipsec-outgoing; Fri, 26 Feb 1999 15:42:42 -0500 (EST) Message-ID: <19990226204503.25372.rocketmail@send501.yahoomail.com> Date: Fri, 26 Feb 1999 12:45:03 -0800 (PST) From: CNJ CNJ Subject: RE: IPSEC stress tester? To: Stephen.Waters@cabletron.com Cc: ipsec@tis.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by clipper.hq.tis.com id PAA24681 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA05522 Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen, I read that Time Step has a tool kit that ICSA is using to test and help certify IPSec products. http://www.zdnet.com/products/stories/reviews/0,4161,360488,00.html I have been unable to find out details about this tool kit. Perhaps someone from Time Step is on this forum and can address for all of us about this tool kit and how it can be obtained. Debbie Beers Thanks for all the replies. I guess what I’m looking for is a test suite that has knowledge of the IPSEC/IKE protocols and tries to expose weaknesses. Some simple examples could be:  sending ESP/AH packets to various SPI values  creating IPSEC-SA with IKE, and then sending corrupted ESP/AH packet (man-in-the-middle tests)  replay attacks  pre-shared key guessing for Phase1 break-in attempts  sending in ESP packets that contain IP packets not covered by the Phase-2 negotiation  ‘exploding’ IPCOMP packets We could probably come up with a fairly long list between us. I would like to see such a tool so that VPN CPE customers can sleep at nights knowing their CPE has passed these tests. So far, I’ve tried tools intended for firewall testing, and, as you would expect, they don’t do much with a router that is armed with IPSEC. This sounds like an opportunity for someone. From the number of holes I’ve had to fix in our IPSEC implementation, this someone probably works for a company with IPSEC products. Steve. -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Thursday, February 25, 1999 9:41 PM To: Waters, Stephen; ‘ipsec@tis.com’ Subject: Re: IPSEC stress tester? I’m looking for a test suite that will stress-test an IPSEC security gateway. Can anyone recommend something? If the product doesn’t exist, maybe a service does? I would prefer a product that I can re-use at my leisure as part of a regression test program. Depends on what you mean by “stress test”. There are at least two orthogonal types of stress tests people have proposed: speed and number/type of SAs. Creating software/hardware to test either type of stress is easy; creating tests that are useful in the real world is probably difficult without discussion from many vendors and customers. A few companies have suggested that VPNC create some standard stress-testing regimen, not so that someone can say “Product A runs faster under stress than Product B”, but so they ca say “if you put Product C on one end of an Internet connection with a line speed of N, you can be sure that the line speed will limit you sooner than the processing power of Product C”. Once VPNC gets up and running, I hope that the members will want to discuss this more, and that we make the results public so that anyone can run the tests themselves.  Paul Hoffman, Director  VPN Consortium _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ipsec@portal.ex.tis.com Fri Feb 26 15:16:13 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA06961; Fri, 26 Feb 1999 15:16:12 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA05802 for ipsec-outgoing; Fri, 26 Feb 1999 15:59:43 -0500 (EST) Message-Id: <4.1.19990226221359.00a41400@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 26 Feb 1999 22:14:51 +0100 To: suresh@livingston.com (Pyda Srisuresh), ipsec@tis.com From: Eric Vyncke Subject: Re: Looking for an IPsec packet analyzer Cc: suresh@livingston.com (Pyda Srisuresh) In-Reply-To: <199902260222.SAA09018@kc.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Have a look at http://www.ping.be/ethload and use the latest beta to get some IPSec+IKE decoding. Beware, this tool runs on the MS-DOS... :-) -eric At 18:22 25/02/99 -0800, Pyda Srisuresh wrote: > >Hi, > >Can someone point me to one or more vendors that provide IPsec and >IKE trafiic decoding in their traffic analyser software? >Specifically, I am looking for the following: > > 1. IPSec AH and ESP header decoding > 2. IKE header and payload decoding (while in the clear) > >Thanks. > >cheers, >suresh Eric Vyncke Cisco Systems Belgium SA/NV Phone: +32-2-778.4677 Fax: +32-2-778.4300 E-mail: evyncke@cisco.com Mobile: +32-75-312.458 From owner-ipsec@portal.ex.tis.com Fri Feb 26 15:55:27 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA07471; Fri, 26 Feb 1999 15:55:26 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA05978 for ipsec-outgoing; Fri, 26 Feb 1999 16:41:42 -0500 (EST) Message-ID: <36D71A4C.ABA51743@redcreek.com> Date: Fri, 26 Feb 1999 14:03:56 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Sweeney CC: "ipsec@tis.com" Subject: Re: Client ID 0.0.0.0 Question References: <36D6ED25.CC4DDC78@assured-digital.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Andrew Sweeney wrote: > > Hi, > > I am a gateway running in tunnel mode. > > What does an advertised client ID of 0.0.0.0 type IPV4_ADDR or > 0.0.0.0/0.0.0.0 type IPV4_SUBNET mean? > > It is my belief that this is telling me that the SA being established > allows access to all networks that my gateway knows about. > > Is this correct? > > Andy Personally, I think that this is illegal. From RFC2409, The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode. If ISAKMP is acting as a client negotiator on behalf of another party, the identities of the parties MUST be passed as IDci and then IDcr. Local policy will dictate whether the proposals are acceptable for the identities specified. If the client identities are not acceptable to the Quick Mode responder (due to policy or other reasons), a Notify payload with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. If you specify 0.0.0.0, you are claiming to be representing *everyone* else, including me. Scott From owner-ipsec@portal.ex.tis.com Sat Feb 27 07:29:41 1999 Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA14085; Sat, 27 Feb 1999 07:29:41 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA08181 for ipsec-outgoing; Sat, 27 Feb 1999 08:03:43 -0500 (EST) Message-ID: <29752A74B6C5D211A4920090273CA3DC031EC7@new-exc1.ctron.com> From: "Waters, Stephen" To: "'Shoichi Sakane'" Cc: "'ipsec@tis.com'" Subject: RE: Looking for an IPsec packet analyzer Date: Sat, 27 Feb 1999 13:24:10 -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@ex.tis.com Precedence: bulk Anyone wanted to trace/decode just the headers (without having a clue of the contents - which would mostly be encrypted), then you can use any one of the IPSEC routers out there that has ISAKMP/ESP/AH protocol analysis: Target device-----------IPSEC router-----------IPSEC source The ISAKMP/ESP/AH pacjets passing through 'IPSEC router' could then be analysed by its protocol trace engine. We have a GUI tool that provides ISAKMP/ESP/AH decode in full colour, but it's not a LAN sniffer as such. If anyone is interested, I can send an example ISAKMP analysis. Steve. -----Original Message----- From: Shoichi Sakane [mailto:sakane@ydc.co.jp] Sent: Friday, February 26, 1999 11:41 AM To: suresh@livingston.com Cc: ipsec@tis.com Subject: Re: Looking for an IPsec packet analyzer > Can someone point me to one or more vendors that provide IPsec and > IKE trafiic decoding in their traffic analyser software? > Specifically, I am looking for the following: > 1. IPSec AH and ESP header decoding > 2. IKE header and payload decoding (while in the clear) There is tcpdump in KAME that is IPv6/IPsec stack for BSD*. KAME's tcpdump can decode some packet of both IKE in part of phase 1 and IPsec. Please refer to http://www.kame.net/ /Shoichi `NE' Sakane/