From owner-ipsec@portal.ex.tis.com Mon Mar 1 05:44: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 FAA10332; Mon, 1 Mar 1999 05:44:57 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id FAA12911 for ipsec-outgoing; Mon, 1 Mar 1999 05:09:34 -0500 (EST) Message-ID: <36DA6CD7.905F8CFF@utimaco.co.at> Date: Mon, 01 Mar 1999 11:32:55 +0100 From: Michael Schmidt Organization: Utimaco Safe Concept GmbH X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,de-DE, de-AU MIME-Version: 1.0 To: ipsec@tis.com Subject: KAME & transform source codes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, After checking the source code of the KAME IKE project (kame-19990131-fbsd228-stable.tgz) out of the KAME FTP server, I wasn't able to locate the source files for the AH/ESP transforms as well as the source codes for the encryption algorithms (OK, I understand that crypto export restrictions may come into play here). Anyway, where would I find the transform (and the other missing source codes)? Are the transforms part of the FreeBSD kernel? I couldn't find them in the FreeBSD 3.0 source code tree? Thanks for any help in advance! Michael -- Michael Schmidt | Utimaco Safe Concept GmbH | Tel: ++43 732 655 755 - 35 Europaplatz 6 | Fax: ++43 732 655 755 - 5 A-4020 Linz, Austria | E-Mail: Michael.Schmidt@utimaco.co.at From owner-ipsec@portal.ex.tis.com Mon Mar 1 08:20: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 IAA11471; Mon, 1 Mar 1999 08:20:46 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA13356 for ipsec-outgoing; Mon, 1 Mar 1999 08:25:39 -0500 (EST) Comments: Authenticated sender is From: "heilmann" To: ipsec@tis.com Date: Mon, 1 Mar 1999 14:45:50 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: UDP / Identifying ISAKMP message X-mailer: Pegasus Mail for Win32 (v2.54DE) Message-ID: <19990301134546.AAA28967@iabgmh.iabg.de@cc31nb05> Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, two general questions concerning IPSec and ISAKMP: 1.) How can the IP layer be determine if a certain IPv6 PDU is (part of) an ISAKMP message? 2.) Are there any special reasons, why ISAKMP hasn't simply been assigned a "Next Header" number for IPv6 - so that it could run directly over IP itself? I'm implementing some basic functionality of ISAKMP for my master's thesis and these questions occur several times. Thanks for any help! Martin ------------------------------------------------------------------ Martin Heilmann IABG mbH, CS31 Tel. 089 - 6088 3954 Einsteinstrasse 20 E-Mail: heilmann@iabg.de 85521 Ottobrunn From owner-ipsec@portal.ex.tis.com Mon Mar 1 08:20: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 IAA11479; Mon, 1 Mar 1999 08:20:54 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA13330 for ipsec-outgoing; Mon, 1 Mar 1999 08:24:31 -0500 (EST) Message-Id: <3.0.6.32.19990301134620.0096e260@stmail01.cubis.de> X-Sender: martius@stmail01.cubis.de X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 01 Mar 1999 13:46:20 +0100 To: Michael Schmidt From: Kai Martius Subject: Re: KAME & transform source codes Cc: ipsec@tis.com In-Reply-To: <36DA6CD7.905F8CFF@utimaco.co.at> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, At 11:32 01.03.99 +0100, you wrote: >After checking the source code of the KAME IKE project >(kame-19990131-fbsd228-stable.tgz) out of the KAME FTP server, I wasn't >able >to locate the source files for the AH/ESP transforms as well as the >source >codes for the encryption algorithms (OK, I understand that crypto export > >restrictions may come into play here). Everything is packaged in the huge sys-diff-file... No export laws apply to KAME, as far as I know. Kai ################################################################## Kai Martius secunet Security Networks GmbH, Dresden (previous) homepage, IPSec-related stuff and PGP keys under: http://www.imib.med.tu-dresden.de/imib/personal/kai.html ################################################################## From owner-ipsec@portal.ex.tis.com Mon Mar 1 08:23: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 IAA11499; Mon, 1 Mar 1999 08:23:28 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA13344 for ipsec-outgoing; Mon, 1 Mar 1999 08:25:34 -0500 (EST) Message-ID: <36D9DEC7.6B3356DE@mail1.sjtu.edu.cn> Date: Mon, 01 Mar 1999 08:26:47 +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=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Dear ipsec@tis.com, I am a student from China, and am interested in IPsec. I have some questions: o Should the protocol algorithm be specified in SPD entries?What would a SPD entry look like? o in the proccessing of inbound traffic,RFC2401 says: 4. Check whether the required IPsec processing has been applied, i.e., verify that the SA's found in (1) and (2) match the kind and order of SAs required by the policy found in (3). I wonder,what does "the kind and order of SAs" mean? does "kind" encompass the IPsec protocol, the algorithm used,key length,IV mode,etc.? o Because of the directionality of SA, does this mean that the initiator of the SA setup associated with the inbound connection should be the peer while the outbound connection the local host or SGW? o If the peer ISAKMP deamon initiates the SA setup, the host or SGW should check the SA against corresponding SPD entry? say, the SGW x calls y for setup SA, should y check whether the proposed SA by x satifies the policy about the traffice between x and y? if so,the ISAKMP payload should carry the information to guide the responder to choose which SPD entry to check the proposed SA, but neither IKE nor Oakley transforms such information to the peer. o After machine booting up,should the ISAKMP deamon actively setup SAs according to local SPD, or just passively waiting for the kernel IPsec module to send KEY_ACQUIRE request? THANKS & REGARDS Wang Huaibo 29/2 From owner-ipsec@portal.ex.tis.com Mon Mar 1 08:43: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 IAA11658; Mon, 1 Mar 1999 08:43:01 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA13159 for ipsec-outgoing; Mon, 1 Mar 1999 07:45:33 -0500 (EST) Message-ID: <36DA9142.993D7031@utimaco.co.at> Date: Mon, 01 Mar 1999 14:08:18 +0100 From: Michael Schmidt Organization: Utimaco Safe Concept GmbH X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,de-DE, de-AU MIME-Version: 1.0 To: Kai Martius CC: ipsec@tis.com Subject: Re: KAME & transform source codes References: <3.0.6.32.19990301134620.0096e260@stmail01.cubis.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Kai, Thanks a lot! Once again, I'm exposing myself as a bloody UNIX amateur, spoilt by M$ ;-) Michael > Hi, > > At 11:32 01.03.99 +0100, you wrote: > >After checking the source code of the KAME IKE project > >(kame-19990131-fbsd228-stable.tgz) out of the KAME FTP server, I wasn't > >able > >to locate the source files for the AH/ESP transforms as well as the > >source > >codes for the encryption algorithms (OK, I understand that crypto export > > > >restrictions may come into play here). > > Everything is packaged in the huge sys-diff-file... No export laws apply to > KAME, as far as I know. > > Kai -- Michael Schmidt | Utimaco Safe Concept GmbH | Tel: ++43 732 655 755 - 35 Europaplatz 6 | Fax: ++43 732 655 755 - 5 A-4020 Linz, Austria | E-Mail: Michael.Schmidt@utimaco.co.at From owner-ipsec@portal.ex.tis.com Mon Mar 1 22:07: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 WAA02587; Mon, 1 Mar 1999 22:06:59 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id WAA16559 for ipsec-outgoing; Mon, 1 Mar 1999 22:35:41 -0500 (EST) Message-ID: From: Bryan Gleeson To: vpn@BayNetworks.COM Cc: l2tp@ipsec.org, ipsec@tis.com, mpls@uu.net Subject: draft-gleeson-vpn-framework-01.txt Date: Mon, 1 Mar 1999 19:54:34 -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 The draft "A Framework for IP based Virtual Private Networks" has been updated. It is available at http://www.shastanets.com/company/PDFs/draft-gleeson-vpn-framework-01.txt and should shortly be available in the Internet Draft directories. It has been updated to reflect and reference some of the vpn related work done since the previous version, notably the VPN-ID draft , and a number of specific VPN proposals (a number of which were presented at the last IETF). It also covers extranets and discusses the issues surounding voluntary tunneling in considerably more detail. As before, the intent is that this should provide a framework for discussion of the vpn related standards work needed by the IETF. Unfortunately there is no VPN WG as such in which to discuss the draft and some of the issues it raises, however we intend to submit the draft for publication as an Informational RFC, and would welcome any comments anyone may have. One issue in particular that is raised in the draft and that has been the focus of some recent L2TP/IPSEC mailing list activity is that of the the protocol stack to be used for secure remote access using voluntary tunneling (i.e. choice of PPP/L2TP/UDP/IPSEC/IP, or IPSEC/IP with the "xauth" extensions, or PPP directly over IPSEC, or perhaps some other combination). Right now there are quite a number of proprietary client solutions commercially available, so this area is one that would certainly benefit from some work in order to allow for interoperable implementations. Bryan Gleeson Shasta Networks From owner-ipsec@portal.ex.tis.com Mon Mar 1 22:34: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 WAA04099; Mon, 1 Mar 1999 22:34:23 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA16662 for ipsec-outgoing; Mon, 1 Mar 1999 23:30:43 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81E28@RED-MSG-50> From: Richard Draves To: "'Mobile IP'" , "'IPsec'" , "'IPng List'" Subject: RE: (IPng 7211) RE: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Mon, 1 Mar 1999 20:52:00 -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. > > 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. Well, it seems we have consensus on the above points. On to something more interesting & perhaps more controversial: what IPsec processing should a correspondent node perform when sending to a mobile node? My first email on this subject suggested that a correspondent node should perform outbound IPsec processing twice: first looking up a security policy using the home address as the destination address selector and applying the resulting security associations, and then doing another security policy database lookup using the care-of address as the destination address selector and applying the additional security associations. However after thinking about more scenarios, it's clear that's too simplistic. I still think two outbound SPD lookups are necessary, using the home address and the care-of address as the destination address selectors, but the results of the two lookups must be *spliced* instead of just concatenated. An assumption here: I believe that it's impractical for a correspondent node to update its security policy database to handle the movement of mobile nodes. The way this works without IPsec: a correspondent node CN is sending to a mobile node with a home address HA. CN looks in its Binding Cache and discovers a care-of address CA associated with the home address. CN sends the packet with a routing header: IPv6 hdr - src CN, dst CA Routing hdr - segs left = 1, HA Transport hdr So let's consider two scenarios with IPsec. In the first scenario, the correspondent node has a transport-mode AH association with the home address. The correpondent node sends packets that look like IPv6 hdr - src CN, dst HA AH hdr - transport-mode SA CN -> HA Transport hdr Then the correspondent node learns that the mobile node has moved. The SPD in the correspondent says that the care-of address is behind a security gateway SG. A tunnel-mode ESP association with SG is required to reach the care-of address. Now the correspondent node sends packets that look like IPv6 hdr - src CN, dst SG ESP hdr - tunnel-mode SA CN -> SG IPv6 hdr - src CN, dst CA Routing hdr - segs left = 1, HA AH hdr - transport-mode SA CN -> HA Transport hdr Note that the correspondent node must do two outbound SPD lookups - one using HA as the destination address selector, and another using CA as the destination address selector - to discover both of the security associations. In the second scenario, the mobile node's home address is behind a security gateway SG1. The correspondent node uses a tunnel-mode ESP association with SG1 to reach the home address. So the correspondent node sends packets that look like IPv6 hdr - src CN, dst SG1 ESP hdr - tunnel-mode SA CN -> SG1 IPv6 hdr - src CN, dst HA Transport hdr Then the correspondent node learns that the mobile node has moved. The SPD in the correspondent says that the care-of address is behind a different security gateway SG2. The correspondent node must use a tunnel-mode ESP association with SG2 to reach the care-of address. So the correspondent node sends packets that look like IPv6 hdr - src CN, dst SG2 ESP hdr - tunnel-mode SA CN -> SG2 IPv6 hdr - src CN, dst CA Routing hdr - segs left = 1, HA Transport hdr In this scenario, the security policy used with the home address is not used when sending to the care-of address, while in the first scenario it is. What's the difference? The difference is that in the first scenario, the correspondent node has a security association directly with the home address, while in this second scenario the association is with a security gateway. I think the correspondent node must do two outbound SPD lookups, using both the home address (lookup #1) and care-of address (lookup #2) as destination address selectors. Then the results of the two lookups are combined. Associations directly with the home address (might be transport-mode or tunnel-mode) are taken from the first lookup, and associations with intermediate security gateways (always tunnel-mode) are taken from the second lookup. Then the headers from the security associations are combined with a routing header as follows: IPv6 hdr - src CN, dst CA Routing hdr - segs left = 1, HA Transport hdr How does this sound? Rich From owner-ipsec@portal.ex.tis.com Tue Mar 2 08:56: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 IAA20336; Tue, 2 Mar 1999 08:56:03 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA18087 for ipsec-outgoing; Tue, 2 Mar 1999 08:45:39 -0500 (EST) Message-Id: <3.0.6.32.19990302193159.012698f0@hydmail> X-Sender: rohit@hydmail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 02 Mar 1999 19:31:59 To: Wang Huaibo From: Rohit Subject: Re: HELP Cc: ipsec@tis.com In-Reply-To: <36D9DEC7.6B3356DE@mail1.sjtu.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 08:26 AM 3/1/99 +0800, you wrote: >Dear ipsec@tis.com, > I am a student from China, and am interested in IPsec. > I have some questions: > o Should the protocol algorithm be specified in SPD > entries?What would a SPD entry look like? Yes! you can specify protocol algorithm in the SPD entry. SPD Entry may look like a collection of protocol to be applied (AH/ESP), mode (Trans/tunnel)mode, algorithm to be applied, the combination in which this protocol is applied etc. > o in the proccessing of inbound traffic,RFC2401 says: > > 4. Check whether the required IPsec processing has been > applied, i.e., verify that the SA's found in (1) and (2) > match the kind and order of SAs required by the policy > found in (3). > > I wonder,what does "the kind and order of SAs" mean? > does "kind" encompass the IPsec protocol, the algorithm > used,key length,IV mode,etc.? "kind" means whether the SA applied matches the the SA you find attached to the matched inbound policy. The "order of SA" means to check whether the order in which the SAs are specified in the Policy is same as you have applied to the incoming packet to decrypt/deauthenticate it. > > o Because of the directionality of SA, does this mean > that the initiator of the SA setup associated with > the inbound connection should be the peer while > the outbound connection the local host or SGW? 'am sorry, can you be much clear on this! still let me try it. I think in either directions if the host is ipsec capable you can have security upto that, if you are protecting a non ipsec host by a SGW then SGW will take part in the negotiatons and establishment of SAs. > o If the peer ISAKMP deamon initiates the SA setup, > the host or SGW should check the SA against > corresponding SPD entry? say, the SGW x calls y > for setup SA, should y check whether the proposed > SA by x satifies the policy about the traffice > between x and y? if so,the ISAKMP payload should > carry the information to guide the responder > to choose which SPD entry to check the proposed SA, > but neither IKE nor Oakley transforms such information > to the peer. You are supposed to extract the selectors from the packet and use them (by reverting the selectors if needed) to select a matching inbound policy( in phase 2 negotiaions if i am not wrong!) > o After machine booting up,should the ISAKMP deamon > actively setup SAs according to local SPD, or just > passively waiting for the kernel IPsec module to > send KEY_ACQUIRE request? Ideally it should wait for Key_acquire request. Hope this will help ! -Rohit Rohit Aradhya Software Engineer Motorola (I) Electronics Ltd TSR Towers, Rajbhavan Road Somajiguda Hyderabad From owner-ipsec@portal.ex.tis.com Wed Mar 3 11:15: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 LAA09165; Wed, 3 Mar 1999 11:15:03 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA23255 for ipsec-outgoing; Wed, 3 Mar 1999 10:20:55 -0500 (EST) Message-Id: <199903031541.KAA08191@anuxc.mv.lucent.com> X-Sender: dac@anuxc.mv.lucent.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 03 Mar 1999 10:43:44 -0600 To: ipsec@tis.com From: Dave Clark Subject: IKE HASH(3) payload Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello; Why does the IKE Quick Mode HASH(3) not include any chained payloads such as Notification and Delete? - thanks in advance; Dave Clark From owner-ipsec@portal.ex.tis.com Wed Mar 3 16:31: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 QAA16972; Wed, 3 Mar 1999 16:31:35 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA24776 for ipsec-outgoing; Wed, 3 Mar 1999 17:01:05 -0500 (EST) Message-Id: <199903032212.RAA21083@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com@tis.com;;;;;;;; From: Internet-Drafts@ietf.org cc: smug@external.cisco.com, ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-irtf-smug-sec-mcast-arch-00.txt (re-send) Date: Wed, 03 Mar 1999 17:12:24 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Architecture for Secure Internet Multicast Author(s) : R. Canetti, P. Cheng, D. Pendarakis, J. Rao, P. Rohatgi, D. Saha Filename : draft-irtf-smug-sec-mcast-arch-00.txt Pages : 18 Date : 25-Feb-99 This document proposes an architecture for secure IP multicast. It identifies the basic components and their functionalities, and specifies how these components interact with each other and with the surrounding systems. The main design principles followed in developing this architecture are simplicity, flexibility, ease of incorporation within existing systems. In particular, the design attempts to mimic the IPSec architecture, and to re-use existing IPSec mechanisms wherever possible. The proposed architecture is able to accommodate many of the existing proposals for multicast key management. In this draft, we concentrate on the architectural building blocks required to enable a group member (either a receiver or a sender of data) to use secure IP multicast. Design of the group controller(s) is left to future documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-smug-sec-mcast-arch-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-irtf-smug-sec-mcast-arch-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-irtf-smug-sec-mcast-arch-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: <19990302145105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-irtf-smug-sec-mcast-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-irtf-smug-sec-mcast-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990302145105.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@portal.ex.tis.com Wed Mar 3 16:31: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 QAA16981; Wed, 3 Mar 1999 16:31:49 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA24784 for ipsec-outgoing; Wed, 3 Mar 1999 17:02:05 -0500 (EST) Message-Id: <199903032212.RAA21101@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com@tis.com;;;;;;;; From: Internet-Drafts@ietf.org cc: smug@external.cisco.com, ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-irtf-smug-gsadef-00.txt (re-send) Date: Wed, 03 Mar 1999 17:12:57 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Group Security Association (GSA) Definition for IP Multicast Author(s) : I. Monga, T. Hardjono Filename : draft-irtf-smug-gsadef-00.txt Pages : 7 Date : 02-Mar-99 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-smug-gsadef-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-irtf-smug-gsadef-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-irtf-smug-gsadef-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: <19990302145536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-irtf-smug-gsadef-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-irtf-smug-gsadef-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990302145536.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@portal.ex.tis.com Wed Mar 3 22:49: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 WAA29500; Wed, 3 Mar 1999 22:49:16 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA25691 for ipsec-outgoing; Wed, 3 Mar 1999 23:21:08 -0500 (EST) Message-Id: <199903032212.RAA21083@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com@tis.com;;;;;;;; From: Internet-Drafts@ietf.org cc: smug@external.cisco.com, ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-irtf-smug-sec-mcast-arch-00.txt (re-send) Date: Wed, 03 Mar 1999 17:12:24 -0500 X-Rcpt-To: aalok@bisquare.com X-UIDL: 553122c00d25e64221e7477a4be84ae4 Status: U Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Architecture for Secure Internet Multicast Author(s) : R. Canetti, P. Cheng, D. Pendarakis, J. Rao, P. Rohatgi, D. Saha Filename : draft-irtf-smug-sec-mcast-arch-00.txt Pages : 18 Date : 25-Feb-99 This document proposes an architecture for secure IP multicast. It identifies the basic components and their functionalities, and specifies how these components interact with each other and with the surrounding systems. The main design principles followed in developing this architecture are simplicity, flexibility, ease of incorporation within existing systems. In particular, the design attempts to mimic the IPSec architecture, and to re-use existing IPSec mechanisms wherever possible. The proposed architecture is able to accommodate many of the existing proposals for multicast key management. In this draft, we concentrate on the architectural building blocks required to enable a group member (either a receiver or a sender of data) to use secure IP multicast. Design of the group controller(s) is left to future documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-smug-sec-mcast-arch-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-irtf-smug-sec-mcast-arch-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-irtf-smug-sec-mcast-arch-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: <19990302145105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-irtf-smug-sec-mcast-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-irtf-smug-sec-mcast-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990302145105.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@portal.ex.tis.com Wed Mar 3 22:49: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 WAA29706; Wed, 3 Mar 1999 22:49:50 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA25690 for ipsec-outgoing; Wed, 3 Mar 1999 23:21:06 -0500 (EST) Message-Id: <199903032212.RAA21101@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;@tis.com@tis.com;;;;;;;; From: Internet-Drafts@ietf.org cc: smug@external.cisco.com, ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-irtf-smug-gsadef-00.txt (re-send) Date: Wed, 03 Mar 1999 17:12:57 -0500 X-Rcpt-To: aalok@bisquare.com X-UIDL: b4c3a1f3568654cb8209a69e1266391d Status: U Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Group Security Association (GSA) Definition for IP Multicast Author(s) : I. Monga, T. Hardjono Filename : draft-irtf-smug-gsadef-00.txt Pages : 7 Date : 02-Mar-99 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-smug-gsadef-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-irtf-smug-gsadef-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-irtf-smug-gsadef-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: <19990302145536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-irtf-smug-gsadef-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-irtf-smug-gsadef-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990302145536.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@portal.ex.tis.com Wed Mar 3 22:54: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 WAA29850; Wed, 3 Mar 1999 22:54:24 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA25668 for ipsec-outgoing; Wed, 3 Mar 1999 23:15:06 -0500 (EST) Date: Wed, 3 Mar 1999 20:33:41 -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: "'Mobile IP'" , "'IPsec'" , "'IPng List'" In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8100AF81E28@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > My first email on this subject suggested that a correspondent node should > perform outbound IPsec processing twice: first looking up a security policy > using the home address as the destination address selector and applying the > resulting security associations, and then doing another security policy > database lookup using the care-of address as the destination address > selector and applying the additional security associations. Let me try to add some more complexity to the brew: When two mobile nodes communicate there are actually 4 IP addresses in use since each of them have a care-of-address and a home address. Does that mean you need to do 4 SPD lookups for the 4 combinations of source and destination? Source home address -> Destination home address Source home address -> Destination COA Source COA -> Destination home address Source COA -> Destination COA What about the case when the correspondent doesn't have a binding cache entries - perhaps due to transient behavior (the first few packets) or perhaps due to the mobile wanting location privacy. Does the policy have to be coordinated between the correspondent host and the home agent that will tunnel the packet in those cases? What about when the CH and the HA are part of different admin domains? Erik From owner-ipsec@portal.ex.tis.com Thu Mar 4 14:39: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 OAA18723; Thu, 4 Mar 1999 14:38:59 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA00518 for ipsec-outgoing; Thu, 4 Mar 1999 14:13:12 -0500 (EST) Message-ID: <36DEC64F.80FFA65F@RedCreek.com> Date: Thu, 04 Mar 1999 09:43:43 -0800 From: Ricky Charlet X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com, baiju.v.patel@intel.com CC: rcharlet@redcreek.com Subject: RE: draft-ietf-ipsec-dhcp-01.txt Content-Type: multipart/mixed; boundary="------------4ABB5BC1E13C34EA260065F2" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. --------------4ABB5BC1E13C34EA260065F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Howdy () In the "Dynamic configuration of IPSEC VPN host using DHCP" draft, it is suggested in section 2.3.1 that a roaming client with a some Internet address who is attempting to acquire a 'virtual ip address' for intranet use should send a DHCP DISCOVER message to the cooperate Security Gateway and that in this message a 'unique indentifier' should be included. The section suggests that the unique identifier might be the: IPSEC identity of the client (as specified in the IPSEC architecture document, and in DOI), or any other information that is unique to the client. The draft says that the gateway does not interpret this field, but allows the bootp relay agent (running on the gateway) to interpret this field for the purpose of identifying which SA to forward this request through. My question is, how is the Security Gateway to authenticate the request then? I understand that the very next section of the draft (2.3.2) discusses the establishment of a DHCP SA between the cooperate Security Gateway and the roaming user's host. This imposes the requirement that the roaming users host knows a secret key. But if this is the only authentication available then it is classic 'weak authentication'. Could we work in the ability to step up to a two factor authentication method? --------------4ABB5BC1E13C34EA260065F2 Content-Type: text/plain; charset=us-ascii; name="draft-ietf-ipsec-dhcp-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-ipsec-dhcp-01.txt" IPSEC Working Group Baiju V. Patel, INTERNET-DRAFT Intel Corporation draft-ietf-ipsec-dhcp-01.txt December 29, 1998 Dynamic configuration of IPSEC VPN host using DHCP Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. A revision of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. This document will expire February 1998. Distribution of this draft is unlimited. 1. Introduction IPSEC [2] is a protocol suite defined by IETF working group on IP security to secure communication at the network layer between communicating peers. Among many applications enabled by IPSEC, an interesting and useful application is connect a remote host (e.g., roaming user) to the intranet through SNG (or secure network gateway) using IPSEC tunnels. A remote host on the public internet would connect to a secure network gateway and then establish an IPSEC tunnel between itself and SNG. All the traffic between the remote host and the intranet will be carried over the IPSEC tunnel via SNG as shown in the figure. Patel 1 draft-ietf-ipsec-dhcp-01.txt 12/29/98 --------------- |----------| |---------| |----------| | Remote Host |----|Internet |----|SNG |---| Intranet | --------------- |----------| |---------- |----------| | |<--IPSEC Tunnel ----> | |-------------| | DHCP Server | |-------------| A typical configuration of the remote host in this application would use two addresses: 1) an interface to connect to the Internet (internet interface), and 2) a virtual interface to connect to the intranet (intranet interface). The IP address of the Internet and intranet interfaces are used in the outer and inner headers of the IPSEC respectively. The mechanisms for automatic configuration of the remote host's address for the Internet interface are well defined; i.e., PPP IP control protocol (IPCP) and DHCP. The mechanisms for auto-configuration of the intranet are standardized. The two obvious choices for auto-configuration of the intranet interface are: 1) use DHCP [3], 2) define a DOI to be used with ISAKMP/Oakley to implement functionality similar to PPP IP Control protocol[4]. In this draft, we propose to standardize on the use of DHCP protocol as a mechanisms for configuration of the intranet interface of a IPSEC tunnel for the following reasons. 1) PPP IP Control protocol is fairly limiting because it primarily focuses on assigning IP address and does not provide all the necessary configuration parameters. 2) Defining a new DOI for this purpose unnecessarily makes ISAKMP/Oakley protocols and negotiations complex. 3) DHCP based mechanisms are already in place and well understood. 4) DHCP protocol provides most of the necessary configuration parameters and allows vendor extensions when necessary. This draft outlines the details of how DHCP protocol can be used to auto-configure the intranet interface of an IPSEC tunnel. The details of DHCP protocol are provided in . The details of IPSEC protocol are provided in and the references included in those documents. 2. Outline of the protocol 2.1. Notations The key words, MUST, SHOULD, MAY etc. are defined in [1]. The IPSEC related concepts and notations are defined in [2] and DHCP related notations are defined in [3]. 2.2. The protocol overview The protocol described here assumes that the remote host already has internet connectivity and the internet interface is appropriately Patel 2 draft-ietf-ipsec-dhcp-01.txt 12/29/98 configured using PPP or DHCP protocols, or using out of band mechanisms (i.e., static configuration). The remote host also has the knowledge of the SNG. The protocol for auto-configuration of the intranet interface of IPSEC tunnel mode consists of three steps: 1) The remote host establishes a DHCP SA. The DHCP SA is an IPSEC tunnel mode SA established to protect initial DHCP traffic between the Secure Network Gateway (SNG) and the remote host. 2) Execute DHCP protocol between the remote hosts intranet interface and the SNG. This traffic is protected using the DHCP SA established in step 1. Therefore, all the DHCP packets between the SNG and the remote host are tunneled using DHCP SA established in step 1. At the end of the DHCP protocol, the remote host is configured with address obtained by it and other relevant parameters (e.g., DNS server name). The DHCP SA SHOULD be deleted at this point since future DHCP messages will be carried over VPN tunnel. 3) Establish a VPN SA between the remote host and the SNG. The VPN SA is a tunnel mode SA. Note that this is a quick mode exchange. At the end of step 3, the remote host is ready to communicate with the intranet using IPSEC tunnel. All the IP traffic (including future DHCP messages) between the remote host, and the intranet are now tunneled over VPN SA. In many cases, DHCP SA and VPN SA may be the same. 2.3. Detailed operation Once the Internet interface of the remote host is already configured, and the connectivity exists between the internet interface of the remote host and the SNG, exchanges of the following messages complete the configuration of the intranet interface and the IPSEC tunnel. The security parameters used for different SA's is based on the security requirements between the remote host and the SNG and therefore, is not subject of this document. The mechanisms described here work best when VPN is implemented using virtual interface (called intranet interface in this document). Thus, the objective is to get intranet interface configured using DHCP protocol. The exchanges are: 1) The intranet interface generates DHCP DISCOVER message and sends it to the intranet interface. The chaddr field of the DHCP message should include a unique identifier to that gateway. Therefore, it can be IPSEC identity of the client (as specified in the IPSEC architecture document, and in DOI), or any other information that is unique to the client. Note that this field not interpreted by the gateway or DHCP server, but is used by the gateway (bootp relay agent) to forward DHCP reply to the Patel 3 draft-ietf-ipsec-dhcp-01.txt 12/29/98 appropriate tunnel. The client must use the same chaddr field in all subsequent messages of the same DHCP exchange. 2) Since there is traffic on the intranet interface, and intranet interface is not configured yet, an IPSEC tunnel over the Internet interface needs to be established (DHCP SA) for the intranet interface. Remark: the DHCP SA may be established before of after receiving DHCP DISCOVER message from the intranet interface. - Establish a Phase 1 ISAKMP/Oakley SA between the Internet interface and the SNG. - Establish DHCP SA using phase 2 (quick mode) of ISAKMP/Oakley. The key lifetime for the DHCP SA SHOULD be in order of minutes since it is only used at the beginning of DHCP protocol. All the future DHCP communication, including DHCP INFORM, DHCP RENEW and DHCP Terminate use VPN SA. The IDUi payload for the quick mode SHOULD use address 0.0.0.0. - Setup the routing tables such that all the traffic from intranet interface is forwarded over the IPSEC tunnel based on DHCP SA. At this point, a filtering table may also be established to drop all non-DHCP traffic. Similarly, all the packets received over the Internet interface based on IPSEC tunnel using DHCP SA are to be forwarded to the intranet interface. 3) The DHCP DISCOVER message is tunneled to SNG using DHCP SA. The SNG must store the chaddr field of the DHCP DISCOVER message and the information (possibly interface) over which the DHCP DISCOVER message was received in a table. 4) The SNG sends back DHCP RESPONSE message over IPSEC tunnel based on DHCP SA. - If the SNG itself is a DHCP server, it can generate the DHCP response message. - If the SNG is not the DHCP server, it MUST relay the DHCP DISCOVER message to a DHCP server and forward the response. The SNG MUST forward the replay back to the DHCP/VPN client over the tunnel associated with the DHCP DISCOVER message. 5) The Internet Interface forwards the DHCP response message to the intranet interface after IPSEC processing. 6) The Intranet Interface sends out DHCP REQUEST message. 7) The DHCP REQUEST message is tunneled to the wall by the Internet Interface using DHCP SA. 8) The SNG tunnels DHCP ACK message to the Internet Interface of the remote host. 9) The Internet interface of the remote host forwards DHCP ACK message to the intranet Interface. At this point, the intranet interface has all the parameters supplied by the DHCP protocol to complete its configuration. The internet interface can establishes a IPSEC tunnel mode SA for VPN (VPN SA) with the SNG. Note that IDui of the quick mode message should be the virtual address of the intranet interface (as obtained earlier using DHCP). DHCP SA SHOULD now be deleted, and associated routing information must be discarded. All the future IP traffic, including DHCP TERMINATE, RENEW, and INFORM messages MAY use VPN traffic for communication to the intranet and the SNG. Patel 4 draft-ietf-ipsec-dhcp-01.txt 12/29/98 2.4. DHCP Considerations Since the SNG needs to keep track of interfaces over with the DHCP protocol messages are to be communicated. The DHCP client MUST supply client identifier option with its DNS name or the IP address of its Internet Interface concatenated with the interface name. The interface name is an ASCII null terminated string. 3. Security Considerations This protocol is secured using IPSEC. 4. References [1]. Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [2]. S. Kent and R. Atkinson, Security architecture for Internet Protocol, RFC 2401 [3]. R. Droms, "Dynamic Host Configuration Protocol", RFC 2131. [4]. G. McGregor, The PPP Internet Protocol Control Protocol (IPCP), RFC 1172. 5. Acknowledgments This draft has been enriched by comments from John Richardson and Prakash Iyer of Intel, Gurdeep Pall and Peter Ford of Microsoft, and Scott Kelley of Red Creek Communications. 6. Author's Addresses Baiju V. Patel Intel Corp, JF3-206 2511 NE 25th Ave Hillsboro, OR 97124 Phone: 503 264 2422 Email: baiju.v.patel@intel.com Patel 5 --------------4ABB5BC1E13C34EA260065F2-- From owner-ipsec@portal.ex.tis.com Thu Mar 4 16:43: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 QAA19987; Thu, 4 Mar 1999 16:43:45 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA01866 for ipsec-outgoing; Thu, 4 Mar 1999 16:56:16 -0500 (EST) Message-Id: <199903042209.RAA12407@clipper.hq.tis.com> Date: Thu, 4 Mar 1999 17:11:55 -0500 (EST) From: John Kelley Reply-To: John Kelley Subject: PLEASE READ: Address of list changing! To: ipsec@tis.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WIHME1vuAxYJJV/LVQqI6A== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk PLEASE NOTE! As of March 12 this mailing list will be hosted at lists.tislabs.com. Postings will begin to be sent with this new address as its sender on this date. As of March 26 mail sent to tis.com or ex.tis.com will no longer be received by the server. Please adjust your address books and filters appropriately. You may immediately start using the @lists.tislabs.com address to subscribe, unsubscribe and post. We are sorry for any inconvenience this may cause. The change is required due to changes in our company's mail and DNS infrastructure. -John Kelley -- John C. Kelley Computer Scientist TISLabs at Network Associates, Inc. Glenwood, MD From owner-ipsec@portal.ex.tis.com Thu Mar 4 18:19: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 SAA20787; Thu, 4 Mar 1999 18:19:29 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id SAA02321 for ipsec-outgoing; Thu, 4 Mar 1999 18:41:14 -0500 (EST) Message-ID: <36DF1FC9.216B1EF4@host186.redcreek.com> Date: Thu, 04 Mar 1999 16:05:29 -0800 From: Ricky Charlet Organization: RedCreek Communicaitons Inc. X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tis.com Subject: where is the ikecfg draft? Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Howdy ()
    While reading the "Extended Authentication within ISAKMP/Oakley" draft (draft-ietf-ipsec-isakmp-xauth-03.txt) I find the first sentence in section 3 saying that the protocols use here are based on the [IKECFG] draft "The ISAKMP configuration Method".
    Problem is that I can't find the IKECFG draft in the draft mirrors or mailing list archives. And the XAUTH draft does not stand on its own too well in terms of describing packets or protocols. Where is a copy of the IKECFG draft? (and what are the reasons it faded from memory??) 
-- 
####################################
#  Ricky Charlet
#       (510) 795-6903
#       rcharlet@redcreek.com
####################################
  From owner-ipsec@portal.ex.tis.com Thu Mar 4 19:36: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 TAA23453; Thu, 4 Mar 1999 19:36:54 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA02645 for ipsec-outgoing; Thu, 4 Mar 1999 20:20:13 -0500 (EST) Message-Id: <199903050141.UAA20971@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-policy-framework-00.txt Date: Thu, 04 Mar 1999 20:41:46 -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 : Policy Framework for IP Security Author(s) : P. Srisuresh, L. Sanchez Filename : draft-ietf-ipsec-policy-framework-00.txt Pages : 10 Date : 03-Mar-99 As policy based networking has become a common place across the Internet with the advent of IPsec, firewalls and other initiatives, it is important for peering end nodes to understand where and why packets enroute are black-holed. End-to-end networking mandates that end nodes be cognizant of the impact policies along various points on the network will have on their packets. The objective of this document is to lay out a framework of policy requirements for end nodes. While the framework is focussed on IPSec based policies, it may be applicable across a wider policy base. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-policy-framework-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-policy-framework-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-policy-framework-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: <19990303133010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-policy-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-policy-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990303133010.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@portal.ex.tis.com Thu Mar 4 19:36: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 TAA23464; Thu, 4 Mar 1999 19:36:56 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA02657 for ipsec-outgoing; Thu, 4 Mar 1999 20:21:14 -0500 (EST) Message-ID: <36DF36D8.A093232C@redcreek.com> Date: Thu, 04 Mar 1999 17:43:52 -0800 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: ipsec@tis.com Subject: Re: where is the ikecfg draft? References: <36DF1FC9.216B1EF4@host186.redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk The ikecfg draft is at http://www.ietf.org/ids.by.wg/ipsec.html From owner-ipsec@portal.ex.tis.com Thu Mar 4 20:32: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 UAA26909; Thu, 4 Mar 1999 20:32:25 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA02832 for ipsec-outgoing; Thu, 4 Mar 1999 21:04:14 -0500 (EST) Message-ID: <36DF3C45.EC3ABB87@ire-ma.com> Date: Thu, 04 Mar 1999 21:07:01 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: "Scott G. Kelly" CC: ipsec@tis.com Subject: Re: where is the ikecfg draft? References: <36DF1FC9.216B1EF4@host186.redcreek.com> <36DF36D8.A093232C@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Didn't it expire last November? :) Scott G. Kelly wrote: > The ikecfg draft is at > > http://www.ietf.org/ids.by.wg/ipsec.html From owner-ipsec@portal.ex.tis.com Thu Mar 4 22:35: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 WAA28948; Thu, 4 Mar 1999 22:35:10 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id XAA03143 for ipsec-outgoing; Thu, 4 Mar 1999 23:14:13 -0500 (EST) Message-Id: <4.2.0.25.19990304203322.02057660@mail.imc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.25 (Beta) Date: Thu, 04 Mar 1999 20:34:26 -0800 To: Ricky Charlet , ipsec@tis.com From: Paul Hoffman Subject: Re: where is the ikecfg draft? In-Reply-To: <36DF1FC9.216B1EF4@host186.redcreek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@ex.tis.com Precedence: bulk At 04:05 PM 3/4/99 -0800, Ricky Charlet wrote: > Problem is that I can't find the IKECFG draft in the draft mirrors or > mailing list archives. And the XAUTH draft does not stand on its own too > well in terms of describing packets or protocols. Where is a copy of the > IKECFG draft? (and what are the reasons it faded from memory??) A copy can be found at . VPNC keeps the latest copy of all IPsec drafts and RFCs on it's site; see for more details. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@portal.ex.tis.com Fri Mar 5 20:05: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 UAA18695; Fri, 5 Mar 1999 20:05:50 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA08083 for ipsec-outgoing; Fri, 5 Mar 1999 20:42:21 -0500 (EST) Message-ID: From: Ricky Charlet To: "'partha@watson.ibm.com'" , "'radams@cisco.com'" , "'rpereira@timestep.com'" , "'wdison@microsoft.com'" , "'raju@watson.ibm.com'" , "'ipsec@lists.tislabs.com'" , "'ipsec@tis.com'" Subject: vpn-policy-schema questions Date: Fri, 5 Mar 1999 18:04:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE6775.9F80E814" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE6775.9F80E814 Content-Type: text/plain; charset="iso-8859-1" Howdy () I have a few questions about the Draft "An LDAP Schema for Configuration and Administration of IPSec based Virtual Private Networks (VPNs)" draft-ipsec-vpn-policy-schema-oo.txt Even if you have only a subset of answers, I'd be interested. 1. Has anyone built a MIB translation of LDAP formatted draft-ietf-ipsec-vpn-policy-schema-00.txt? 2. The IPSecProposal object includes one AHTransformRef, one ESPTransformRef, and one IPCOMPTransformRef. Is the intention here to limit SA bundles to the possible combination of one each from the above three possibilities? 3. Could there be a way for the PolicyAction object to be able to reference vendor specific actions not defined in this draft? What would be the minimum requisites. 4. In the IPSecSecurityAction, aren't the *proxied* objects redundant with the IPPolicyCondition which brought this action into play? 5. What do you think of changing the *autoStartFlag objects to *autoStartCondition objects which would have references like: always never duringTimeRange X..Y if interface X is down if interface X is heavily loaded 6. Inside of one IPSecProposal are we limited to one DH group for all transforms (ESP, AH)? 7. What are the reasons for making ISAKMPAction a PolicyAction? Arn't the 'PolicyCondition's for selection ISAKMPAction trivial and possibly even unalterable by local policy ? I see that ISAKMPAction is reference from IPSecSecurityAction, this seems appropriate and sufficient to me. 8. Does anyone have some opinions about how external authentication/authorization engines might be married into this draft? 9. Suppose two packets pass through a security gateway, receiving IPSec treatment. On the first packet, how does this schema allow multiple ISAKMP and IPSec proposals to be offered in the two negotiation phases? On the second packet, how does this schema identify those particular proposals (ISAKMP and IPSec, one each) that won the negotiation when the first packet passed? ################################### # Ricky Charlet # rcharlet@RedCreek.com # (510) 795-6903 ################################### end Howdy; ------_=_NextPart_000_01BE6775.9F80E814 Content-Type: application/octet-stream; name="Ricky Charlet.vcf" Content-Disposition: attachment; filename="Ricky Charlet.vcf" BEGIN:VCARD VERSION:2.1 N:Charlet;Ricky FN:Ricky Charlet ORG:RedCreek Communications Inc.;Engineering TITLE:Engineer ADR;WORK:;2nd Floor;3900 Newpark Mall Rd.;Newark;CA;94560;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:2nd Floor=0D=0A3900 Newpark Mall Rd.=0D=0ANewark, CA 94560=0D=0AUSA EMAIL;PREF;INTERNET:rcharlet@redcreek.com REV:19981013T230517Z END:VCARD ------_=_NextPart_000_01BE6775.9F80E814-- From owner-ipsec@portal.ex.tis.com Fri Mar 5 20:06: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 UAA18724; Fri, 5 Mar 1999 20:06:00 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id UAA08075 for ipsec-outgoing; Fri, 5 Mar 1999 20:41:43 -0500 (EST) Message-ID: From: Ricky Charlet To: "'partha@watson.ibm.com'" , "'radams@cisco.com'" , "'rpereira@timestep.com'" , "'wdison@microsoft.com'" , "'raju@watson.ibm.com'" , "'ipsec@lists.tislabs.com'" , "'ipsec@tis.com'" Subject: vpn-policy-schema questions Date: Fri, 5 Mar 1999 18:04:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE6775.9F80E814" Sender: owner-ipsec@ex.tis.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE6775.9F80E814 Content-Type: text/plain; charset="iso-8859-1" Howdy () I have a few questions about the Draft "An LDAP Schema for Configuration and Administration of IPSec based Virtual Private Networks (VPNs)" draft-ipsec-vpn-policy-schema-oo.txt Even if you have only a subset of answers, I'd be interested. 1. Has anyone built a MIB translation of LDAP formatted draft-ietf-ipsec-vpn-policy-schema-00.txt? 2. The IPSecProposal object includes one AHTransformRef, one ESPTransformRef, and one IPCOMPTransformRef. Is the intention here to limit SA bundles to the possible combination of one each from the above three possibilities? 3. Could there be a way for the PolicyAction object to be able to reference vendor specific actions not defined in this draft? What would be the minimum requisites. 4. In the IPSecSecurityAction, aren't the *proxied* objects redundant with the IPPolicyCondition which brought this action into play? 5. What do you think of changing the *autoStartFlag objects to *autoStartCondition objects which would have references like: always never duringTimeRange X..Y if interface X is down if interface X is heavily loaded 6. Inside of one IPSecProposal are we limited to one DH group for all transforms (ESP, AH)? 7. What are the reasons for making ISAKMPAction a PolicyAction? Arn't the 'PolicyCondition's for selection ISAKMPAction trivial and possibly even unalterable by local policy ? I see that ISAKMPAction is reference from IPSecSecurityAction, this seems appropriate and sufficient to me. 8. Does anyone have some opinions about how external authentication/authorization engines might be married into this draft? 9. Suppose two packets pass through a security gateway, receiving IPSec treatment. On the first packet, how does this schema allow multiple ISAKMP and IPSec proposals to be offered in the two negotiation phases? On the second packet, how does this schema identify those particular proposals (ISAKMP and IPSec, one each) that won the negotiation when the first packet passed? ################################### # Ricky Charlet # rcharlet@RedCreek.com # (510) 795-6903 ################################### end Howdy; ------_=_NextPart_000_01BE6775.9F80E814 Content-Type: application/octet-stream; name="Ricky Charlet.vcf" Content-Disposition: attachment; filename="Ricky Charlet.vcf" BEGIN:VCARD VERSION:2.1 N:Charlet;Ricky FN:Ricky Charlet ORG:RedCreek Communications Inc.;Engineering TITLE:Engineer ADR;WORK:;2nd Floor;3900 Newpark Mall Rd.;Newark;CA;94560;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:2nd Floor=0D=0A3900 Newpark Mall Rd.=0D=0ANewark, CA 94560=0D=0AUSA EMAIL;PREF;INTERNET:rcharlet@redcreek.com REV:19981013T230517Z END:VCARD ------_=_NextPart_000_01BE6775.9F80E814-- From owner-ipsec@portal.ex.tis.com Sat Mar 6 02:37: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 CAA06524; Sat, 6 Mar 1999 02:37:14 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id DAA08602 for ipsec-outgoing; Sat, 6 Mar 1999 03:17:23 -0500 (EST) Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81EA5@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" Cc: "'Mobile IP'" , "'IPsec'" , "'IPng List'" Subject: RE: (mobile-ip) RE: (IPng 7211) RE: Last Call: Mobility Support i n IPv6 to Propos ed Standard Date: Sat, 6 Mar 1999 00:38:51 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipsec@ex.tis.com Precedence: bulk Erik asked about more cases where mobility and IPsec interact: > What about the case when the correspondent doesn't have a > binding cache > entries - perhaps due to transient behavior (the first few packets) or > perhaps due to the mobile wanting location privacy. > Does the policy have to be coordinated between the correspondent host > and the home agent that will tunnel the packet in those cases? > What about when the CH and the HA are part of different admin domains? If the correspondent node doesn't have a binding cache entry for the mobile - ie it doesn't know the mobile is mobile - I think the correspondent when sending just needs to do IPsec processing as usual with the mobile's home address as the destination address selector. No policy coordination between the correspondent and the home agent is required. This assumes that there is no security gateway between the mobile and its home agent, so that when the home agent intercepts the packet destined for the mobile, the only security associations remaining in the packet are those directly with the mobile's home address. For example, suppose the correspondent has a transport-mode AH association with the mobile's home address. The correspondent sends packets like IPv6 hdr - src CN, dst HA AH hdr - transport-mode SA CN -> HA Transport hdr The home agent intercepts these and sends them to the care-of address. Suppose the care-of address is behind a security gateway. The home agent sets up a tunnel-mode ESP assocation with the security gateway and sends packets like IPv6 hdr - src Agent, dst SG ESP hdr - tunnel-mode SA Agent -> SG IPv6 hdr - src Agent, dst CA IPv6 hdr - src CN, dst HA AH hdr - transport-mode SA CN -> HA Transport hdr In this situation the mobile will do a first inbound SPD check when it hits the 3rd IPv6 header. The first policy check will use as selectors source Agent and destination CA. (It will verify that no association exists between the Agent and the care-of address.) It will do a second inbound SPD check when it hits the transport header. The second policy check will use as selectors source CN and destination HA. (It will verify the transport-mode AH association between the correspondent and the home address.) > When two mobile nodes communicate there are actually 4 IP addresses > in use since each of them have a care-of-address and a home address. > Does that mean you need to do 4 SPD lookups for the 4 combinations of > source and destination? > Source home address -> Destination home address > Source home address -> Destination COA > Source COA -> Destination home address > Source COA -> Destination COA > I think when two mobile nodes are communicating, you still only want two SPD lookups. The two SPD lookups are first using the two home addresses as destination and source selectors, and then second using the two care-of addresses as destination and source selectors. The results of the two lookups are spliced together. Associations directly with the destination home address (might be transport-mode or tunnel-mode) are taken from the first lookup, and associations with intermediate security gateways (always tunnel-mode) are taken from the second lookup. Then the headers from the security associations are combined with a routing header and destination options header as follows: IPv6 hdr - src care-of address, dst care-of address Routing hdr - segs left = 1, dst home address Destination options hdr - Home Address option, src home address Transport hdr Looking at what I just wrote, I'm unclear on two things: 1. The desired placement of the Home Address option. Should it be immediately before the transport header, or immediately after the Routing header? (The draft tries to specify this in section 10.1, but I'm not sure which alternative it means or which is correct.) 2. The processing of this packet when it gets to the destination mobile node. Does the routing header processing require inbound and outbound security policy checks before it is looped-back internally? This is the consensus that we already reached for generic routing header processing - it's like forwarding. But in this case the new destination address is reached via loopback, not forwarding outside the node. Rich From owner-ipsec@portal.ex.tis.com Mon Mar 8 02:57: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 CAA03900; Mon, 8 Mar 1999 02:57:33 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id CAA13109 for ipsec-outgoing; Mon, 8 Mar 1999 02:28:14 -0500 (EST) Message-Id: <199903080542.AAA01853@pzero.sandelman.ottawa.on.ca> To: "heilmann" cc: ipsec@tis.com Subject: Re: UDP / Identifying ISAKMP message In-reply-to: Your message of "Mon, 01 Mar 1999 14:45:50 GMT." <19990301134546.AAA28967@iabgmh.iabg.de@cc31nb05> Date: Mon, 08 Mar 1999 00:42:06 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "heilmann" == heilmann writes: heilmann> two general questions concerning IPSec and ISAKMP: heilmann> 1.) How can the IP layer be determine if a certain IPv6 heilmann> PDU is (part of) an ISAKMP message? protocol == UDP, port == 500. heilmann> 2.) Are there any special reasons, why ISAKMP hasn't heilmann> simply been assigned a "Next Header" number for IPv6 - heilmann> so that it could run directly over IP itself? It was designed specifically to allow that kind of thing. I don't think it has been assigned yet. Hilary had some reasons for UDP vs IP protocols. ] Have encryption. Am travelling... looks like Pensylvania. |1 Fish/2 Fish[ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNuNjLB4XQavxnHg9AQEjpQH/QgpGx4i/qw4z3m3hag6GUBScu4Li7Mfs 5/BUtNaRawSAhLns7G8P13I7Jjd8r+4nLZamx8bGTtNomibwBVZUjw== =NnRY -----END PGP SIGNATURE----- From owner-ipsec@portal.ex.tis.com Mon Mar 8 10:55: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 KAA11685; Mon, 8 Mar 1999 10:55:31 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA14953 for ipsec-outgoing; Mon, 8 Mar 1999 11:09:12 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF8AB021@exchange> From: Roy Pereira To: Bronislav Kavsan , "Scott G. Kelly" Cc: ipsec@tis.com Subject: RE: where is the ikecfg draft? Date: Mon, 8 Mar 1999 11:32:12 -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 I will resubmit a new version of it after the IPSec Remote Access BOF next week. > -----Original Message----- > From: Bronislav Kavsan [mailto:bkavsan@ire-ma.com] > Sent: Thursday, March 04, 1999 9:07 PM > To: Scott G. Kelly > Cc: ipsec@tis.com > Subject: Re: where is the ikecfg draft? > > > Didn't it expire last November? :) > > Scott G. Kelly wrote: > > > The ikecfg draft is at > > > > http://www.ietf.org/ids.by.wg/ipsec.html > > > > From owner-ipsec@portal.ex.tis.com Mon Mar 8 11:09: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 LAA11811; Mon, 8 Mar 1999 11:09:07 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA14739 for ipsec-outgoing; Mon, 8 Mar 1999 10:21:37 -0500 (EST) Date: Mon, 8 Mar 1999 10:43:49 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: UDP / Identifying ISAKMP message In-Reply-To: <199903080542.AAA01853@pzero.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Mon, 8 Mar 1999, Michael Richardson wrote: > heilmann> 2.) Are there any special reasons, why ISAKMP hasn't > heilmann> simply been assigned a "Next Header" number for IPv6 - > heilmann> so that it could run directly over IP itself? > > It was designed specifically to allow that kind of thing... Indeed, RFC 2408 specifically mentions the possibility of using it over bare IP. > Hilary had some reasons for UDP vs IP protocols. The usual reason for wanting to use UDP is that it provides port numbers, which permits doing things like running experimental daemons on the same machine as production ones. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@portal.ex.tis.com Mon Mar 8 11:21: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 LAA11902; Mon, 8 Mar 1999 11:21:26 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA14609 for ipsec-outgoing; Mon, 8 Mar 1999 10:12:15 -0500 (EST) Message-Id: <199903081510.KAA27206@clipper.hq.tis.com> Date: Mon, 8 Mar 1999 10:12:39 -0500 (EST) From: John Kelley Reply-To: John Kelley Subject: Addendum: Address of list changing To: ipsec@tis.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tG6GcJl1SgAKTzqtOTc/vg== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Sender: owner-ipsec@ex.tis.com Precedence: bulk Further information related to the domain name change coming soon to a list near you: -All subscriber lists will be maintained as-is when the list address changes. (Technically, the server and lists etc., are not physically moving to a different system. The domain name configuration of the current server will be changed. So, literally nothing but the domain name and email addresses will change.) -The list archives will still be available via anonymous ftp. This server will change to ftp.tislabs.com. Ftp.tis.com will work for a time after the change, but it is advisable to start using ftp.tislabs.com asap. Sorry for not including this in my earlier post. -John -- John C. Kelley Computer Scientist TISLabs at Network Associates, Inc. Glenwood, MD From owner-ipsec@portal.ex.tis.com Mon Mar 8 11:23: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 LAA11919; Mon, 8 Mar 1999 11:23:12 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA15081 for ipsec-outgoing; Mon, 8 Mar 1999 11:25:15 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF8AB03F@exchange> From: Roy Pereira To: "IPSEC Mailing List (E-mail)" Subject: IPSec Remote Access BOF Date: Mon, 8 Mar 1999 11:47:28 -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 I'd like to invite anyone interested to present at the IPSec Remote Access BOF coming up on March 15 at IETF. Please send me your presentation proposals by no later than this Thursday. IP Security Remote Access BOF (ipsra) Monday, March 15 at 0930-1130 ============================= The rapid growth of remote access and the subsequent transition from older direct-dial methods to Internet-based remote access is making an impact secure communications. IP Security (IPSec), as it is today defined, is missing key functionality needed to effectively support Internet-based remote access as well as being difficult to deploy to remote users. IPSec is quite functional and provides for a very robust base of security specifications, thus any new functionality would have to be added to the existing specifications as add-ons and not disrupt existing implementations. To address these problems the IPSRA Working Group will: 1) specify an extensible mechanism for bootstrapping remote IPSec users 2) specify an extensible mechanism to extend IPSec to support legacy user authentication methods such as RADIUS The proposed work item for this group would yield standards that are compatible with the existing IPSec architecture [RFC 2401] and IKE, complementing the standards work achieved by the IPSec Working Group. This work will be derived from, but not limited to, all or some of the following documents: draft-ietf-ipsec-iskamp-xauth draft-ietf-ipsec-isakmp-mode-cfg draft-ietf-ipsec-isakmp-hybrid-auth draft-ietf-ipsec-dhcp AGENDA: - Agenda bashing - Series of presentations of related work - Open discussion and consensus gathering: do we need to form a WG to do the proposed work? - Collect feedback and modify charter - adjourn From owner-ipsec@portal.ex.tis.com Mon Mar 8 13:31: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 NAA13104; Mon, 8 Mar 1999 13:31:12 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA15890 for ipsec-outgoing; Mon, 8 Mar 1999 13:39:15 -0500 (EST) Message-Id: <4.1.19990308103709.0092e7a0@idi-fk-gw.abhiweb.com> X-Sender: rodney@idi-fk-gw.abhiweb.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 08 Mar 1999 10:38:05 -0800 To: Henry Spencer , IP Security List From: Rodney Thayer Subject: Re: UDP / Identifying ISAKMP message In-Reply-To: References: <199903080542.AAA01853@pzero.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk in a classic operating system environment it's good for it to be based on an above-IP protocol because it's often difficult to run around and hit the file system for things like cert files if you're running raw IP. At 10:43 AM 3/8/99 -0500, Henry Spencer wrote: >On Mon, 8 Mar 1999, Michael Richardson wrote: >> heilmann> 2.) Are there any special reasons, why ISAKMP hasn't >> heilmann> simply been assigned a "Next Header" number for IPv6 - >> heilmann> so that it could run directly over IP itself? >> >> It was designed specifically to allow that kind of thing... > >Indeed, RFC 2408 specifically mentions the possibility of using it over >bare IP. > >> Hilary had some reasons for UDP vs IP protocols. > >The usual reason for wanting to use UDP is that it provides port numbers, >which permits doing things like running experimental daemons on the same >machine as production ones. > > Henry Spencer > henry@spsystems.net > (henry@zoo.toronto.edu) > From owner-ipsec@portal.ex.tis.com Mon Mar 8 14:10: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 OAA13519; Mon, 8 Mar 1999 14:10:28 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id MAA15500 for ipsec-outgoing; Mon, 8 Mar 1999 12:28:16 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF8AB0C4@exchange> From: Tim Jenkins To: ipsec@tis.com Subject: MIB Issues (long) Date: Mon, 8 Mar 1999 12:50:42 -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 In attempt to move this along, I'm going to post a shell structure. It's not been filled in, since it seems like we still have to work on the overall architecture. So, I am presenting here a portion of the next proposed draft for comments. Some accompanying notes. Where possible, the MIB will use John Shriver's textual conventions draft. All addresses are duplicated, one for V4 and one for V6. The one that's not used is set to 0. This allows proper presentation of each address type, and still makes them usable as members of an index. (Thanks to John Shriver for this suggestion.) Some specific issues that need comments: 1) Is this architecture the right one? 2) Is the IPv4 /IPv6 address issue handled sufficiently? 3) Do we worry about sensitive data, i.e., do we provide separate tables for sensitive information such as identities? If so, what other information do we treat as sensitive? Once the structure is decided upon, then we can decide what goes into the individual tables. I will probably be presenting this or something modified depending on the comments I receive at the IETF meeting next week, so get those comments in today! ==> 3. IPSec MIB Objects Architecture The IPSec MIB consists of three separate MIB groups. An IPSec MIB provides monitoring for raw uni-directional security associations (SAs). An Internet Security Association and Key Management Protocol (ISAKMP) MIB provides a base for the Domain Of Interpretation (DOI)- independent portion of phase 1 SAs created using ISAKMP. Finally, an Internet Key Exchange (IKE) MIB provides the IKE DOI-specific phase 1 SAs, and also the protection suite object to link the raw IPSec SAs to the IKE SAs that created them. Note that there is no attempt at this time to define complete ISAKMP (DOI of 0) SAs. Configuration about the SAs is provided as are statistics related to the SAs themselves. Additionally, the MIBs provide a number of entity level aggregate totals for the SAs. There are also traps defined. These may be used by system administrators to help detect mis-configurations or possible attacks. 3.1 MIB Tables The MIBs use a number of tables to show IKE SAs and phase 2 SAs, in order to get the most flexibility for the different possible uses of IPSec and IKE. A general picture of the relationship of the tables is shown in Figure 1. The raw SAs provided by the IPSec MIB are standalone, and may be used by themselves. The ISAKMP MIB is also standalone. The IKE MIBs require both the IPSec tables and the ISAKMP tables. ISAKMP +--------------------------------------------+ | ISAKMP DOI-independent part of Phase 1 SAs | +--------------------------------------------+ ^ IKE | | | +----------------------------------------+ +-| IKE DOI-dependent part of Phase 1 SAs | +----------------------------------------+ ^ | +-----------------------+ +-| Protection Suites | +-----------------------+ | | | | | | \ / \ / \ / \ / \ / \ / IPSEC +--------------------+ | ESP Inbound SAs | +--------------------+ +--------------------+ | AH Inbound SAs | +--------------------+ +--------------------+ | IPCOMP Inbound SAs | +--------------------+ +--------------------+ | ESP Outbound SAs | +--------------------+ +--------------------+ | AH Outbound SAs | +--------------------+ +---------------------+ | IPCOMP Outbound SAs | +---------------------+ Figure 1 Relationship of Tables 3.2 ISAKMP Security Association Table The ISAKMP MIB consists of tables related to ISAKMP SAs. As such, one of the tables consists of information about phase 1 SAs that is independent of the DOI used. Its purpose is to provide a base for all protocols that use ISAKMP as the basis for their SA negotiation. This table includes the identifiers for phase 1 SAs, some version information, some communications information and some basic status information. Additional tables would be generated that would be specific to the ISAKMP DOI, however, as stated earlier, there is no attempt at this time to define these tables. 3.3 IKE Security Association Table IKE SAs presented in the table contain information about their services provided, lifetime, end point authentication and some aggregate performance statistics. They build on the ISAKMP DOI-independent table. 3.4 IKE Protection Suite Table IPSec protection suites are as defined by [ISAKMP]. In ISAKMP, an SA is effectively a protection suite that provides only a single security service. Since the protection suite is defined by ISAKMP, this table is part of the same MIB tree as the IKE SA table. In ISAKMP (and therefore IKE), SAs are considered a subset of protection suites, since both protection suites and SAs are negotiated within IKE using a single proposal payload during a single quick mode. [ISAKMP] also requires that attributes negotiated within a protection suite apply to all SAs. Therefore, the protection suite table provides expiration values and selectors for all SAs in a protection suite. In order to get the statistics for the SAs, however, the protection suite provides the ability to get to the individual SAs themselves. ISAKMP assumes that protection suites have only a single occurrence of any one of the three defined security services. (IP compression is considered a security service for the purposes of this MIB.) It also assumes that the order of these services within the protection suite is compression before ESP before AH (in the encrypting/hashing direction) as also stated in [ISAKMP] and [SECARCH]. However, the MIB as defined here allows up to three protocols, with no restrictions on their order or occurrence. Entries in the protection suite table are uniquely identified by the local and remote IP addresses and the security protocol and SPI (or CPI) pairs in each direction. Note that both statically keyed SAs and SAs created by a key exchange protocol may be shown in the table, even though this is an ISAKMP concept. Further, in order to link the creation of protection suite (and thereby SAs) to specific endpoints, the protection suite also contains entries for the identities of the endpoints that negotiated the SAs. 3.5 IPSec Security Association Tables Individual IPSec phase 2 SAs are separated by both direction and (security) protocol, resulting in the creation of six separate tables. Separate inbound tables are used for ESP, AH and IPCOMP. Each table shares common information, such as the selectors and expiration limits in addition to protocol and specific information. Similarly, there is a set of outbound tables for each protocol. These tables are presented in a MIB tree separate from the IKE SA table to allow the use of these tables by implementations that support static SAs, or SAs created by key exchange protocols other than IKE. 3.6 Security Association Bundles This MIB does not explicitly show SA bundles or any combination of layered SAs that do not meet the protection suite definition as defined in [ISAKMP]. However, these may be represented in these MIBs by separate protections suites or SAs with the appropriate set of selectors. 3.7 Notify Messages Notify messages sent from peer to peer are not necessarily sent as traps. However, they are collected as they occur and accumulated in a parse table structure. A notify message object is defined. This object is used as the index into the table of accumulated notify messages. This helps system administrators determine if there are potential configuration problems or attacks on their network. 3.8 IPSec MIB Traps Traps are provided to let system administrators know about the existence of error conditions occurring in the entity. Errors are associated with the creation and deletion of SAs, and also operational errors that may indicate the presence of attacks on the system. Traps are not provided when SAs come up or go down, unless they cannot be negotiated or go down due to error conditions. The causes of SA negotiation failure are indicated by a notify message object. 3.9 IPSec Entity Level Objects This part of the MIB carries statistics global to the IPSec device. Statistics included are aggregate usage and aggregate errors for both phase 1 SAs and phase 2 protection suites. The statistics are provided as objects in a tree below these groups. 4. MIB Definitions IPSEC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Counter64, Integer32, Unsigned32, experimental, NOTIFICATION-TYPE FROM SNMPv2-SMI DateAndTime, TruthValue FROM SNMPv2-TC; ipsecMIB MODULE-IDENTITY LAST-UPDATED "9903051200Z" ORGANIZATION "IETF IPSec Working Group" CONTACT-INFO " Tim Jenkins TimeStep Corporation 362 Terry Fox Drive Kanata, ON K0A 2H0 Canada 613-599-3610 tjenkins@timestep.com" DESCRIPTION "The MIB module to describe generic ISAKMP objects, IKE objects, IPSec objects, and entity level objects and events for those types." REVISION "9903051200Z" DESCRIPTION "Initial revision." -- replace xxx in next line before release, uncomment before release -- ::= { mib-2 xxx } -- delete next line before release ::= { experimental 500 } -- invalid! ipsecMIBObjects OBJECT IDENTIFIER ::= { ipsecMIB 1 } ipsec OBJECT IDENTIFIER ::= { ipsecMIBObjects 1 } isakmp OBJECT IDENTIFIER ::= { ipsecMIBObjects 2 } ike OBJECT IDENTIFIER ::= { ipsecMIBObjects 3 } -- the ISAKMP DOI-independent SA MIB-Group -- -- a collection of objects providing information about the -- DOI-independent portion of SAs generated using ISAKMP isakmpSaTable OBJECT-TYPE SYNTAX SEQUENCE OF IsakmpSaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing the DO-independent portion of ISAKMP SAs." ::= { isakmp 1 } isakmpSaEntry OBJECT-TYPE SYNTAX IsakmpSaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular IKE SA." INDEX { ipsecIkeSaIndex } ::= { ipsecIkeSaTable 1 } IsakmpSaEntry::= SEQUENCE { -- identification isakmpSaInitiatorCookie OCTET STRING (SIZE (16)), isakmpSaResponderCookie OCTET STRING (SIZE (16)), isakmpSaLocalIpV4Address IpAddress, isakmpSaLocalIpV6Address OCTET STRING (SIZE (16)), isakmpSaRemoteIpV4Address IpAddress, isakmpSaRemoteIpV6Address OCTET STRING (SIZE (16)), -- communication information isakmpSaLocalUdpPort INTEGER (0..65535), isakmpSaRemoteUdpPort INTEGER (0..65535), -- peer version information isakmpSaPeerMajorVersion INTEGER (0..15), isakmpSaPeerMinorVersion INTEGER (0..15), -- creation/status/type isakmpSaDoi Unsigned32, isakmpSaLocallyInitiated TruthValue, isakmpSaStatus INTEGER { negotiating(1), established(2) }, isakmpSaMode INTEGER { base(1), identityProtection(2), authOnly(3), agressive(4) }, } -- the ISAKMP Entity MIB-Group -- -- a collection of objects providing information about overall ISAKMP -- status in the entity -- -- Definitions of significant branches -- isakmpTrapsA OBJECT IDENTIFIER ::= { isakmp 2 } isakmpTraps OBJECT IDENTIFIER ::= { isakmpTrapsA 0 } isakmpStats OBJECT IDENTIFIER ::= { isakmp 3 } -- the IKE SA MIB-Group -- -- a collection of objects providing information about -- IKE SAs ikeSaTable OBJECT-TYPE SYNTAX SEQUENCE OF IkeSaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on IKE SAs." ::= { ike 1 } ikeSaEntry OBJECT-TYPE SYNTAX IkeSaEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular IKE SA." INDEX { ikeSaInitiatorCookie, ikeSaResponderCookie, ikeSaLocalIpV4Address, ikeSaLocalIpV6Address, ikeSaRemoteIpV4Address, ikeSaRemoteIpV6Address } ::= { ikeSaTable 1 } IpsecIkeSaEntry ::= SEQUENCE { -- identifier information ikeSaInitiatorCookie isakmpSaInitiatorCookie, ikeSaResponderCookie isakmpSaResponderCookie, ikeSaLocalIpV4Address isakmpSaLocalIpV4Address, ikeSaLocalIpV6Address isakmpSaLocalIpV6Address, ikeSaRemoteIpV4Address isakmpSaRemoteIpV4Address, ikeSaRemoteIpV6Address isakmpSaRemoteIpV6Address, -- ID and authentication information ikeSaAuthMethod Integer32, ikeSaPeerIdType Integer32, ikeSaPeerId OCTET STRING, ikeSaPeerCertSerialNum OCTET STRING, ikeSaPeerCertIssuer OCTET STRING, ikeSaLocalIdType Integer32, ikeSaLocalId OCTET STRING, -- security algorithm information ikeSaEncAlg INTEGER, ikeSaEncKeyLength Integer32, ikeSaHashAlg Integer32, ikeSaDifHelGroupDesc Integer32, ikeSaDifHelGroupType Integer32, ikeSaDifHelFieldSize Integer32, ikeSaPRF Integer32, ikeSaPFS TruthValue, -- expiration limits ikeSaTimeLimit Counter64, -- in seconds ikeSaTrafficLimit Counter64, -- in bytes -- operating statistics ikeSaTimeCount Counter64, -- in seconds ikeSaInboundTraffic Counter64, -- in bytes ikeSaOutboundTraffic Counter64, -- in bytes ikeSaInboundPackets Counter32, ikeSaOutboundPackets Counter32, ikeProtSuitesCreated Counter32, ikeProtSuitesDeleted Counter32, -- error statistics ikeSaDecryptErrors Counter32, ikeSaAuthErrors Counter32, ikeSaOtherReceiveErrors Counter32, ikeSaSendErrors Counter32 } -- the IKE Entity MIB-Group -- -- a collection of objects providing information about overall IKE -- status in the entity -- -- Definitions of significant branches -- ikeTrapsA OBJECT IDENTIFIER ::= { ike 2 } ikeTraps OBJECT IDENTIFIER ::= { ikeTrapsA 0 } ikeStats OBJECT IDENTIFIER ::= { ike 3 } ikeSaErrorStats OBJECT IDENTIFIER ::= { ike 4 } ikeProtSuiteStats OBJECT IDENTIFIER ::= { ike 5 } ikeProtSuiteErrorStats OBJECT IDENTIFIER ::= { ike 6 } -- -- entity IKE statistics -- ikeTotalProtSuites OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IKE protection suites successfully established by the entity since boot time." ::= { ikeStats 1 } ikeNegFailures OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of IKE protection suite negotiations that failed in the entity since boot time." ::= { ikeStats 2 } ikeTotalInboundPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of inbound packets carried on IKE SAs since boot time." ::= { ikeStats 3 } ikeTotalTransOutboundPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of outbound packets carried on IKE SAs since boot time." ::= { ikeStats 4 } ikeTotalTransInboundTraffic OBJECT-TYPE SYNTAX Counter64 UNITS "Kbytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The total amount of inbound traffic carried on IKE SAs since boot time, measured in 1024-octet blocks." ::= { ikeStats 5 } ikeTotalTransOutboundTraffic OBJECT-TYPE SYNTAX Counter64 UNITS "Kbytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The total amount of outbound traffic carried on IKE SAs since boot time, measured in 1024-octet blocks." ::= { ikeStats 6 } -- -- IKE SA error counts -- ikeProtocolErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the entity since boot time with IKE protocol errors. This includes packets with invalid cookies, but does not include errors that are associated with specific IKE SAs." ::= { ikeSaErrorStats 1 } ikeDecryptionErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the entity in IKE SAs since boot time with decryption errors." ::= { ikeSaErrorStats 2 } ikeAuthenticationErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the entity in IKE SAs since boot time with authentication errors. This includes all packets in which the hash value is determined to be invalid." ::= { ikeSaErrorStats 3 } ikeOtherReceiveErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the entity in IKE SAs since boot time and discarded due to errors not due to decryption or authentication." ::= { ikeSaErrorStats 4 } ikeSendErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets to be sent by the entity in IKE SAs since boot time and discarded due to errors." ::= { ikeSaErrorStats 5 } -- -- entity protection suite statistics -- ikeProtSuiteTotalInboundPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of inbound packets carried on all protection suites since boot time." ::= { ikeProtSuiteStats 1 } ikeProtSuiteTotalOutboundPackets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of outbound packets carried on all protection suites since boot time." ::= { ikeProtSuiteStats 2 } ikeProtSuiteTotalInboundTraffic OBJECT-TYPE SYNTAX Counter64 UNITS "Kbytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The total amount of inbound traffic carried on all protection suites since boot time, measured in 1024-octet blocks." ::= { ikeProtSuiteStats 3 } ikeProtSuiteTotalOutboundTraffic OBJECT-TYPE SYNTAX Counter64 UNITS "Kbytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The total amount of outbound traffic carried on all protection suites since boot time, measured in 1024-octet blocks." ::= { ikeProtSuiteStats 4 } -- -- IKE protection suite error counts -- ipsecProtSuiteReceiveErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets received by the entity in protection suites since boot time and discarded due to errors of any kind." ::= { ikeProtSuiteErrorStats 1 } ipsecIkeSendErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets to be sent by the entity in protection suites since boot time and discarded due to errors of any kind." ::= { ikeProtSuiteErrorStats 2 } -- the IPSec Inbound ESP MIB-Group -- -- a collection of objects providing information about -- IPSec Inbound ESP SAs ipsecSaEspInTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsecSaEspInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on IPSec inbound ESP SAs." ::= { ipsec 1 } ipsecSaEspInEntry OBJECT-TYPE SYNTAX IpsecSaEspInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular IPSec inbound ESP SA." INDEX { ipsecSaEspInV4Address, ipsecSaEspInV6Address, ipsecSaEspInSpi } ::= { ipsecSaEspInTable 1 } IpsecSaEspInEntry::= SEQUENCE { -- identification ipsecSaEspInV4Address IpAddress, ipsecSaEspInV6Address OCTET STRING (SIZE (16)), ipsecSaEspInSpi Unsigned32, -- SA selectors ipsecSaEspInDestId OCTET STRING, ipsecSaEspInDestIdType Unsigned32, ipsecSaEspInSourceId OCTET STRING, ipsecSaEspInSourceIdType Unsigned32, ipsecSaEspInProtocol Integer32, ipsecSaEspInDestPort Integer32, ipsecSaEspInSourcePort Integer32, -- security services description ipsecSaEspInEncapsulation INTEGER, ipsecSaEspInEncAlg Integer32, ipsecSaEspInEncKeyLength Unsigned32, ipsecSaEspInAuthAlg Integer32, -- expiration limits ipsecSaEspInTimeLimit Counter64, -- sec., 0 if none ipsecSaEspInTrafficLimit Counter64, -- 0 if none -- current operating statistics ipsecSaEspInTimeCount Counter64, ipsecSaEspInTrafficCount Counter64, ipsecSaEspInTraffic Counter64, ipsecSaEspInPackets Counter64, -- error statistics ipsecSaEspInDecryptErrors Counter32, ipsecSaEspInAuthErrors Counter32, ipsecSaEspInReplayErrors Counter32, ipsecSaEspInPolicyErrors Counter32, ipsecSaEspInOtherReceiveErrors Counter32, } -- the IPSec Inbound AH MIB-Group -- -- a collection of objects providing information about -- IPSec Inbound AH SAs ipsecSaAhInTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsecSaAhInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on IPSec inbound AH SAs." ::= { ipsec 2 } ipsecSaAhInEntry OBJECT-TYPE SYNTAX IpsecSaAhInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular IPSec inbound AH SA." INDEX { ipsecSaAhInV4Address, ipsecSaAhInV6Address, ipsecSaAhInSpi } ::= { ipsecSaAhInTable 1 } IpsecSaAhInEntry::= SEQUENCE { -- identification ipsecSaAhInV4Address IpAddress, ipsecSaAhInV6Address OCTET STRING (SIZE (16)), ipsecSaAhInSpi Unsigned32, -- SA selectors ipsecSaAhInDestId OCTET STRING, ipsecSaAhInDestIdType Unsigned32, ipsecSaAhInSourceId OCTET STRING, ipsecSaAhInSourceIdType Unsigned32, ipsecSaAhInProtocol Integer32, ipsecSaAhInDestPort Integer32, ipsecSaAhInSourcePort Integer32, -- security services description ipsecSaAhInEncapsulation INTEGER, ipsecSaAhInAuthAlg Integer32, -- expiration limits ipsecSaAhInTimeLimit Counter64, -- sec., 0 if none ipsecSaAhInTrafficLimit Counter64, -- 0 if none -- current operating statistics ipsecSaAhInTimeCount Counter64, ipsecSaAhInTrafficCount Counter64, ipsecSaAhInTraffic Counter64, ipsecSaAhInPackets Counter64, -- error statistics ipsecSaAhInAuthErrors Counter32, ipsecSaAhInReplayErrors Counter32, ipsecSaAhInPolicyErrors Counter32, ipsecSaAhInOtherReceiveErrors Counter32, } -- the IPSec Inbound IPCOMP MIB-Group -- -- a collection of objects providing information about -- IPSec Inbound IPCOMP SAs ipsecSaIpcompInTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsecSaIpcompInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on IPSec inbound IPCOMP SAs." ::= { ipsec 3 } ipsecSaIpcompInEntry OBJECT-TYPE SYNTAX IpsecSaIpcompInEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular IPSec inbound IPCOMP SA." INDEX { ipsecSaIpcompInV4Address, ipsecSaIpcompInV6Address, ipsecSaIpcompInCpi } ::= { ipsecSaIpcompInTable 1 } IpsecSaIpcompInEntry::= SEQUENCE { -- identification ipsecSaIpcompInV4Address IpAddress, ipsecSaIpcompInV6Address OCTET STRING (SIZE (16)), ipsecSaIpcompInCpi Unsigned32, -- SA selectors (if needed) ipsecSaIpcompInDestId OCTET STRING, ipsecSaIpcompInDestIdType Unsigned32, ipsecSaIpcompInSourceId OCTET STRING, ipsecSaIpcompInSourceIdType Unsigned32, ipsecSaIpcompInProtocol Integer32, ipsecSaIpcompInDestPort Integer32, ipsecSaIpcompInSourcePort Integer32, -- security services description ipsecSaIpcompInEncapsulation INTEGER, ipsecSaIpcompInCompAlg Integer32, -- current operating statistics ipsecSaIpcompInTraffic Counter64, ipsecSaIpcompInPackets Counter64, -- error statistics ipsecSaIpcompInDecompErrors Counter32, ipsecSaIpcompInOtherReceiveErrors Counter32, } -- IPCOMP assumptions: 1) Don't care about policy errors. 2) Don't care about expiration. 3) Selectors can be empty if IPCOMP is shared across multiple protection suites. -- the IPSec Outbound ESP MIB-Group -- -- a collection of objects providing information about -- IPSec Outbound ESP SAs ipsecSaEspOutTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsecSaEspOutEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on IPSec Outbound ESP SAs." ::= { ipsec 4 } ipsecSaEspOutEntry OBJECT-TYPE SYNTAX IpsecSaEspOutEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular IPSec Outbound ESP SA." INDEX { ipsecSaEspOutV4Address, ipsecSaEspOutV6Address, ipsecSaEspOutSpi } ::= { ipsecSaEspOutTable 1 } IpsecSaEspOutEntry::= SEQUENCE { -- identification ipsecSaEspOutV4Address IpAddress, ipsecSaEspOutV6Address OCTET STRING (SIZE (16)), ipsecSaEspOutSpi Unsigned32, -- SA selectors ipsecSaEspOutSourceId OCTET STRING, ipsecSaEspOutSourceIdType Unsigned32, ipsecSaEspOutDestId OCTET STRING, ipsecSaEspOutDestIdType Unsigned32, ipsecSaEspOutProtocol Integer32, ipsecSaEspOutSourcePort Integer32, ipsecSaEspOutDestPort Integer32, -- security services description ipsecSaEspOutEncapsulation INTEGER, ipsecSaEspOutEncAlg Integer32, ipsecSaEspOutEncKeyLength Unsigned32, ipsecSaEspOutAuthAlg Integer32, -- expiration limits ipsecSaEspOutTimeLimit Counter64, -- sec., 0 if none ipsecSaEspOutTrafficLimit Counter64, -- 0 if none -- current operating statistics ipsecSaEspOutTraffic Counter64, ipsecSaEspOutPackets Counter64, ipsecSaEspOutTimeCount Counter64, ipsecSaEspOutTrafficCount Counter64, -- error statistics ipsecSaEspOutSendErrors Counter32, } -- the IPSec Outbound AH MIB-Group -- -- a collection of objects providing information about -- IPSec Outbound AH SAs ipsecSaAhOutTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsecSaAhOutEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on IPSec Outbound AH SAs." ::= { ipsec 5 } ipsecSaAhOutEntry OBJECT-TYPE SYNTAX IpsecSaAhOutEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular IPSec Outbound AH SA." INDEX { ipsecSaAhOutV4Address, ipsecSaAhOutV6Address, ipsecSaAhOutSpi } ::= { ipsecSaAhOutTable 1 } IpsecSaAhOutEntry::= SEQUENCE { -- identification ipsecSaAhOutV4Address IpAddress, ipsecSaAhOutV6Address OCTET STRING (SIZE (16)), ipsecSaAhOutSpi Unsigned32, -- SA selectors ipsecSaAhOutSourceId OCTET STRING, ipsecSaAhOutSourceIdType Unsigned32, ipsecSaAhOutDestId OCTET STRING, ipsecSaAhOutDestIdType Unsigned32, ipsecSaAhOutProtocol Integer32, ipsecSaAhOutSourcePort Integer32, ipsecSaAhOutDestPort Integer32, -- security services description ipsecSaAhOutEncapsulation INTEGER, ipsecSaAhOutAuthAlg Integer32, -- expiration limits ipsecSaAhOutTimeLimit Counter64, -- sec., 0 if none ipsecSaAhOutTrafficLimit Counter64, -- 0 if none -- current operating statistics ipsecSaAhOutTraffic Counter64, ipsecSaAhOutPackets Counter64, ipsecSaAhOutTimeCount Counter64, ipsecSaAhOutTrafficCount Counter64, -- error statistics ipsecSaAhOutSendErrors Counter32, } -- the IPSec Outbound IPCOMP MIB-Group -- -- a collection of objects providing information about -- IPSec Outbound IPCOMP SAs ipsecSaIpcompOutTable OBJECT-TYPE SYNTAX SEQUENCE OF IpsecSaIpcompOutEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on IPSec Outbound IPCOMP SAs." ::= { ipsec 6 } ipsecSaIpcompOutEntry OBJECT-TYPE SYNTAX IpsecSaIpcompOutEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular IPSec Outbound IPCOMP SA." INDEX { ipsecSaIpcompOutV4Address, ipsecSaIpcompOutV6Address, ipsecSaIpcompOutCpi } ::= { ipsecSaIpcompOutTable 1 } IpsecSaIpcompOutEntry::= SEQUENCE { -- identification ipsecSaIpcompOutV4Address IpAddress, ipsecSaIpcompOutV6Address OCTET STRING (SIZE (16)), ipsecSaIpcompOutCpi Unsigned32, -- SA selectors ipsecSaIpcompOutSourceId OCTET STRING, ipsecSaIpcompOutSourceIdType Unsigned32, ipsecSaIpcompOutDestId OCTET STRING, ipsecSaIpcompOutDestIdType Unsigned32, ipsecSaIpcompOutProtocol Integer32, ipsecSaIpcompOutSourcePort Integer32, ipsecSaIpcompOutDestPort Integer32, -- security services description ipsecSaIpcompOutEncapsulation INTEGER, ipsecSaIpcompOutCompAlg Integer32, -- current operating statistics ipsecSaIpcompOutTraffic Counter64, ipsecSaIpcompOutPackets Counter64, } -- IPCOMP assumptions: 1) Don't care about policy errors. 2) Don't care about expiration. 3) Selectors can be empty if IPCOMP is shared across multiple protection suites. 4) There are no send errors; will send uncompressed if can't compress. -- the IKE Protection Suites MIB-Group -- -- a collection of objects providing information about -- protection suites ikeProtSuiteTable OBJECT-TYPE SYNTAX SEQUENCE OF IkeProtSuiteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table containing information on IKE protection suites." ::= { ike 2 } ikeProtSuiteEntry OBJECT-TYPE SYNTAX IkeProtSuiteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) containing the information on a particular protection suite." INDEX { ikeProtSuiteIndex } ::= { ikeProtSuiteTable 1 } IkeProtSuiteEntry ::= SEQUENCE { ikeProtSuiteIndex Integer32, -- identification ikeProtSuiteLocalV4Address IpAddress, ikeProtSuiteLocalV6Address OCTET STRING (SIZE (16)), ikeProtSuiteRemoteV4Address IpAddress, ikeProtSuiteRemoteV6Address OCTET STRING (SIZE (16)), ikeProtSuiteSa1Protocol Unsigned32, ikeProtSuiteInSa1Spi Unsigned32, ikeProtSuiteOutSa1Spi Unsigned32, ikeProtSuiteSa2Protocol Unsigned32, ikeProtSuiteInSa2Spi Unsigned32, ikeProtSuiteOutSa2Spi Unsigned32, ikeProtSuiteSa3Protocol Unsigned32, ikeProtSuiteInSa3Spi Unsigned32, ikeProtSuiteOutSa3Spi Unsigned32, -- created by (need to make this optional for protection?) ikeProtSuiteLocalOwnerId OCTET STRING, ikeProtSuiteLocalOwnerIdType Unsigned32, ikeProtSuiteRemoteOwnerId OCTET STRING, ikeProtSuiteRemoteOwnerIdType Unsigned32, -- protection suite selectors ikeProtSuiteLocalId OCTET STRING, ikeProtSuiteLocalIdType Unsigned32, ikeProtSuiteRemoteId OCTET STRING, ikeProtSuiteRemoteIdType Unsigned32, ikeProtSuiteProtocol Integer32, ikeProtSuiteLocalPort Integer32, ikeProtSuiteRemotePort Integer32, -- creation mechanism ikeProtSuiteLocallyInitiated TruthValue, ikeProtSuiteDifHelGroupDesc Integer32, ikeProtSuiteDifHelGroupType Integer32, ikeProtSuitePFS TruthValue, -- expiration limits ikeProtSuiteTimeLimit Counter64, -- sec., 0 if none ikeProtSuiteTrafficLimit Counter64, -- 0 if none -- current operating statistics ikeProtSuiteInTraffic Counter64, ikeProtSuiteInPackets Counter64, ikeProtSuiteOutTraffic Counter64, ikeProtSuiteOutPackets Counter64, ikeProtSuiteTimeCount Counter64, ikeProtSuiteInTrafficCount Counter64, ikeProtSuiteOutTrafficCount Counter64, -- current operating statistics ikeProtSuiteInboundTraffic Counter64, ikeProtSuiteOutboundTraffic Counter64, ikeProtSuiteInboundPackets Counter64, ikeProtSuiteOutboundPackets Counter64, -- error statistics ikeProtSuiteReceiveErrors Counter32, ikeProtSuiteSendErrors Counter32 } <== --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 From owner-ipsec@portal.ex.tis.com Tue Mar 9 11:35:19 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 LAA20162; Tue, 9 Mar 1999 11:35:18 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA19852 for ipsec-outgoing; Tue, 9 Mar 1999 10:00:20 -0500 (EST) From: Steve Bellovin To: ipsec@tislabs.com, end2end-interest@isi.edu, tsv@ee.lbl.gov, diff-serv@BayNetworks.COM, ecn-interest@research.att.com, red-impl@lbl.gov, tf-esp@research.att.com Subject: last call for tf-esp BoF speakers Reply-To: smb@research.att.com Cc: vern@ee.lbl.gov, sob@harvard.edu, jis@MIT.EDU, mleech@nortel.ca Date: Tue, 09 Mar 1999 10:21:28 -0500 Message-Id: <19990309152134.40E8CACAA7@smb.research.att.com> Sender: owner-ipsec@ex.tis.com Precedence: bulk Please forgive the broad-spectrum mail -- I've set Reply-To to force responses to come to me, rather than to all of these lists. I'm still looking for speakers for the tf-esp BoF -- right now, it's marginal whether or not there are enough signed up to justify meeting. I'm looking for people to speak on (a) why we need this facility, (b) why we don't, or other ways to accomplish the same goal, and (c) proposals for how to modify the ESP header to leak what is desired. From owner-ipsec@portal.ex.tis.com Tue Mar 9 20: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 UAA10786; Tue, 9 Mar 1999 20:36:06 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id VAA22453 for ipsec-outgoing; Tue, 9 Mar 1999 21:00:26 -0500 (EST) Message-Id: <199903092306.SAA00354@pzero.sandelman.ottawa.on.ca> To: ipsec@portal.gw.tislabs.com Subject: Vendor ID issues Date: Tue, 09 Mar 1999 18:06:53 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Bob and I have had a number of discussions about the Vendor ID payload. ICSA testing has revealed that quite a number of people are uncertain about what the VID is for. I have produced a BCP that provides a longer example of how to use it. I do not pretend it is complete. The BCP missed last Friday's deadline due to lack of proper boilerplate. I have proposed to Ted to take 15 minutes of IPsec meeting time to try and lead a discussion about what VID is for. Bob and my most recent exchange is below. >>>>> "Robert" == Robert Moskowitz writes: Robert> This highlights the whole problem with Vendor ID. Robert> Consider: Robert> Vendor X develops the foo extenstion to IKE and ships it Robert> with release 5.6 of XOS. Robert> Vendor Y enters into an agreement with X and supports foo Robert> in release 3.4 of YOS; meanwhile XOS is upgraded to 5.7 to Robert> recognize Vendor ID Y. Robert> However, Y was smart, realizing that many X customers Robert> would not be so fast to upgrade. I'm missing a sentence here. What did Y do to be smart? Robert> If X was the intiator, Y would go right into foo mode and Robert> not bother to send its ID. That isn't according to spec. Y should still send its VID. Robert> If Y was the initiator, and X rejected Y's ID, when Y Robert> receives X's ID, Y would still do foo. If X sends a VID, then it should assume that whomever it is talking to can send extensions *TO* it using the private use space. The fact that X does not recognize Y's VID means that X may be unable to respond. Possibly that calls for a specific notify message. But, some payloads may not require responses anyway. The private use spaces are unique to the *receiver* of the payload. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNuWpiR4XQavxnHg9AQHG3QIAn8sdHM+xmp3qLgVyWauIa+KGXVCUrlUC a19GlIxeU+GY4qll+G7x0TVYYVjuRe7T0DBlIXyh9t/px+xf+XC+qQ== =9ls2 -----END PGP SIGNATURE----- From owner-ipsec@portal.ex.tis.com Wed Mar 10 09:12: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 JAA02969; Wed, 10 Mar 1999 09:12:06 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA24139 for ipsec-outgoing; Wed, 10 Mar 1999 08:32:22 -0500 (EST) Message-ID: <36E6792F.C2428826@ubs.com> Date: Wed, 10 Mar 1999 14:52:47 +0100 From: Stefan =?iso-8859-1?Q?M=FCller?= Organization: Union Bank of Switzerland X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,de-CH,fr-CH,it MIME-Version: 1.0 To: ipsec@tislabs.com Subject: Main versus Aggressive Mode Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk hi, is IKE exchange in aggressive mode as secure as in main mode? what are the disadvantages of aggressive mode? thanks stefan mueller From owner-ipsec@portal.ex.tis.com Wed Mar 10 10:55: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 KAA03874; Wed, 10 Mar 1999 10:55:49 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA24991 for ipsec-outgoing; Wed, 10 Mar 1999 11:23:19 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF8AB905@exchange> From: Tim Jenkins To: PJ Kirner , ipsec@tislabs.com Subject: RE: Host configuration Date: Wed, 10 Mar 1999 11:45:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@ex.tis.com Precedence: bulk Just a couple days ago (Mon 3/8/99 11:32 AM), Roy Pereira [rpereira@TimeStep.com], responded to this: ==> I will resubmit a new version of it after the IPSec Remote Access BOF next week. > -----Original Message----- > From: Bronislav Kavsan [mailto:bkavsan@ire-ma.com] > Sent: Thursday, March 04, 1999 9:07 PM > To: Scott G. Kelly > Cc: ipsec@tis.com > Subject: Re: where is the ikecfg draft? > > > Didn't it expire last November? :) > > Scott G. Kelly wrote: > > > The ikecfg draft is at > > > > http://www.ietf.org/ids.by.wg/ipsec.html > > > > <== --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: PJ Kirner [mailto:pjkirner@tril-inc.com] > Sent: Wednesday, March 10, 1999 11:14 AM > To: ipsec@tislabs.com > Subject: Host configuration > > > I am looking into host configuration (i.e. assigning IP > address information > across a VPN to a VPN Client). I see that there are two > drafts that address > this somewhat draft-ietf-ipsec-isakmp-mode-cfg-04.txt which > was published > out in May of 98 and has since expired. And a newer one > draft-ietf-ipsec-dhcp-01.txt that was published in December > of 98. I was > wondering what the status of these documents are and if the > ISAKMP Mode > Configuration path had been allowed to expire because it was > being replace > in favor of the IPSEC HDCP draft? > > Any advice in this area would be greatly appreciated or a > maybe I am missing > another relevant document that would specify more completly > how to do this. > > PJ Kirner > > > From owner-ipsec@portal.ex.tis.com Wed Mar 10 10:58: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 KAA03889; Wed, 10 Mar 1999 10:58:41 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id LAA25004 for ipsec-outgoing; Wed, 10 Mar 1999 11:26:05 -0500 (EST) Message-Id: <199903101647.IAA05816@potassium.network-alchemy.com> To: Michael Richardson cc: ipsec@portal.gw.tislabs.com Subject: Re: Vendor ID issues In-reply-to: Your message of "Tue, 09 Mar 1999 18:06:53 EST." <199903092306.SAA00354@pzero.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5813.921084460.1@network-alchemy.com> Date: Wed, 10 Mar 1999 08:47:40 -0800 From: Dan Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk I had a similar exchange with Bob over this. I don't know why ICSA is testing this stuff. They're having enough trouble just figuring out how to test main mode with pre-shard keys! As far as interoperability is concerned, if you barf upon receipt of a vendor ID payload you don't recognize then you're broken. draft-ietf-ipsec-isakmp-mode-cfg-04.txt (yea, it's expired but it helps me make a point) defines the use of an exchange and payload from the reserved areas. This is wrong. I-Ds can't just start grabbing numbers from the reserved numberspace. The vendor ID payload is used to fix this problem. The draft should've defined numbers from the private use range and defined a vendor ID payload to use for implementations that wish to implement and test this new mode. If the peer does not produce the required vendor ID payload then you can't initiate the mode to it. When the I-D advances it can be assigned valid exchange and payload numbers by IANA and the verbage discussing the vendor ID payload to use for testing can be dropped. But that didn't happen. :-( Now we have several implementations of this draft that use reserved magic numbers. The BCP is definitely needed before this is repeated. Can you post it to the list? Dan. On Tue, 09 Mar 1999 18:06:53 EST you wrote > -----BEGIN PGP SIGNED MESSAGE----- > > > Bob and I have had a number of discussions about the Vendor ID payload. > ICSA testing has revealed that quite a number of people are > uncertain about what the VID is for. > > I have produced a BCP that provides a longer example of how to > use it. I do not pretend it is complete. The BCP missed last Friday's > deadline due to lack of proper boilerplate. I have proposed to Ted to > take 15 minutes of IPsec meeting time to try and lead a discussion > about what VID is for. > > Bob and my most recent exchange is below. From owner-ipsec@portal.ex.tis.com Wed Mar 10 11:01: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 LAA03939; Wed, 10 Mar 1999 11:01:50 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id KAA24886 for ipsec-outgoing; Wed, 10 Mar 1999 10:52:19 -0500 (EST) Message-ID: <017d01be6b10$f44a9590$1eacddcf@osiris.tril-inc.com> From: "PJ Kirner" To: Subject: Host configuration Date: Wed, 10 Mar 1999 11:13:37 -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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk I am looking into host configuration (i.e. assigning IP address information across a VPN to a VPN Client). I see that there are two drafts that address this somewhat draft-ietf-ipsec-isakmp-mode-cfg-04.txt which was published out in May of 98 and has since expired. And a newer one draft-ietf-ipsec-dhcp-01.txt that was published in December of 98. I was wondering what the status of these documents are and if the ISAKMP Mode Configuration path had been allowed to expire because it was being replace in favor of the IPSEC HDCP draft? Any advice in this area would be greatly appreciated or a maybe I am missing another relevant document that would specify more completly how to do this. PJ Kirner From owner-ipsec@portal.ex.tis.com Wed Mar 10 12:40: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 MAA04769; Wed, 10 Mar 1999 12:40:23 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA25490 for ipsec-outgoing; Wed, 10 Mar 1999 13:04:19 -0500 (EST) Message-ID: <36E6B966.1F4A3881@redcreek.com> Date: Wed, 10 Mar 1999 10:26:46 -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: PJ Kirner CC: ipsec@tislabs.com Subject: Re: Host configuration References: <017d01be6b10$f44a9590$1eacddcf@osiris.tril-inc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk PJ Kirner wrote: > > I am looking into host configuration (i.e. assigning IP address information > across a VPN to a VPN Client). I see that there are two drafts that address > this somewhat draft-ietf-ipsec-isakmp-mode-cfg-04.txt which was published > out in May of 98 and has since expired. And a newer one > draft-ietf-ipsec-dhcp-01.txt that was published in December of 98. I was > wondering what the status of these documents are and if the ISAKMP Mode > Configuration path had been allowed to expire because it was being replace > in favor of the IPSEC HDCP draft? > You'll get a chance to hear about both mechanisms at the IP Security Remote Access BOF (ipsra) if you're at the upcoming IETF. From owner-ipsec@portal.ex.tis.com Wed Mar 10 14: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 OAA06364; Wed, 10 Mar 1999 14:20:27 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id OAA25768 for ipsec-outgoing; Wed, 10 Mar 1999 14:31:17 -0500 (EST) Message-Id: <199903101952.OAA24495@istari.sandelman.ottawa.on.ca> To: ipsec@tislabs.com Subject: Re: Vendor ID issues In-Reply-To: Your message of "Wed, 10 Mar 1999 08:47:40 PST." <199903101647.IAA05816@potassium.network-alchemy.com> Date: Wed, 10 Mar 1999 14:52:17 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Dan" == Dan Harkins writes: Dan> I had a similar exchange with Bob over this. I don't know why ICSA Dan> is testing this stuff. They're having enough trouble just figuring out Dan> how to test main mode with pre-shard keys! As far as interoperability Dan> is concerned, if you barf upon receipt of a vendor ID payload you don't Dan> recognize then you're broken. They aren't testing it. Rather they are experiencing the brokenness because some product does not accept it, but at the time it was tested, nobody sent it. Dan> required vendor ID payload then you can't initiate the mode to it. When Dan> the I-D advances it can be assigned valid exchange and payload numbers Dan> by IANA and the verbage discussing the vendor ID payload to use for Dan> testing can be dropped. But that didn't happen. :-( Now we have several It isn't clear to me what one does if one receives an ISAKMP initiator packet that has a version number greater than one's own. I think that if you receive minor > ME, that you do not respond, but rather you initiate again with your major/minor, and the *same* cookies. I think that if you receive major > ME that you initiate with new cookies. We have to work this out. I would think that major number increments mean that major things have changed, i.e. interpretation of payloads, etc. Dan> The BCP is definitely needed before this is repeated. Can you post it Dan> to the list? http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsec-vendorid.txt :!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 iQDVAwUBNubNYnMJp3VWzPepAQHl0wX9GSfyu7T/toTiTZ2DwlecqXJ5YLGEHhEM MVbK7I8pxoVZAEZ7nxwc5ZaZp8NcHL+WynS3ZYdpCzfKUccxT6t2h1x1Qum5JCiP gAyrGjDGDpgKN8mPtCOfaAVyynH9Fye/DG6JincQ1vxMbaeTYcadc1i3BDghTAwA JLezfJWP3yYXksAdmaPfdv0HtPTJ4xZ8FMSDDeCBMVfbcoYBh+TxLCPf0qhigNjQ Efshl5mJv7sqWOHg9b1Vh/0rrFJixW5N =53DZ -----END PGP SIGNATURE----- From owner-ipsec@portal.ex.tis.com Wed Mar 10 14:54: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 OAA07820; Wed, 10 Mar 1999 14:54:30 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id PAA25909 for ipsec-outgoing; Wed, 10 Mar 1999 15:22:23 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF8ABAB6@exchange> From: Tim Jenkins To: "Michael C. Richardson" , ipsec@tislabs.com Subject: Version Issues (was RE: Vendor ID issues ) Date: Wed, 10 Mar 1999 15:44:09 -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 Michael raises version number issues; I have some concerns of my own. When I read the drafts, it appears that the version numbers belong to ISAKMP. If this is correct, how do we indicate versions of IKE (or any other protocol, for that matter)? I don't think the vendor ID is either intended or appropriate for this (to indicate additional capabilities of the protocol). Could it be that the version numbers in the ISAKMP header refer to the DOI that is using ISAKMP? This leads to a problem if you use ISAKMP DOI of 0. In that case, what's the version number of IKE or another protocol that uses ISAKMP? The rules that Michael's proposing probably cannot be made until the version number usage and meanings are clarified. (It would help the MIB definition, too.) --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Michael C. Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Wednesday, March 10, 1999 2:52 PM > To: ipsec@tislabs.com > Subject: Re: Vendor ID issues > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > It isn't clear to me what one does if one receives an > ISAKMP initiator > packet that has a version number greater than one's own. > I think that if you receive minor > ME, that you do not > respond, but rather > you initiate again with your major/minor, and the *same* cookies. > I think that if you receive major > ME that you initiate > with new cookies. > We have to work this out. I would think that major number > increments mean > that major things have changed, i.e. interpretation of payloads, etc. > :!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 Wed Mar 10 15:56: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 PAA10513; Wed, 10 Mar 1999 15:56:22 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id QAA26063 for ipsec-outgoing; Wed, 10 Mar 1999 16:28:22 -0500 (EST) Message-ID: <6236E58EC451D1119E80006097040ED9B0561D@lobester.rsa.com> From: Bob Baldwin To: ipsec@tislabs.com Cc: Bob Baldwin Subject: RSA is hiring crypto software engineers Date: Wed, 10 Mar 1999 13:53:46 -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 I know I am treading on thin ice with this posting, but I thought that some members of the IPSec mailing list would be interested in knowing that RSA has several job openings for software engineers with a background in crypto or protocols. For details, please check out our website at: http://www.rsa.com/rsa/jobs/html/sw_dev_eng.html --Bob Baldwin Technical Director, RSA Data Security From owner-ipsec@portal.ex.tis.com Wed Mar 10 16:34: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 QAA11912; Wed, 10 Mar 1999 16:34:25 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id RAA26195 for ipsec-outgoing; Wed, 10 Mar 1999 17:17:29 -0500 (EST) Message-Id: <199903102238.RAA12550@venus.solidum.com> To: "Black, David" CC: ipsec@tislabs.com Subject: Re: ECN and IPsec tunnels In-reply-to: Your message of "Mon, 01 Mar 1999 16:00:27 EST." <29D5E8EB2B79D211BE9500E0292494A2014D5488@42s1143.isus.emc.com> Date: Wed, 10 Mar 1999 17:38:09 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Black," == Black, David writes: Black,> Those with good memories may recall discussion of what to do Black,> about the fact that IPsec tunnels ignore and discard the DS field Black,> on tunnel egress, meaning that diff-serv markings won't propagate Black,> across tunnel egress. The promised draft on ECN and IPsec Black,> tunnels has been written (it's rather longer that I thought it Black,> would be). This is the precursor to any work on diff-serv and Black,> IPsec tunnels -- I invite anyone who's interested to take a look Black,> and send comments to the authors (including yours truly). Black,> Reading the ECN RFC (2481) before this draft is strongly Black,> recommended. We also got bitten by the submission deadline, and Black,> hence the draft is at: Black,> ftp://ftp.ee.lbl.gov/papers/draft-ipsec-ecn-00.txt I would suggest that or'ing the outer ECN bits with the inner ECN bits on tunnel egress is the thing to do. This is something that should be negotiated as an SA attribute by IKE. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: mcr@solidum.com. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.5.1, an Emacs/PGP interface iQCVAwUBNub0O4PZOgmMo+2lAQEjRwP/cosY/H9bphERKfSlq5dYkJkJRLtxcGpj 3iP+NhDnkV6V9grKp9sW54oUCAgWrvIiQjmzPPLyOh6ZQyeSABNTAUjhr3lhhx+/ AWSm6ugY4E+uinFmN/eKz9HGKfGHH4q1eYzqoak44aGGk7MJbJw38wyIMAnQoxJW oGVqacn56sc= =zT1x -----END PGP SIGNATURE----- From owner-ipsec@portal.ex.tis.com Wed Mar 10 23:36: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 XAA27177; Wed, 10 Mar 1999 23:36:42 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id WAA27079 for ipsec-outgoing; Wed, 10 Mar 1999 22:58:30 -0500 (EST) Date: Wed, 10 Mar 1999 20:18:55 -0800 (PST) Message-Id: <199903110418.UAA15042@cayman-islands.isi.edu> From: Clifford Neuman To: the-computer-security-community@isi.edu Subject: Workshop on Countering Cyber-Terrorism Reply-to: bcn@isi.edu Sender: owner-ipsec@ex.tis.com Precedence: bulk Countering Cyber-Terrorism June 22-23 Marina del Rey, California A workshop sponsored by the Information Sciences Institute of the University of Southern California Call for Participation Recent studies warn of Cyber-Terrorism and the vulnerability of our computer systems and infrastructure to attack. These reports identify damage that determined, knowledgeable, and well-financed adversaries could inflict on commercial, government, and military systems. Such attacks would have severe consequences for the public, and in particular the economy, which has become dependant on computers and communications infrastructure. The objective of this workshop is to identify things that should be done to improve our ability to detect, protect against, contain, neutralize, mitigate the effects of, and recover from cyber-terrorist attacks. Participants are sought from the computer security, electronic commerce and banking, network infrastructure, military, and counter-terrorism communities, as well as those with experience of cyber-terrorist attacks. Recommendations may suggest research and development or operational measures that can be taken. The workshop is NOT a forum for presentation of the latest security systems, protocols or algorithms. The workshop will address the strategies, framework, and infrastructure required to combine and incrementally deploy such technologies to counter the cyber-terrorist threat. Attendance will be limited to approximately 25 participants. Participants will be selected on the basis of submitted position papers that raise issues for the workshop to discuss, identify threats or countermeasures, or propose strategies or infrastructure to counter the threat of cyber-terrorism. Position papers should be four pages or less in length. Submissions should be sent in e-mail in Word or PDF format, or as ASCII text to cyber-terrorism-ws@isi.edu. Please check the web page http://www.isi.edu/cctws for more information, including a position paper from the organizers which will be available two weeks prior to the submission deadline. Important Dates: Organizer's Paper Available April 5, 1999 Position Papers Due April 19, 1999 Notification of Acceptance May 1, 1999 Revised Position Papers Due May 28, 1999 Position Papers Available on Web June 9 Workshop Dates June 22-23 Organizing Committee: Bob Balzer, Information Sciences Institute, Balzer@isi.edu Thomas Longstaff, CERT Coordination Center, tal@cert.org Don Faatz, the MITRE Corporation, dfaatz@mitre.org Clifford Neuman, Information Sciences Institute, bcn@isi.edu From owner-ipsec@portal.ex.tis.com Thu Mar 11 08:45: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 IAA10359; Thu, 11 Mar 1999 08:45:20 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA28459 for ipsec-outgoing; Thu, 11 Mar 1999 08:09:27 -0500 (EST) Message-ID: <29D5E8EB2B79D211BE9500E0292494A2014D54D5@42s1143.isus.emc.com> From: "Black, David" To: "'Michael Richardson'" , "Black, David" Cc: ipsec@tislabs.com Subject: RE: ECN and IPsec tunnels Date: Wed, 10 Mar 1999 17:48:54 -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 > I would suggest that or'ing the outer ECN bits with the inner ECN > bits on tunnel egress is the thing to do. This is something that should be > negotiated as an SA attribute by IKE. That is exactly what the draft proposes (only one ECN bit is involved), including support for negotiating this as an SA attribute negotiation and the related SAD modification (both of the latter are OPTIONAL for obvious reasons). Was some of this not clear from the draft when you read it? --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909 black_david@emc.com --------------------------------------------------- From owner-ipsec@portal.ex.tis.com Thu Mar 11 13:42: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 NAA13494; Thu, 11 Mar 1999 13:42:05 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id NAA29666 for ipsec-outgoing; Thu, 11 Mar 1999 13:23:03 -0500 (EST) Message-ID: From: Ricky Charlet To: "'Partha P. Bhattacharya'" , "'ipsec@lists.tislabs.com'" Subject: RE: policy expressive power in IPSec-VPN policy draft Date: Thu, 11 Mar 1999 10:45:25 -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 Hey thanks, Actually I knew that about the draft-ietf-ipsec-vpn. I have reciently posted two question sets. One was to the 'policy group'I asking the policy group if they are prepared to deal with the 'negotiating proposals'. The other was to the IPSec group asking some specific questions about this draft. I am not sure which you are responding to. My questions (as posted about this draft) so far remain unaswered by anyone. Here they are again. I have a few questions about the Draft "An LDAP Schema for Configuration and Administration of IPSec based Virtual Private Networks (VPNs)" draft-ipsec-vpn-policy-schema-oo.txt Even if you have only a subset of answers, I'd be interested. 1. Has anyone built a MIB translation of LDAP formatted draft-ietf-ipsec-vpn-policy-schema-00.txt? 2. The IPSecProposal object includes one AHTransformRef, one ESPTransformRef, and one IPCOMPTransformRef. Is the intention here to limit SA bundles to the possible combination of one each from the above three possibilities? 3. Could there be a way for the PolicyAction object to be able to reference vendor specific actions not defined in this draft? What would be the minimum requisites. 4. In the IPSecSecurityAction, aren't the *proxied* objects redundant with the IPPolicyCondition which brought this action into play? 5. What do you think of changing the *autoStartFlag objects to *autoStartCondition objects which would have references like: always never duringTimeRange X..Y if interface X is down if interface X is heavily loaded 6. Inside of one IPSecProposal are we limited to one DH group for all transforms (ESP, AH)? 7. What are the reasons for making ISAKMPAction a PolicyAction? Arn't the 'PolicyCondition's for selection ISAKMPAction trivial and possibly even unalterable by local policy ? I see that ISAKMPAction is reference from IPSecSecurityAction, this seems appropriate and sufficient to me. 8. Does anyone have some opinions about how external authentication/authorization engines might be married into this draft? 9. Suppose two packets pass through a security gateway, receiving IPSec treatment. On the first packet, how does this schema allow multiple ISAKMP and IPSec proposals to be offered in the two negotiation phases? On the second packet, how does this schema identify those particular proposals (ISAKMP and IPSec, one each) that won the negotiation when the first packet passed? Ricky Charlet rcharlet@redcree.com -----Original Message----- From: Partha P. Bhattacharya [mailto:pbhattac@cisco.com] Sent: Wednesday, March 10, 1999 10:43 PM To: policy@raleigh.ibm.com Cc: rcharlet@redcreek.com Subject: policy expressive power in IPSec-VPN policy draft Ricky: In short, the LDAP VPN policy schema draft draft-ietf-ipsec-vpn-policy-schema-00.txt provides the full policy expressive power as required by IPSec. The basic version of an IPSec (data protection) policy as described in the draft consists of - one PolicyCondition object and - one IPSecSecurityAction object - one ISAKMPAction object The IPSecSecurityAction object consists of tunnel end point descriptions and a list of IPSecProposal objects (semantics between multiple proposals is logical OR). The preference can be ndicated by doing "n:DN". Each proposal is an IPSec transform set; it consist of - a list of AH transforms, - optionally a list of ESP transforms and - optionally a list of IPCOMP transforms. AH, ESP and IPCOMP transform objects are represented as IPSecTransform objects (it includes a type that indicates what protocol it corresponds to). If multiple AH (resp. ESP, IPCOMP) transforms are present in the same IPSec proposal then the semantics is logical OR. The preference can be indicated by doing "n:DN". The semantics of any combination of AH, ESP and IPCOMP protocols in an IPSec proposal is logical AND. Consider the following multi-proposal example, suppose your policy is - if HTTP to dest 1.1.1.* then - do ipsec and negotiate two proposals - either ESP= 3DES, SHA and AH = SHA or MD5 (first preference) - or EPS = DES, SHA (second preference) Policy: - PolicyConditionRef ---------> PolicyCondition object (proto= HTTP, destAddr = 1.1.1.X) - IPSecSecurityAction --------->IPSecProposal obj attr: AHTransformRef -------->IPSecTransform obj (attrib. AHProtocol = SHA) -------->IPSecTransform obj (attrib. AHProtocol = MD5) attr: ESPTransformRef------->IPSecTransform obj (attrib ESPCipher = 3DES, ESPAuth = SHA) ---------->IPSecProposal obj attr: ESPTransformRef------->IPSecTransform obj (attrib ESPCipher = DES, ESPAuth = SHA) Hope this answers your question. Partha P. Bhattacharya Internet Services Management Group Cisco Systems 255 Tasman Drive San Jose CA 95134 From owner-ipsec@portal.ex.tis.com Fri Mar 12 08:33: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 IAA16682; Fri, 12 Mar 1999 08:33:41 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id HAA03257 for ipsec-outgoing; Fri, 12 Mar 1999 07:56:38 -0500 (EST) X-Envelope-Sender-Is: muljawan.hendrianto@siemens.com.sg (at relayer david.siemens.com.sg) Message-ID: <27319248F5AFD111B5240060B067FACC0127CC9F@sgpk100a.siemens.com.sg> From: "Hendrianto Muljawan, SCN/SAE" To: ipsec@lists.tislabs.com Subject: ipsec implementation Date: Fri, 12 Mar 1999 11:15:18 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello all, I just joined this lists a few days ago. I have heard about IPSEC when I attended the APRICOT 1999. I have read some ietf drafts about this topics, but I couldn't found any information about what kind of software I need to implement it in a mix of UNIX-Windows NT environment and about the possibility to use PPTP. It will be greatly appreciated if someone could give me some hints of some websites/drafts about this. best regards, Muljawan Hendrianto Siemens Advanced Engineering Pte.Ltd. Siemens Corporate Network Division 2 Kallang Sector Singapore 349277 Tel: +65 7407554 Fax: +65 7407497 From owner-ipsec@portal.ex.tis.com Fri Mar 12 08:51: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 IAA16835; Fri, 12 Mar 1999 08:51:33 -0800 (PST) Received: by portal.ex.tis.com (8.9.1/8.9.1) id IAA03474 for ipsec-outgoing; Fri, 12 Mar 1999 08:55:33 -0500 (EST) Message-ID: <36E9223B.BAC20FB5@sympatico.ca> Date: Fri, 12 Mar 1999 09:18:35 -0500 From: Sandy Harris X-Mailer: Mozilla 4.5 [en]C-SYMPA (Win95; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: ipsec implementation References: <27319248F5AFD111B5240060B067FACC0127CC9F@sgpk100a.siemens.com.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk "Hendrianto Muljawan, SCN/SAE" wrote: > I have read some ietf drafts about this topics, but I couldn't found any > information about what kind of software I need to implement it in a mix of > UNIX-Windows NT environment and about the possibility to use PPTP. > It will be greatly appreciated if someone could give me some hints of some > websites/drafts about this. A 1997 list of 40-odd implementations is at: http://www.mit.edu/~tytso/ipsec/results9710.html I don't know of a newer list & would love to hear if there is one. Vendor groups with pointers to various things: http://www.rsa.com/rsa/SWAN S/WAN Secure Wide Area Networking http://www.vpnc.org newly formed VPN Consortium Open source distributions include: http://www.x4all.nl/~freeswan for Linux http://www.kame.net/project-overview.html for various *BSD Unices From owner-ipsec@lists.tislabs.com Fri Mar 12 23:58:22 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA10420; Fri, 12 Mar 1999 23:58:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA11103 Sat, 13 Mar 1999 00:17:39 -0500 (EST) Message-Id: <199903130233.VAA17247@pzero.sandelman.ottawa.on.ca> To: ipsec@tislabs.com Subject: Re: Version Issues (was RE: Vendor ID issues ) In-reply-to: Your message of "Wed, 10 Mar 1999 15:44:09 EST." <319A1C5F94C8D11192DE00805FBBADDF8ABAB6@exchange> Date: Fri, 12 Mar 1999 21:33:53 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tim" == Tim Jenkins writes: Tim> Michael raises version number issues; I have some concerns of Tim> my own. When I read the drafts, it appears that the version Tim> numbers belong to ISAKMP. If this is correct, how do we Tim> indicate versions of IKE (or any other protocol, for that Tim> matter)? I don't think the vendor ID is either intended or Tim> appropriate for this (to indicate additional capabilities of Tim> the protocol). I would propose that the minor number be turned into a DOI number. That's be my choice. The DOI just involves changes to numbers, not packet formats. Maybe we don't have enough bits there for the DOI. Tim> Could it be that the version numbers in the ISAKMP header Tim> refer to the DOI that is using ISAKMP? This leads to a Tim> problem if you use ISAKMP DOI of 0. In that case, what's the Tim> version number of IKE or another protocol that uses ISAKMP? Tim> The rules that Michael's proposing probably cannot be made Tim> until the version number usage and meanings are Tim> clarified. (It would help the MIB definition, too.) No kidding! ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Sun Mar 14 14:58:35 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA29305; Sun, 14 Mar 1999 14:58:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14549 Sun, 14 Mar 1999 14:50:26 -0500 (EST) From: sbooth@us.ibm.com X-Lotus-FromDomain: IBMUS To: Ricky Charlet cc: "'Partha P. Bhattacharya'" , "'ipsec@lists.tislabs.com'" Message-ID: <85256734.006F0377.00@d54mta05.raleigh.ibm.com> Date: Sun, 14 Mar 1999 15:12:28 -0500 Subject: RE: policy expressive power in IPSec-VPN policy draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My responses are inline: Skip Booth, T/L 441-3186, ext 3-3186 VPN/RLAN Development IBM Networking Hardware Division Dept MZDA, Bldg 664/H515 RTP, NC 27709 Internal email: IBMUSM25(SBOOTH) Internet email: sbooth@us.ibm.com Notes email: Skip Booth/Raleigh/IBM Ricky Charlet on 03/11/99 01:45:25 PM To: "'Partha P. Bhattacharya'" , "'ipsec@lists.tislabs.com'" cc: (bcc: Skip Booth/Raleigh/IBM) Subject: RE: policy expressive power in IPSec-VPN policy draft >Hey thanks, > > Actually I knew that about the draft-ietf-ipsec-vpn. I have >reciently posted two question sets. One was to the 'policy group'I asking >the policy group if they are prepared to deal with the 'negotiating >proposals'. The other was to the IPSec group asking some specific questions >about this draft. I am not sure which you are responding to. My questions >(as posted about this draft) so far remain unaswered by anyone. Here they >are again. > >I have a few questions about the Draft "An LDAP Schema for >Configuration and Administration of IPSec based Virtual Private Networks >(VPNs)" draft-ipsec-vpn-policy-schema-oo.txt >Even if you have only a subset of answers, I'd be interested. > >1. Has anyone built a MIB translation of LDAP formatted >draft-ietf-ipsec-vpn-policy-schema-00.txt? We have built a Enterprise MIB Based on an earlier version of this draft primary to interrogate the PDP on the status of the policies read from the directory server. >2. The IPSecProposal object includes one AHTransformRef, one >ESPTransformRef, and one IPCOMPTransformRef. Is the intention here to limit >SA bundles to the possible combination of one each from the above three >possibilities? No, each of those references is a multi-valued attribute. For instance, a proposal with AH and ESP transforms might look as follows: AHTransformRef: 1: cn=strongAH, o=ibm, c=us ESPTransformRef: 1: cn=veryStrongESPnoAuth, o=ibm,c=us ESPTransformRef: 2: cn=StrongESPnoAuth, o=ibm,c=us The :dn syntax allows the values of the attributes to state the priority of the transform in the proposal. >3. Could there be a way for the PolicyAction object to be able to reference >vendor specific actions not defined in this draft? What would be the minimum >requisites. You can always subclass the PolicyAction class and define whatever is necessary. I would hope that we could minimize subclassing into new classes just to avoid interropability problems. I would prefer that if there is information that is important to all implementations that it would make it into the original class. >4. In the IPSecSecurityAction, aren't the *proxied* objects redundant with >the IPPolicyCondition which brought this action into play? I think so as well. We have done an implementation based on this schema and we did not implement the proxy attributes and instead extracted the information in the IPPolicyCondition to use as our proxy. Hopefully we can reach some agreement on whether there is value in defining separate attributes that define the same set of information. >5. What do you think of changing the *autoStartFlag objects to >*autoStartCondition objects which would have references like: > always > never > duringTimeRange X..Y > if interface X is down > if interface X is heavily loaded It seems that like the always and never are already covered in the current definition. The validity period is also already a defined condition. So I would recommend that you would have two IPSECSecurityActions and policies with the conditions stated above. i.e. Policy 1: if (condition == interface X is down) || (condition == interface X is heavily loaded) then do: IPsecSecurityAction (autostart == off) Policy 2: if (duringTimeRange X..Y) then do: IPSecSecurityAction (autostart == on) >6. Inside of one IPSecProposal are we limited to one DH group for all >transforms (ESP, AH)? Yes the current schema limits you to that. However, I actually think that the DH Group should be in the IPSecSecurityAction since that my understanding is that all the transform within a proposal suite must have the same value for PFS and correspondingly to the DHGroup. >7. What are the reasons for making ISAKMPAction a PolicyAction? Arn't the >'PolicyCondition's for selection ISAKMPAction trivial and possibly even >unalterable by local policy ? I see that ISAKMPAction is >reference from IPSecSecurityAction, this seems appropriate and sufficient to >me. I agree. It really depends on the semantics of the policy and whether the Phase 1 policies (condition ISAKMP Packets + ISAKMP Action) is stored in the directory or whether the PDP will generate these rules after downloading the security policy. As the current schema is written the "filter rules" could actually be stored in the directory. I am hoping that we can start some discussion on this issue. >8. Does anyone have some opinions about how external >authentication/authorization engines might be married into this draft? None at this point >9. Suppose two packets pass through a security gateway, receiving IPSec >treatment. On the first packet, how does this schema allow multiple ISAKMP >and IPSec proposals to be offered in the two negotiation phases? On the >second packet, how does this schema identify those particular proposals >(ISAKMP and IPSec, one each) that won the negotiation when the first packet >passed? I don't believe this is a schema issue. The schema tells the PDP (security gateway) what proposal suite to negotiate. The first packets will kick off the phase 1 negotiations and then once they complete the phase 2 negotions. Once the negotiation completes, the SG has established a specific instance of the policy to use for the rest of the packets. >Ricky Charlet >rcharlet@redcree.com -----Original Message----- From: Partha P. Bhattacharya [mailto:pbhattac@cisco.com] Sent: Wednesday, March 10, 1999 10:43 PM To: policy@raleigh.ibm.com Cc: rcharlet@redcreek.com Subject: policy expressive power in IPSec-VPN policy draft Ricky: In short, the LDAP VPN policy schema draft draft-ietf-ipsec-vpn-policy-schema-00.txt provides the full policy expressive power as required by IPSec. The basic version of an IPSec (data protection) policy as described in the draft consists of - one PolicyCondition object and - one IPSecSecurityAction object - one ISAKMPAction object The IPSecSecurityAction object consists of tunnel end point descriptions and a list of IPSecProposal objects (semantics between multiple proposals is logical OR). The preference can be ndicated by doing "n:DN". Each proposal is an IPSec transform set; it consist of - a list of AH transforms, - optionally a list of ESP transforms and - optionally a list of IPCOMP transforms. AH, ESP and IPCOMP transform objects are represented as IPSecTransform objects (it includes a type that indicates what protocol it corresponds to). If multiple AH (resp. ESP, IPCOMP) transforms are present in the same IPSec proposal then the semantics is logical OR. The preference can be indicated by doing "n:DN". The semantics of any combination of AH, ESP and IPCOMP protocols in an IPSec proposal is logical AND. Consider the following multi-proposal example, suppose your policy is - if HTTP to dest 1.1.1.* then - do ipsec and negotiate two proposals - either ESP= 3DES, SHA and AH = SHA or MD5 (first preference) - or EPS = DES, SHA (second preference) Policy: - PolicyConditionRef ---------> PolicyCondition object (proto= HTTP, destAddr = 1.1.1.X) - IPSecSecurityAction --------->IPSecProposal obj attr: AHTransformRef -------->IPSecTransform obj (attrib. AHProtocol = SHA) -------->IPSecTransform obj (attrib. AHProtocol = MD5) attr: ESPTransformRef------->IPSecTransform obj (attrib ESPCipher = 3DES, ESPAuth = SHA) ---------->IPSecProposal obj attr: ESPTransformRef------->IPSecTransform obj (attrib ESPCipher = DES, ESPAuth = SHA) Hope this answers your question. Partha P. Bhattacharya Internet Services Management Group Cisco Systems 255 Tasman Drive San Jose CA 95134 From owner-ipsec@lists.tislabs.com Mon Mar 15 13:01:28 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16296; Mon, 15 Mar 1999 13:01:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19588 Mon, 15 Mar 1999 12:47:28 -0500 (EST) Comments: Originally sent to TIS.COM Message-ID: <36ED4C9A.3B6FB890@siara.com> Date: Mon, 15 Mar 1999 10:08:26 -0800 From: "Sunil.Vallamkonda" X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tislabs.com Subject: IKE - ISAKMP/Oakley software. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, As I read IPSec/IKE RFCs, I have a question: Is there any site that I can download ISAKMP/Oakley software - freeware or any software vendor ? Any links/pointers is helpful. Thx. Sunil. From owner-ipsec@lists.tislabs.com Mon Mar 15 16:02:45 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA17923; Mon, 15 Mar 1999 16:02:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20513 Mon, 15 Mar 1999 15:58:32 -0500 (EST) Message-Id: <199903152041.OAA00428@pzero.sandelman.ottawa.on.ca> To: ipsec@tislabs.com Subject: The world according to MCR Date: Mon, 15 Mar 1999 14:41:38 -0600 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Monday March 15, 1999 1300-1500 Salon EF 1. Agenda Bashing Tso's and Moskowitz 2. Document Administrivia Tso's and Moskowitz One more transform: RIPEM-MD for authentication. In last call. RFC1825-1827 were obsoleted by new drafts. RFC1828/1829 (AH/ESP transform) were not obsoleted as well as RFC1851 (3DES) will be moved to historic: 1. sequential counter for the IV 2. stated objected to make old trnasforms to go away. 3. ... what was the third reason?? Go to draft standard from proposed standard. To get to there we need to have a MIB. This is the last critical item before proposed standard. Hugo: Do we want to go ahead with the DH-free authentication system for IKE? Draft is nearly expired, and has not received any comments. Question of proceedure: within IPsec vs start new group. Is there even any interest in implementing this? (Some silence from the room) What about the rekeying issue? Maybe we could have a BCP as well as a change document? 3. IPSEC MIB Tim Jenkins An architecture only for the MIB. No point in arguing about what goes into the MIB until we know what it looks like. Monitoring only of IKE and IPsec seperate branches in MIB tree: ISAKMP DOI-independant, IKE,IPsec intended to provide a base for application specific users for phaseI/II. (tunnel concepts, and other stuff will be built upon this) entity stats, six IPsec phase 2 SA tables. inbound x outbound x ESP x AH x IPCOMP DOI-independant notify table. protection suite: pulls together individual IPsec phase 2 SAs to reflect how they were negotiated using IKE. SEE TABLE (Tim, please provide!) Eleven things are required to make the protection suite table unique. This is far too cumbersome to use as an index. Typically have a 1-1 mapping between ISAKMP SA/IKE SA, but that is not the general case. If the IKE SA expire before the protection suite? Should never happen. What about if I do an identity PFS? That would be an exception. RA: envision a world where I use ISAKMP/IKE SAs but not IPsec. People who are not implementing IPsec, but are using ISAKMP. Tim: You mean Protection Suite Table should be seperate from IKE? RA: IKE and IPsec should be seperate. RA: not objecting to Protection Suite Table, but I want them quite decoupled. Tim: we need to the split as high as possible, and I've not yet decided how high it needs to be. It sounds like you want them done at the highest level. Q: is basic arch. correct? Q: where should branches split? Different documents? different tables in same MIB? Q: provide multiple tables to make it easier to hide more sensitive information? Q: IPv4 and IPv6 addressing. Currently propose duplicating addresses where needed. Q: indexing of protocol suite table Straw poll: RA: fundamental problem is that I want to use ISAKMP for things other than IPsec. 4. Deprecating 1DES J. Gilmore... presented by Hugh Daniels. DeepCrack. How many want to use DES? Noone. A problem is that we take 5 years to trust an algorithm, yet we need to distrust something within 5 minutes. What if in 5 years, something takes Blowfish (e.g.) out, we need to know how to switch things. A second problem is that DES is used for more than just bulk encryption. It is also used for IKE. speaker: I'd like to use DES in some situations where it has commercial value. Proceedure issue: it is a must implement for 1DES. Proposal is that "MUST implement" gets changed from 1DES to X. 1DES because MAY implement. Hugh: It is a MUST NOT. Roy: I understand that DES is crackable, but we use it in the real world. Dan: DES is crappy. But that isn't the issue. Our new default algorithm should be FOO. I'd like some alternatives. SMB: Two alternatives are 3DES and DESX. SMB: Not suggesting that it be changed to MUST NOT. The question is what is your threat model. It is good against joy hackers. Matt Blaze: One problem with existing IPsec is that there are too many algorithms to chose from. At low layer, one has to provide services of some kind in a black box way. If you have weak pieces it invites protocol interactions where you get faults. Have 3DES be MUST, Charlie Koffman: Impassioned plea at Danvers for mandating DES. Logic was political. At the time DES export was illegal, and we could push them over the edge and make DES export legal. Now, we need to mandate 3DES for the same reason. JI: Moore's law. Computers are twice as fast as a year ago. 3DES is half the speed, so we aren't any worse. And who is killing your friends with DES? Hugh: My software is being used by human rights groups... and yes lives are at stack. Mike: we should have backwards compatibility. Distinction between MUST implement and MUST use as default. RA: fundamentally, if we split the default from MUST be implemented. retain 1DES as must implement. Straw poll: 3DES MUST IMPLEMENT. Many yeahs, some objections DESX MANDATORY: not many. Remove DES from MANDANTORY: some Keep DES in the MANDANTORY: more 5. IKE SA's w/non-fixed IP address Yael Dayan Aggressive mode with preshared key. A user with a non-constant IP address, then we must use Aggressive mode. The problem is that the responding (the gateway) must do DH operations before it really knows if the user is legit. Proposal for a New Phase I Exchange. [MCR's comment: Vendor ID payloads can be used in Aggressive mode to enable a new feature]a 6. IPSEC Interactions with ECN Sally Floyd Explicit Congestion Notification.... rfc2481. Redefines two bits in the IP header. ECN Capable transport bit. Set by the end node. Congestion Experienced bit. Set by the router instead of dropping the packet. If set, causes the receiver to act as if the packet was dropped. Inner header gets copied to outer header. Congestion Experienced gets set, then it gets decapsulating, throughing out the Congestion Experienced bit. Two options: - limited functionality option. Outer header shouldn't have the ECN Capable set. Don't copy the ECN bit. No added security vulnerabilities. - full functionality option: Outer header in IPsec tunnel can be marked as ECN capable. If congestion is encountered, packet can be marked instead of dropped. That bit gets copied to the inner header on decapsulation. Security implication. Dropping of a packet is not reverseable. But, the Congestion Experienced bit can be reset. So the indication of Congestion is inaccurate, causing impacts on any other competing flows. Proposal: 1. Add new field to SAD. 2. Change IPsec tunnel header processing for the ECN field. 3. add the optional ability for IPsec tunnels to negotiate the use of ECN. Kent: it is premature to make a change at this stage to accomodate an experimental protocol. Charlie: why not have a second experimental draft on IPsec. Sally: ECN is incrementally deployable. Bob: the reason why ECN is experimental is because it is using a very valuable quantity: those two bits in the TOS field. It experimental because we just don't know if the gain will be worth the two bits. speaker: we could seperate the three proposals. JI: what happens if to the world if you just leave things as they are? Are we worse off than if you didn't have ECN? Sally: it causes congestion control to be turned off in the end-node, which causes congestion collapse, which is pretty serious. JI: I'm not convinced that there will be sufficient interaction between IPsec and ECN in the next two years to get any real data? Ted: if we mandate clearing the bit and the ECN fails, then we have a problem when the IESG reassigns the bit. Kent: If we do anything, then we should do all three points. 7. Other Open Work Items Tso's and Moskowitz Error codes. Ted: error codes should be vaguely consistent to allow communication. Certain fields in the IKE were not protected. Ted: no clear problem, but might be worisome. MCR: what do the version numbers mean? Ted: major/minor numbers? When do we change them? major for incompat change, minor for compatible change. Bob: Tim Jenkins' rekeying BCP. PKIX/PKI requirements stuff: Rodney and WG chairs will determine what forum will do the work. Murash?: what about ICMP errors? SMB: ... MCR speaks, and all record is lost in the confusion. Ted: i hear call for volunteers. IPsec workshop Fess Parker's DoubleTree Resort Santa Barbara, CA Asked for Ericsson VPN Interoperability Workship rate May 23-28, 1999. VPN Consortium (www.vpnc.org) - Has a page of all known active drafts. - which are still serious? Which have been abandoned by everyone but the author? Could all authors' consult with Paul Hoffman about their status. IPSRA mailing list: ietf-ipsra@vpnc.org... subscribe via ietf-ipsra-request@vpnc.org http://www.vpnc.org/ietf-ipsra/ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNu1wfx4XQavxnHg9AQEM7QH+LKnNTcnTPP8MK0Y7HTS4hqVZB0AlVemv b/NlQmkqyedTa0w60CbHKLKPZdxHn+kVIrLE7V20bZRw79kgQrJC+w== =ZY2w -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Mar 15 18:35:41 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA19453; Mon, 15 Mar 1999 18:35:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA21031 Mon, 15 Mar 1999 18:47:30 -0500 (EST) Date: Tue, 16 Mar 1999 02:08:54 +0200 (EET) Message-Id: <199903160008.CAA10793@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Michael Richardson Cc: ipsec@tislabs.com Subject: The world according to MCR In-Reply-To: <199903152041.OAA00428@pzero.sandelman.ottawa.on.ca> References: <199903152041.OAA00428@pzero.sandelman.ottawa.on.ca> 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@lists.tislabs.com Precedence: bulk Michael Richardson writes: > 5. IKE SA's w/non-fixed IP address > Yael Dayan > Aggressive mode with preshared key. I don't think this should be limited to pre shared keys. The RSA/DSA signature modes are also vulnerable to the doing KE payload generation and even signature calculation based on the first aggressive mode packets without any kind proof that there is somebody in the other end... So if we really are concerned about the spoofed IP source address and doing heavy calculation based on that we should not allow using aggressive mode. > A user with a non-constant IP address, then we must use > Aggressive mode. > > The problem is that the responding (the gateway) must do DH operations > before it really knows if the user is legit. > > Proposal for a New Phase I Exchange. > > [MCR's comment: Vendor ID payloads can be used in Aggressive > mode to enable a new feature]a No, you really cannot. This is clearly new exchange type, and needs to get new exchange type number. There is no need to add vendor id in the new exchange type. I think we need some kind of document telling how to use vendor-id, private address spaces (in different places) etc. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Mar 15 20:43:52 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA24740; Mon, 15 Mar 1999 20:43:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA21467 Mon, 15 Mar 1999 20:38:32 -0500 (EST) Message-Id: <199903160158.RAA28644@potassium.network-alchemy.com> To: Tero Kivinen cc: Michael Richardson , ipsec@tislabs.com Subject: Re: The world according to MCR In-reply-to: Your message of "Tue, 16 Mar 1999 02:08:54 +0200." <199903160008.CAA10793@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28641.921549516.1@network-alchemy.com> Date: Mon, 15 Mar 1999 17:58:37 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 16 Mar 1999 02:08:54 +0200 Tero Kivinen wrote > Michael Richardson writes: > > 5. IKE SA's w/non-fixed IP address > > Yael Dayan > > Aggressive mode with preshared key. > > I don't think this should be limited to pre shared keys. The RSA/DSA > signature modes are also vulnerable to the doing KE payload generation > and even signature calculation based on the first aggressive mode > packets without any kind proof that there is somebody in the other > end... > > So if we really are concerned about the spoofed IP source address and > doing heavy calculation based on that we should not allow using > aggressive mode. While the DOS problem is not specific to pre-shared keys I think the issue was that pre-shared keys had to be used for some reason and therefore Main Mode couldn't be used. > > Proposal for a New Phase I Exchange. > > > > [MCR's comment: Vendor ID payloads can be used in Aggressive > > mode to enable a new feature]a > > No, you really cannot. This is clearly new exchange type, and needs to > get new exchange type number. There is no need to add vendor id in the > new exchange type. I think we need some kind of document telling how > to use vendor-id, private address spaces (in different places) etc. Why not? The authenticating hash payloads and SKEYID generation could be changed to fix this "problem". The Initiator sends the vendor ID payload in the first message. If the Responder recognizes this (and assuming implicit acceptance of this capability) he'll respond with his vendor ID payload with the rest of his message, the contents of which will not be per RFC2409. The Initiator receives this and processes it accordingly. He responds with the final hash which the responder processes. If the responder doesn't like the vendor ID payload he can choose to either refuse the exchange or to just go with it, RFC2409 style. If the Initiator doesn't receive an identifiable vendor ID payload from the Responder he must assume that the exchange is per RFC2409 and process it accordingly. That should work. But I'm not really sure this is so much of a problem. The responder can postpone the 2nd half of the Diffie-Hellman exchange and limit the damage this attack can do. Also certain games can be played with a pool of Diffie- Hellman values. When an Aggressive Exchange is responded to a member of the pool is removed and used with the exchange. The pool is filled during idle times. If the pool gets critically low, or a large number of half-open Aggressive Mode exchanges (or some other detector of a DOS attack) is noticed techniques from some congestion avoidance heuristic can be used to randomly (or not so randomly) drop exchanges until the critical period passes, that is, until the pool reaches a certain mark or the number of half-open exchanges drops to a tolerable level. There are probably other defensive tactics one can also employ if one is worried about this sort of thing. Dan. From owner-ipsec@lists.tislabs.com Mon Mar 15 21:40:26 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA28084; Mon, 15 Mar 1999 21:40:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA21689 Mon, 15 Mar 1999 22:00:31 -0500 (EST) Message-Id: <199903160316.VAA07788@pzero.sandelman.ottawa.on.ca> To: ipsec@tislabs.com Subject: Re: The world according to MCR In-reply-to: Your message of "Tue, 16 Mar 1999 02:08:54 +0200." <199903160008.CAA10793@torni.ssh.fi> Date: Mon, 15 Mar 1999 21:16:29 -0600 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Tero" == Tero Kivinen writes: >> [MCR's comment: Vendor ID payloads can be used in Aggressive >> mode to enable a new feature]a Tero> No, you really cannot. This is clearly new exchange type, Tero> and needs to get new exchange type number. There is no need Tero> to add vendor id in the new exchange type. I think we need Tero> some kind of document telling how to use vendor-id, private Tero> address spaces (in different places) etc. -- kivinen@iki.fi Yes, I'm working on one. You expressed a differing opinion than mine when it comes to what it means, but we seem to have come to some agreement. ] At IETF44 in Minneapolis, MN | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Mar 16 09:51:10 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA23766; Tue, 16 Mar 1999 09:51:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23484 Tue, 16 Mar 1999 09:07:33 -0500 (EST) Message-Id: <199903161408.JAA11926@relay.gw.tislabs.com> X-Sender: balenson@pop.hq.tis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 16 Mar 1999 08:49:29 -0500 To: ipsec@tislabs.com From: "David M. Balenson" Subject: CFP: ISOC Year 2000 Network & Distr. System Security (NDSS 2000) Cc: balenson@tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk C A L L F O R P A P E R S The Internet Society Year 2000 Network and Distributed System Security Symposium (NDSS 2000) Catamaran Resort Hotel, San Diego, California February 2-4, 2000 IMPORTANT DATES: Paper and panel submissions due: June 16, 1999 Author notification: August 17, 1999 Final versions of papers and panels due: October 15, 1999 GOAL: This symposium aims to foster information exchange among researchers and practitioners of network and distributed system security services. The intended audience includes those who are interested in practical aspects of network and distributed system security, with the focus on actual system design and implementation, rather than theory. A major goal of the symposium is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings of the symposium will be published by the Internet Society. Submissions are solicited for, but are not limited to, the following topics: * Secure Electronic Commerce, e.g., payment, barter, EDI, notarization/timestamping, endorsement and licensing. * Intellectual Property Protection: protocols, schemas, implementations, metering, watermarking, other forms of rights management. * Implementation, deployment and management of network security policies. * Integrating Security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and, of course, the Web. * Attack-resistant protocols and services. * Special problems and case studies: e.g. interplay and tradeoffs between security and efficiency, usability, reliability and cost. * Security for collaborative applications and services: tele- and video-conferencing, groupwork, etc. * Fundamental services: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification, revocation, audit trails and accountability. * Integrating security services with system and application security facilities and protocols, e.g., message handling, file transport/access, directories, time synchronization, data base management, boot services, mobile computing. * Security for emerging technologies -- sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems. * Intrusion Avoidance, Detection, and Response: systems, experiences and architectures * Network Perimeter Controls: firewalls, packet filters, application gateways. BEST PAPER AWARD: A best paper award will be introduced at NDSS 2000. This award will be presented at the symposium to the authors of the best paper to be selected by the program committee. GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CO-CHAIRS: Gene Tsudik, USC / Information Sciences Institute Avi Rubin, AT&T Labs - Research TUTORIAL CHAIR: Doug Maughan, NSA / DARPA PROGRAM COMMITTEE: Bill Cheswick, Lucent Bell Labs Marc Dacier, IBM Research Zurich Jim Ellis, CMU / CERT Carl Ellison, Intel Ed Felten, Princeton Virgil Gligor, UMD College Park Thomas Hardjono, Bay Networks/Nortel Cynthia Irvine, Naval Postgraduate School Charlie Kaufman, Iris Associates Dave Kormann, AT&T Labs - Research Hugo Krawczyk, Technion and IBM Carl Landwehr, Naval Research Lab Doug Maughan, NSA / DARPA Gary McGraw, Reliable Software Technologies Sandra Murphy, TIS Labs at Network Associates Clifford Neuman, USC / Information Sciences Institute Paul Van Oorschot, Entrust Sami Saydjari, DARPA ISO David Wagner, UC Berkeley Bennet Yee, UC San Diego LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: John Kochmar, SEI PUBLICITY CHAIR: David Balenson, TIS Labs at Network Associates LOGISTICS CHAIR: Carla Rosenfeld, Internet Society REGISTRATIONS CHAIR Beth Strait, Internet Society SUBMISSIONS: The committee invites both technical papers and panel proposals. Technical papers should be at most 20 pages long. Panel proposals should be at most two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may -- at the discretion of the panel chair -- include written position statements from the panelists. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, e-mail addresses, and must specify the contact author in case of multi-author submissions. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by June 16, 1999, and must be made via electronic mail in either PostScript or ASCII format. If the committee is unable to print a PostScript submission, a hardcopy will be requested. Therefore, PostScript submissions must arrive well before the deadline. All submissions and program related correspondence (only) should be directed to the program chair: Gene Tsudik USC Information Sciences Institute 4676 Admiralty Way Marina Del Rey, CA 90292 Email: ndss00@isi.edu TEL: +1 (310) 822-1511 ext 329 FAX: +1 (310) 823-6714 Dates, final call for papers, advance program, and registration information will be available soon at the URL: httl//www.isoc.org/ndss2000. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as indicated above. Authors and panelists will be notified of acceptance by August 17, 1999. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by October 15, 1999. From owner-ipsec@lists.tislabs.com Tue Mar 16 11:14:12 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24997; Tue, 16 Mar 1999 11:14:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24358 Tue, 16 Mar 1999 11:20:33 -0500 (EST) Message-Id: <199903161636.KAA00539@pzero.sandelman.ottawa.on.ca> To: Hugo Krawczyk CC: ipsec@tislabs.com Subject: Re: The world according to MCR In-reply-to: Your message of "Tue, 16 Mar 1999 12:01:21 +0200." Date: Tue, 16 Mar 1999 10:36:08 -0600 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Hugo: Do we want to go ahead with the DH-free authentication system for > IKE? Draft is nearly expired, and has not received any comments. Question of > proceedure: within IPsec vs start new group. Is there even any > interest in implementing this? (Some silence from the room) >>>>> "Hugo" == Hugo Krawczyk writes: Hugo> what does the above "Hugo:" mean? Is this a question to me, Hugo> or is it something I raised during the meeting. The latter Sorry mistaken identity based upon context. Would the person who said that, please identity themselves? ] At IETF44 in Minneapolis, MN | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Mar 16 11:17:12 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25026; Tue, 16 Mar 1999 11:17:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24293 Tue, 16 Mar 1999 11:06:35 -0500 (EST) Message-Id: <199903161622.KAA00495@pzero.sandelman.ottawa.on.ca> To: ipsec@tislabs.com Subject: Re: The world according to MCR In-reply-to: Your message of "Mon, 15 Mar 1999 17:58:37 PST." <199903160158.RAA28644@potassium.network-alchemy.com> Date: Tue, 16 Mar 1999 10:22:52 -0600 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dan" == Dan Harkins writes: Dan> Why not? The authenticating hash payloads and SKEYID Dan> generation could be changed to fix this "problem". The Dan> Initiator sends the vendor ID payload in the first Dan> message. If the Responder recognizes this (and assuming Dan> implicit acceptance of this capability) he'll respond with Dan> his vendor ID payload with the rest of his message, the First, sending of a vendor ID payload is not dependant upon receiving anything, and does not imply acceptance of the other's vendor ID payload. Second, the intention was that the vendor ID payload had to be *received* before one could *send* using the private number space. Kivinen had a different idea, and I'd like to get three or four brains together and has out some better text. ] At IETF44 in Minneapolis, MN | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Mar 16 12:05:24 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25424; Tue, 16 Mar 1999 12:05:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24480 Tue, 16 Mar 1999 11:52:54 -0500 (EST) Message-Id: <4.1.19990316110808.00bd43e0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 16 Mar 1999 11:08:52 -0600 To: "Sunil.Vallamkonda" , ipsec@tislabs.com From: Robert Moskowitz Subject: Re: IKE - ISAKMP/Oakley software. In-Reply-To: <36ED4C9A.3B6FB890@siara.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:08 AM 3/15/99 -0800, Sunil.Vallamkonda wrote: > > >As I read IPSec/IKE RFCs, I have a question: > >Is there any site that I can download ISAKMP/Oakley software - >freeware or any software vendor ? >Any links/pointers is helpful. > www.xs4all.nl/~freeswan Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Tue Mar 16 12:15:59 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25552; Tue, 16 Mar 1999 12:15:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24684 Tue, 16 Mar 1999 12:33:00 -0500 (EST) Date: Tue, 16 Mar 1999 12:49:05 -0500 From: canetti Message-Id: <9903161749.AA28452@ornavella.watson.ibm.com> To: hugo@ee.technion.ac.il, mcr@sandelman.ottawa.on.ca Subject: Re: The world according to MCR Cc: ipsec@tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It was my utmost honor to serve as the incarnation of The Hugo at Minneapolis... :) Ran (This does not mean that my comment at the IPSEC meeting was in Hugo's name; it was my own. Still, I trust that Hugo will join me in asking the list whether people are interested in pursuing the DH-less mode of IKE. So if you are interested, please speak up.) > From: Michael Richardson > > > > > > Hugo: Do we want to go ahead with the DH-free authentication system for > > IKE? Draft is nearly expired, and has not received any comments. Question of > > proceedure: within IPsec vs start new group. Is there even any > > interest in implementing this? (Some silence from the room) > > >>>>> "Hugo" == Hugo Krawczyk writes: > Hugo> what does the above "Hugo:" mean? Is this a question to me, > Hugo> or is it something I raised during the meeting. The latter > > Sorry mistaken identity based upon context. > > Would the person who said that, please identity themselves? > > ] At IETF44 in Minneapolis, MN | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ > > From owner-ipsec@lists.tislabs.com Tue Mar 16 13:45:23 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26641; Tue, 16 Mar 1999 13:45:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26459 Tue, 16 Mar 1999 14:03:01 -0500 (EST) Message-Id: <199903161924.LAA00262@potassium.network-alchemy.com> To: Michael Richardson cc: ipsec@tislabs.com Subject: Re: The world according to MCR In-reply-to: Your message of "Tue, 16 Mar 1999 10:22:52 CST." <199903161622.KAA00495@pzero.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <259.921612263.1@network-alchemy.com> Date: Tue, 16 Mar 1999 11:24:23 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 16 Mar 1999 10:22:52 CST Michael Richardson wrote > > >>>>> "Dan" == Dan Harkins writes: > Dan> Why not? The authenticating hash payloads and SKEYID > Dan> generation could be changed to fix this "problem". The > Dan> Initiator sends the vendor ID payload in the first > Dan> message. If the Responder recognizes this (and assuming > Dan> implicit acceptance of this capability) he'll respond with > Dan> his vendor ID payload with the rest of his message, the > > First, sending of a vendor ID payload is not dependant upon > receiving anything, and does not imply acceptance of the other's > vendor ID payload. I never said that sending the vendor ID was dependant on receiving anything, nor did I say that the mere sending of it implied acceptance on the part of the recipient. The responder could choose not to send his vendor ID payload regardless of what the initiator did and regardless of whether he recognized the initiator's vendor ID. Also, the implication in this ad hoc scheme was that the vendor ID payload was an offer to do something different and non-RFC2409. Sending it would not mean acceptance to do this, but both sending it and receiving it would. This pseudo-negotiation use of the vendor ID payload may not be in keeping with the spirit or the intention of it but that's an emotional argument I'd rather not have. It is not prohibited by RFC2408 and it would work. The responder could be configured to only do aggressive mode with a client that it recognized and only do it in this manner to limit exposure to DOS attacks. This scheme may not be as secure as straight aggressive mode but it's a perfectly legal use of the vendor ID payload. > Second, the intention was that the vendor ID payload had to be > *received* before one could *send* using the private number space. There was no private numberspace involved in the scheme I described so I don't know what this refers to. Dan. From owner-ipsec@lists.tislabs.com Wed Mar 17 04:34:25 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA25034; Wed, 17 Mar 1999 04:34:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA29461 Wed, 17 Mar 1999 04:33:29 -0500 (EST) Message-ID: <29752A74B6C5D211A4920090273CA3DC031F77@new-exc1.ctron.com> From: "Waters, Stephen" To: ipsec@lists.tislabs.com Subject: LDAP Schema, CAs and RADIUS Date: Wed, 17 Mar 1999 09:56:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk O.K., I need 'back-office' Authentication, Authorization and Accounting services for my Security Gateway. I can do this today, with a few bits of sticky-tape, with RADIUS, but what is the future? I can get Authorization by implementing LDAP and sucking down IPSEC VPN policies. I can get Authentication using Certificates and implementing a bunch of protocols to check CRLs. What do I do for Accounting? Some folk use RADIUS to do address-download to remote clients, e.g. Intranet IP address pool management and name server address down-load (IKECFG stuff). A nice feature to centralize address pool management. I guess name-server addresses could just about be added to the IPSEC VPN schema (reasonably static - you hope), but I still need an answer for Accounting and Address Pool Management. Do we make the RADIUS server the meeting point for Legacy AAA, LDAP Policy, and CRLs? Regards, Steve. From owner-ipsec@lists.tislabs.com Wed Mar 17 10:50:17 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29091; Wed, 17 Mar 1999 10:50:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00677 Wed, 17 Mar 1999 10:53:07 -0500 (EST) From: Pat.Calhoun@Eng.Sun.Com (Patrice Calhoun) Message-Id: <199903171615.IAA08756@hsmpka.eng.sun.com> Date: Wed, 17 Mar 1999 10:17:27 -0800 To: "Waters, Stephen" , Reply-To: Subject: Re: LDAP Schema, CAs and RADIUS X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > O.K., I need 'back-office' Authentication, Authorization and >Accounting services for my Security Gateway. > > I can do this today, with a few bits of sticky-tape, with RADIUS, >but what is the future? > > I can get Authorization by implementing LDAP and sucking down IPSEC >VPN policies. > I can get Authentication using Certificates and implementing a bunch >of protocols to check CRLs. > > What do I do for Accounting? > > Some folk use RADIUS to do address-download to remote clients, e.g. >Intranet IP address pool management and > name server address down-load (IKECFG stuff). A nice feature to >centralize address pool management. I agree that this is a generally useful freature, but having a RADIUS server manage address pools is a hack to the RADIUS protocol. There have been proposals to extend the RADIUS protocol, and these were all turned down by the WG chair since RADIUS is *not* a resource management protocol. Therefore, if you want to do this, you certainly can, but not in any standard (or reliable) fashion. > > I guess name-server addresses could just about be added to the IPSEC >VPN schema (reasonably static - you hope), > but I still need an answer for Accounting and Address Pool >Management. > > Do we make the RADIUS server the meeting point for Legacy AAA, LDAP >Policy, and CRLs? > So I would strongly recommend that you add any of your IPSEC/AAA requirements in the AAA WG. PatC From owner-ipsec@lists.tislabs.com Thu Mar 18 14:08:54 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA11007; Thu, 18 Mar 1999 14:08:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06472 Thu, 18 Mar 1999 14:36:27 -0500 (EST) Date: Wed, 17 Mar 1999 14:44:32 -0600 From: Paul Krumviede Subject: Re: LDAP Schema, CAs and RADIUS To: "Waters, Stephen" Cc: ipsec@lists.tislabs.com Message-id: <36F01430.2F495F5D@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <29752A74B6C5D211A4920090273CA3DC031F77@new-exc1.ctron.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Waters, Stephen" wrote: > > O.K., I need 'back-office' Authentication, Authorization and > Accounting services for my Security Gateway. As Pat said, the AAA WG would probably be interested in hearing about requirements so that one can avoid using duct tape to build this kind of thing. -paul From owner-ipsec@lists.tislabs.com Thu Mar 18 14:10:54 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA11045; Thu, 18 Mar 1999 14:10:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06491 Thu, 18 Mar 1999 14:37:28 -0500 (EST) Message-ID: <36F118F3.A82F6634@oskar.nanoteq.co.za> Date: Thu, 18 Mar 1999 17:17:07 +0200 From: Chris Bohme X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: "'ipsec@lists.tislabs.com'" Subject: Re: policy expressive power in IPSec-VPN policy draft References: <85256734.006F0377.00@d54mta05.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Can anyone (esp. the authors) give an indication of the future of the draft "An LDAP Schema for Configuration and Administration of IPSec based VPNs" ? Because the draft expires in a few weeks, I'd like to know whether there are any updates / new versions planned. Basically I share the concerns raised by authors of previous postings in this thread. The 'proxied objects' seem redundant, as do explicit policy conditions/actions for ISAKMPPhase1 and ISAKMPPhase2. Those extra rules make this schema bulky and I wonder why they have been included. Is there anyone (authors maybe) who can shed some more light on the subject ? Thanks, Chris From owner-ipsec@lists.tislabs.com Thu Mar 18 14:11:16 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA11061; Thu, 18 Mar 1999 14:11:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06490 Thu, 18 Mar 1999 14:37:28 -0500 (EST) Message-Id: <199903180455.WAA00739@pzero.sandelman.ottawa.on.ca> To: ipsec@tislabs.com CC: ietf-ipsra@vpnc.org Subject: Configuration of mobile users Date: Wed, 17 Mar 1999 20:52:29 -0800 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I've just re-read draft-ietf-ipsec-dhcp-01.txt and draft-ietf-ipsec-isakmp-mode-cfg-04.txt. To compare/contrast, I think the major advantage of isakmp-mode-cfg is that one doesn't burn entropy from the DH making an IPsec SA that is only used for three or four packets. Secondly, it isn't clear that all "VPN" SAs will necessarily have selectors that permit the DHCP traffic. The major advantage of ipsec-dhcp is that it reuses existing protocol definitions, infra-structure, and DHCP has a clear mechanism for extensions. I would like to suggest a compromise/hybrid solution: let's define a payload/exchange type which carries DHCP payloads within ISAKMP. This has all the advantages of isakmp-mode-cfg: 1. no seperate SA 2. the ISAKMP learns about the parameters directly The speaker on Monday from Microsoft (Bernard I think) expressed the belief that many of the PPP configuration options should have been done via a DHCP Inform. I'm not qualified to agree or disagree with this statement, but if true, would tend to support using DHCP. In addition, DHCP leases need to be renewed periodically. This provides a *NATURAL* keep alive message for road warriors. Further, DHCP says specific things about what a host is supposed to do as it shuts down wrt sending out DHCP releases. ] Why doesn't my notebook fit on the food tray on this flight? | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNvCGiB4XQavxnHg9AQGjvAH8C/6rjsvSkQH0OTg+mxdaZVF4VgH5K9ET uOlHer65T3X4tHcr29wm5fMgwCzrYGB89zlXT1Ni79PV9AvVvCJnGA== =nWG8 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Mar 18 14:14:36 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA11175; Thu, 18 Mar 1999 14:14:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06466 Thu, 18 Mar 1999 14:35:26 -0500 (EST) Date: Wed, 17 Mar 1999 13:52:49 -0600 From: Paul Krumviede Subject: Re: The world according to MCR To: canetti Cc: hugo@ee.technion.ac.il, mcr@sandelman.ottawa.on.ca, ipsec@tislabs.com Message-id: <36F00811.A3CBAE04@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <9903161749.AA28452@ornavella.watson.ibm.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk canetti wrote: > (This does not mean that my comment at the IPSEC meeting was in Hugo's name; > it was my own. Still, I trust that Hugo will join me in asking the list > whether people are interested in pursuing the DH-less mode of IKE. > So if you are interested, please speak up.) At least somewhat interested... -paul From owner-ipsec@lists.tislabs.com Thu Mar 18 19:27:03 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA19421; Thu, 18 Mar 1999 19:27:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA07712 Thu, 18 Mar 1999 19:48:35 -0500 (EST) Message-ID: <004701be71a5$5994f770$324445ab@pbhattac-nt.cisco.com> From: "Partha P. Bhattacharya" To: "Chris Bohme" Cc: Subject: Re: policy expressive power in IPSec-VPN policy draft Date: Thu, 18 Mar 1999 17:10:59 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01BE7162.4B3AC8F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0044_01BE7162.4B3AC8F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We will update this draft soon. We will align the schema to the base = policy schema that is=20 being defined by the POLICY wg.=20 One reason for have having explicit proxied info in the action is that = the job of the policy search=20 module is simple. It just returns the action module which contains all = the info. Imagine multiple rules where the conditions are different but the actions are the same. = The search engine will=20 hit one rule but then it will have to collect all the selectors from all = the rules that point to=20 the same action in order to form the IDci, IDcr. Currently in IPsec only = one range/subnet=20 can be negotiated but in the future this may change and multiple ID = lists may be allowed. These attributes are optional; so we attach defaults to imply the selectors of = the matched rule. We allowed phase 1 rules and also explicit pointers from IPSecAction. = While redundant, explicit phase 1 rules when you have few rules; since in that case you don't need = to specify the ISAKMPAction in every IPSec rule. The intended processing is=20 =20 - found an IPSec rule - if there is an attached ISAKMPAction take that one - else attemp to match the isakmp rules=20 Partha Bhattacharya -----Original Message----- From: Chris Bohme Cc: 'ipsec@lists.tislabs.com' Date: Thursday, March 18, 1999 2:13 PM Subject: Re: policy expressive power in IPSec-VPN policy draft >Hi, > >Can anyone (esp. the authors) give an indication of the future of the = draft "An >LDAP Schema for Configuration and Administration of IPSec based VPNs" ? = Because >the draft expires in a few weeks, I'd like to know whether there are = any >updates / new versions planned. > >Basically I share the concerns raised by authors of previous postings = in this >thread. The 'proxied objects' seem redundant, as do explicit policy >conditions/actions for ISAKMPPhase1 and ISAKMPPhase2. Those extra rules = make >this schema bulky and I wonder why they have been included. Is there = anyone >(authors maybe) who can shed some more light on the subject ? > >Thanks, > >Chris > > > ------=_NextPart_000_0044_01BE7162.4B3AC8F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We will update this draft soon. We = will align=20 the schema to the base policy schema that is
being defined by the POLICY wg. =
 
One reason for have having explicit proxied info in = the action=20 is that the job of the policy search 
module is simple. It just returns the action module = which=20 contains all the info. Imagine multiple
rules where the conditions are different but the = actions are=20 the same. The search engine will 
hit one rule but then it will have to collect all = the=20 selectors from all the rules that point to 
the same action in order to form the IDci, IDcr. = Currently in=20 IPsec only one range/subnet
can be negotiated but in the = future this=20 may change and multiple ID lists may be allowed. These
attributes are optional; so we attach defaults to = imply the=20 selectors of the matched rule.
 
We allowed phase 1 rules and also = explicit=20 pointers from IPSecAction. While redundant, explicit
phase 1 rules = when you have=20 few rules; since in that case you don't need to specify the = ISAKMPAction
in=20 every IPSec rule. The intended processing is 
 
 - found an IPSec rule
 - if there is an attached ISAKMPAction take = that=20 one
 - else attemp to match the isakmp=20 rules 
 
Partha Bhattacharya
 
-----Original Message-----
From: = Chris Bohme=20 <chris@oskar.nanoteq.co.za&g= t;
Cc:=20 'ipsec@lists.tislabs.com' = <ipsec@lists.tislabs.com>Date:=20 Thursday, March 18, 1999 2:13 PM
Subject: Re: policy expressive power = in=20 IPSec-VPN policy draft

>Hi,
>
>Can = anyone=20 (esp. the authors) give an indication of the future of the draft=20 "An
>LDAP Schema for Configuration and Administration of = IPSec based=20 VPNs" ? Because
>the draft expires in a few weeks, I'd like = to know=20 whether there are any
>updates / new versions=20 planned.
>
>Basically I share the concerns raised by authors = of=20 previous postings in this
>thread. The 'proxied objects' seem = redundant,=20 as do explicit policy
>conditions/actions for ISAKMPPhase1 and=20 ISAKMPPhase2. Those extra rules make
>this schema bulky and I = wonder why=20 they have been included. Is there anyone
>(authors maybe) who can = shed=20 some more light on the subject=20 ?
>
>Thanks,
>
>Chris
>
>
> ------=_NextPart_000_0044_01BE7162.4B3AC8F0-- From owner-ipsec@lists.tislabs.com Fri Mar 19 10:43:55 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA21072; Fri, 19 Mar 1999 10:43:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10630 Fri, 19 Mar 1999 10:31:30 -0500 (EST) Message-Id: <3.0.32.19990319104545.00a50c00@bl-mail1.corpeast.baynetworks.com> X-Sender: smamros@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 19 Mar 1999 10:45:46 -0500 To: Michael Richardson From: Shawn Mamros Subject: Re: Configuration of mobile users Cc: ipsec@tislabs.com, ietf-ipsra@vpnc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk First, a question: Am I correct in assuming that ietf-ipsra@vpnc.org is the mailing list for the IP Security Remote Access BOF? If so, how does one subscribe, and is there an archive? Sorry if this info was posted sooner here, but I missed it (and I wasn't able to make the meeting in Minneapolis). > I would like to suggest a compromise/hybrid solution: let's define a >payload/exchange type which carries DHCP payloads within ISAKMP. > > This has all the advantages of isakmp-mode-cfg: > 1. no seperate SA > 2. the ISAKMP learns about the parameters directly If DHCP is to be used (and there are certainly advantages to doing so), then this hybrid makes the most sense to me. Doing a separate SA has a lot of other problems besides the overhead, not the least of which is the selectors/Quick Mode client IDs one would have to allow and use. (To get the client's initial request to the server, you'd have to allow tunnel traffic from 0.0.0.0 to 255.255.255.255; then to get the DHCP server's response back, if you were to stick to the rules, you'd need *another* SA pair from the DHCP server's address to the client's newly assigned one. Not a pretty picture...) Keep in mind, though, that DHCP is inherently IPv4-only; there are fixed length four octet fields in the header for IP addresses. There is a draft for a DHCP for IPv6, which I haven't looked at in a while, but the last I knew of it, the message format and even most/all of the protocol exchanges were radically different from DHCPv4. > The speaker on Monday from Microsoft (Bernard I think) expressed the >belief that many of the PPP configuration options should have been >done via a DHCP Inform. I'm not qualified to agree or disagree with >this statement, but if true, would tend to support using DHCP. At the time PPP was being done, the DHCPINFORM message didn't exist. That one's a fairly recent invention, which was added when DHCP was rev'd up to Draft Standard in RFC 2131. Even if that weren't the case, DHCP's large header size (236 octets, inherited from BOOTP) wouldn't be a good thing for a serial line environment, where every byte adds latency. > In addition, DHCP leases need to be renewed periodically. This >provides a *NATURAL* keep alive message for road warriors. Further, >DHCP says specific things about what a host is supposed to do as it >shuts down wrt sending out DHCP releases. Lease times only apply when DHCP is used for address acquisition. If one already has an address and goes the DHCPINFORM route, it really won't make an effective keepalive, at least not from the IPSec gateway server's perspective. -Shawn Mamros (who did a lot of DHCP work in a prior lifetime...) E-mail to: smamros@nortelnetworks.com ------------- End Forwarded Message ------------- From owner-ipsec@lists.tislabs.com Sat Mar 20 18:19:31 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15342; Sat, 20 Mar 1999 18:19:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA14385 Sat, 20 Mar 1999 18:49:29 -0500 (EST) Message-Id: <4.2.0.32.19990320160639.00a23240@mail.imc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta) Date: Sat, 20 Mar 1999 16:10:54 -0800 To: ipsec@tislabs.com From: Paul Hoffman Subject: Active/dead Internet Drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. At the IPsec WG this week, it was emphasized that we're trying to finish up work in the WG by focusing on the tasks in the charter. I put in a request for folks to tell me which WG Internet Drafts are active and which are dead. VPNC has a list of the drafts known to relate to IPsec at ; most of the ones there have draft-ietf-ipsec names, indicating that they are WG work items. Could any document authors let me know what to fill in for the status of their drafts? If the draft is dead, you should let Ted'n'Bob know so they can have the IETF Secretariat take it off the WG charter page. Also, if I've left any drafts off that list, by all means let me know. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Mar 22 10:38:40 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02960; Mon, 22 Mar 1999 10:38:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18529 Mon, 22 Mar 1999 10:10:23 -0500 (EST) Message-Id: <199903212221.XAA13563@waldorf.appli.se> To: "Sunil.Vallamkonda" cc: ipsec@tislabs.com Subject: Re: IKE - ISAKMP/Oakley software. In-reply-to: Your message of "Mon, 15 Mar 1999 10:08:26 PST." <36ED4C9A.3B6FB890@siara.com> Date: Sun, 21 Mar 1999 23:21:19 +0100 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Date: Mon, 15 Mar 1999 10:08:26 -0800 > From: "Sunil.Vallamkonda" > > Is there any site that I can download ISAKMP/Oakley software - > freeware or any software vendor ? > Any links/pointers is helpful. In OpenBSD there is sbin/isakmpd, the code is still in flux though, as we are changing to PF_KEYv2 right now. http://www.openbsd.org/ You can get the code in various ways, many of them described at that page. Actually the code available from there is crippled as we do not include RSA for patent reasons, but there is another distribution channel where I include RSA code, however I have not made such a release in quite a while so the latest one is really obsolelete. If you are interested in that RSA version, contact me privately. Niklas From owner-ipsec@lists.tislabs.com Mon Mar 22 12:48:58 1999 Received: from lists.tislabs.com (portal.ex.tis.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA04089; Mon, 22 Mar 1999 12:48:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19057 Mon, 22 Mar 1999 12:44:27 -0500 (EST) Comments: Originally sent to TIS.COM Message-ID: From: Ricky Charlet To: "'ipsec@tis.com'" Subject: FW: Configuration of mobile users Date: Mon, 22 Mar 1999 10:06:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE748E.B016AB2A" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE748E.B016AB2A Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE748E.B016AB2A" ------_=_NextPart_001_01BE748E.B016AB2A Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Ricky Charlet Sent: Monday, March 22, 1999 10:06 AM To: 'Michael Richardson' Subject: RE: Configuration of mobile users Howdy () > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Sent: Wednesday, March 17, 1999 8:52 PM > To: ipsec@tislabs.com > Cc: ietf-ipsra@vpnc.org > Subject: Configuration of mobile users > > > I would like to suggest a compromise/hybrid solution: let's define a > payload/exchange type which carries DHCP payloads within ISAKMP. > > This has all the advantages of isakmp-mode-cfg: > 1. no seperate SA > 2. the ISAKMP learns about the parameters directly > > To me, this hybrid seems like the worst of both worlds solution. We don't get to leave the ISAKMP/IKE state machine alone AND we don't get non-IP protocol support. Let me put up my thoughts on how these two proposals would work out. There probably are gaps and/or flaws in my thinking, and I am sure people on this list can uncover them. The ISAKMP-config / ISAKMP-Xauth solution requires a new 'phase 1.5' exchange and lets you carry just about any info you want down that protected exchange... in our case we are discussing putting boot-strapping IP configuration information AND/OR proxied external authentication systems challenge/responses into that 'phase 1.5' exchange. Note that the boot strapping IP config info could just as easily have been IPX info or AppleTalk info or .... By the time you get around to building your phase 2 SA, you have loaded bootstrapping config onto the client AND you have authenticated / authorized the client with a mechanism of you choice. The DHCP draft implies that anyone from 0.0.0.0 255.255.255.255 be allowed to build a phase 2 SA to your authentication server, it is assumed that this SA will be VERY short lived (one to four minutes?). The client is only connected to an authentication/authorization server long enough to get some credentials. Then the client builds a new phase 2 SA to what ever resource the credentials allow. Note that this solution required no new 'phase 1.5' exchange definitions, but it is only ever going to work with IP due to its reliance on DHCP. ################################### # Ricky Charlet # rcharlet@RedCreek.com # (510) 795-6903 ################################### end Howdy; ------_=_NextPart_001_01BE748E.B016AB2A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: Configuration of mobile users

-----Original Message-----
From: Ricky Charlet
Sent: Monday, March 22, 1999 10:06 AM
To: 'Michael Richardson'
Subject: RE: Configuration of mobile users


Howdy ()
       =20

> -----Original Message-----
> From: Michael Richardson [mailto:mcr@sandelman.ottawa.o= n.ca]
> Sent: Wednesday, March 17, 1999 8:52 PM
> To: ipsec@tislabs.com
> Cc: ietf-ipsra@vpnc.org
> Subject: Configuration of mobile users
>
>
>   I would like to suggest a = compromise/hybrid solution: let's define a
> payload/exchange type which carries DHCP = payloads within ISAKMP.
>
>   This has all the advantages of = isakmp-mode-cfg:
>         = 1. no seperate SA
>         = 2. the ISAKMP learns about the parameters directly
>         =
>

        To me, = this hybrid seems like the worst of both worlds solution. We don't get = to leave the ISAKMP/IKE state machine alone AND we don't get non-IP = protocol support.

        Let me put = up my thoughts on how these two proposals would work out. There = probably are gaps and/or flaws in my thinking, and I am sure people on = this list can uncover them.


        The = ISAKMP-config / ISAKMP-Xauth solution requires a new 'phase 1.5' = exchange and lets you carry just about any info you want down that = protected exchange... in our case we are discussing putting = boot-strapping IP configuration information AND/OR proxied external = authentication systems challenge/responses into that 'phase 1.5' = exchange. Note that the boot strapping IP config info could just as = easily have been IPX info or AppleTalk info or ....  By the time = you get around to building your phase 2 SA, you have loaded = bootstrapping config onto the client AND you have authenticated / = authorized the client with a mechanism of you choice.

        The DHCP = draft implies that anyone from 0.0.0.0 255.255.255.255 be allowed to = build a phase 2 SA to your authentication server, it is assumed that = this SA will be VERY short lived (one to four minutes?). The client is = only connected to an authentication/authorization server long enough to = get some credentials. Then the client builds a new phase 2 SA to what = ever resource the credentials allow. Note that this solution required = no new 'phase 1.5' exchange definitions, but it is only ever going to = work with IP due to its reliance on DHCP.



###################################
#  Ricky Charlet
#   rcharlet@RedCreek.com
#  (510) 795-6903
###################################
end Howdy; 

  ------_=_NextPart_001_01BE748E.B016AB2A-- ------_=_NextPart_000_01BE748E.B016AB2A Content-Type: application/octet-stream; name="Ricky Charlet.vcf" Content-Disposition: attachment; filename="Ricky Charlet.vcf" BEGIN:VCARD VERSION:2.1 N:Charlet;Ricky FN:Ricky Charlet ORG:RedCreek Communications Inc.;Engineering TITLE:Engineer ADR;WORK:;2nd Floor;3900 Newpark Mall Rd.;Newark;CA;94560;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:2nd Floor=0D=0A3900 Newpark Mall Rd.=0D=0ANewark, CA 94560=0D=0AUSA EMAIL;PREF;INTERNET:rcharlet@redcreek.com REV:19981013T230517Z END:VCARD ------_=_NextPart_000_01BE748E.B016AB2A-- From owner-ipsec@lists.tislabs.com Tue Mar 23 04:03:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA08951; Tue, 23 Mar 1999 04:03:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA21535 Tue, 23 Mar 1999 04:07:38 -0500 (EST) Message-ID: <36F75E18.E19657DD@oskar.nanoteq.co.za> Date: Tue, 23 Mar 1999 11:25:44 +0200 From: Chris Bohme X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Partha P. Bhattacharya" CC: ipsec@lists.tislabs.com Subject: Re: policy expressive power in IPSec-VPN policy draft References: <004701be71a5$5994f770$324445ab@pbhattac-nt.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Hi Partha, Thanks for your reply, I have a few more questions concerning the policy examples, though: In scenario 1 in section 8.1.3, a rule is specified for Quick Mode negotiations (dn: cn=S1-S2-isakmp-QuickMode-rule, o=XYZ, c=US). Is it necessary to explicitly state this rule even though it coincides with the PolicyCondition that is supposed to trigger IPSec processing ? Shouldn't the default rather be to respond to Quick Mode negotiotiations and rather use an explicit deny rule if that should not be the case ? In section 8.1.2 number 3 the following rules applying to S1 are listed: dn: cn= S1-S2-AHESP-rule, o=XYZ, c=US Objectclass: Policy PolicyType: IPSecDataLocal PolicyConditionRef: cn=S1-S2-AHESP-traffic, o=XYZ, c=US PolicyActionRef: cn=clearIPSecSecurityAction, o=XYZ, c=US dn: cn=S1-S2-AHESP-traffic, o=XYZ, c=US, Objectclass: IPPolicyCondition SourceIPAddressRange: S1 DestinationIPAddressRange: S2 IPProtocolRange: 50-51 (i.e. AH and ESP) These rules describe that IPSec packets (created by S1) destined to S2 may be forwarded by S1. Couldn't it be assumed, by default, that if a machine secures an outgoing packet that it created itself, it should be able to forward it ? Otherwise it would not have made sense to secure it in the first place. The text states that this rule is used to specify "whether S1 and S2 can communicate directly or a gateway has to be traversed", but isn't this already taken care of by specifying a different IPSecTunnelEndpoint ? And finally, what is the reason behind having a PolicyType of IPSecDataLocal and IPSecDataRemote ? Wouldn't PolicyType=IPSecData have sufficed in all the cases ? Regards, Chris "Partha P. Bhattacharya" wrote: > We will update this draft soon. We will align the schema to the base > policy schema that isbeing defined by the POLICY wg. One reason for > have having explicit proxied info in the action is that the job of the > policy searchmodule is simple. It just returns the action module which > contains all the info. Imagine multiplerules where the conditions are > different but the actions are the same. The search engine willhit one > rule but then it will have to collect all the selectors from all the > rules that point tothe same action in order to form the IDci, IDcr. > Currently in IPsec only one range/subnetcan be negotiated but in the > future this may change and multiple ID lists may be allowed. > Theseattributes are optional; so we attach defaults to imply the > selectors of the matched rule. We allowed phase 1 rules and also > explicit pointers from IPSecAction. While redundant, explicitphase 1 > rules when you have few rules; since in that case you don't need to > specify the ISAKMPAction > in every IPSec rule. The intended processing is - found an IPSec > rule - if there is an attached ISAKMPAction take that one - else > attemp to match the isakmp rules Partha Bhattacharya From owner-ipsec@lists.tislabs.com Tue Mar 23 11:01:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA12707; Tue, 23 Mar 1999 11:01:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22536 Tue, 23 Mar 1999 10:26:44 -0500 (EST) Message-ID: <004401be7544$afbfef90$65b445ab@pbhattac-nt.cisco.com> From: "Partha P. Bhattacharya" To: "Chris Bohme" Cc: Subject: Re: policy expressive power in IPSec-VPN policy draft Date: Tue, 23 Mar 1999 07:49:06 -0800 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 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Responses inline. -----Original Message----- From: Chris Bohme To: Partha P. Bhattacharya Cc: ipsec@lists.tislabs.com Date: Tuesday, March 23, 1999 1:30 AM Subject: Re: policy expressive power in IPSec-VPN policy draft >Hi Partha, > >Thanks for your reply, I have a few more questions concerning the >policy examples, though: > >In scenario 1 in section 8.1.3, a rule is specified for Quick Mode >negotiations (dn: cn=S1-S2-isakmp-QuickMode-rule, o=XYZ, c=US). Is it >necessary to explicitly state this rule even though it coincides with >the PolicyCondition that is supposed to trigger IPSec processing ? >Shouldn't the default rather be to respond to Quick Mode negotiotiations >and rather use an explicit deny rule if that should not be the case ? When the draft was written, the thinking was to create an explicit rule for every type of packet that a host sees. That way, the devices could be "dumb" and just attempt to match a rule with the packet header. The rule that triggers IPSec processing has S1 and S2 in the policy condition. But a quick mode packet for a responder has the gateway addresses in the packet headers and S1 and S2 appear inside the payload. If we don't have the extra rule you mention, we have to look for a rule with matching S1, S2. This is certainly possible. However our experience has indicated that this may not lead to fast processing. (It is "easier" to match rule sets with a point as given input than with a set as a given input; note S1, S2 can be sets) We have realized that the current method leads to an explosion of rules in the repository. So, in the next draft, we will only have one or two rules that will describe the traffic going into an IPSec tunnel and let the devices internally create the derived rules as necessary. > >In section 8.1.2 number 3 the following rules applying to S1 are listed: > > dn: cn= S1-S2-AHESP-rule, o=XYZ, c=US > Objectclass: Policy > PolicyType: IPSecDataLocal > PolicyConditionRef: cn=S1-S2-AHESP-traffic, o=XYZ, c=US > PolicyActionRef: cn=clearIPSecSecurityAction, o=XYZ,c=US > > > dn: cn=S1-S2-AHESP-traffic, o=XYZ, c=US, > Objectclass: IPPolicyCondition > SourceIPAddressRange: S1 > DestinationIPAddressRange: S2 > IPProtocolRange: 50-51 (i.e. AH and ESP) > >These rules describe that IPSec packets (created by S1) destined to S2 >may be forwarded by S1. Couldn't it be assumed, by default, that if a >machine secures an outgoing packet that it created itself, it should be >able to forward it ? Otherwise it would not have made sense to secure it >in the first place. The text states that this rule is used to specify >"whether S1 and S2 can communicate directly or a gateway has to be >traversed", but isn't this already taken care of by specifying a >different IPSecTunnelEndpoint ? In the general case, security requirements may require nested IPSec processing. Think of a remote corporate machine on the Internet that has to do end-to-end IPSec and at the same time has to traverse a gateway to enter the corporate net. In such cases, an IPSec packet may need to go through another layer of IPSec processing. In some other cases though, an IPSec packet goes in the clear. The above rule was created to let a host differentiate between the two cases. The processing rule is then to keep recursively looking for a rule until you hit the clear rule. > >And finally, what is the reason behind having a PolicyType of >IPSecDataLocal and IPSecDataRemote ? Wouldn't PolicyType=IPSecData have >sufficed in all the cases ? The PolicyType of IPSecDataLocal was for traffic going into an IPSec "tunnel"; the PolicyType of IPSecDataLocal was for traffic coming out of a tunnel. The latter rule was created to disallow "spoofed" packets that are supposed to come inside of an IPSec tunnel. Again, this is a derived rule that was supposed to ease IPSec processing on the host. For a spoofed packet that came in the clear, the policy engine would match this rule and discard the packet by noticing from the IPSecSecurityAction that the packet shd have received inbound IPSec processing. > >Regards, > >Chris > > From owner-ipsec@lists.tislabs.com Tue Mar 23 11:17:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA12838; Tue, 23 Mar 1999 11:17:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22827 Tue, 23 Mar 1999 11:35:20 -0500 (EST) Date: Tue, 23 Mar 1999 11:57:07 -0500 Message-Id: <199903231657.LAA05835@brill.shiva.com> From: John Shriver To: ipsec@lists.tislabs.com Subject: textual-conventions MIB I-D available Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] My proposal for a textual-conventions MIB for the ISAKMP DOI for IPSec has been posted as draft-ietf-ipsec-doi-tc-mib-00.txt. This defines textual conventions for all the magic numbers (enumerations) used in ISAKMP/IKE, so that a MIB can provide for meaningful decode. The intent is that the IANA will maintain this MIB as they assign magic numbers in the DOI. In this way, the DOI can grow without obsoleting MIBs that wish to symbolically decode the magic numbers. This revises draft-shriver-ipsec-doi-tc-mib-00.txt by adding one textual convention that I forgot, and it's now a working group document. (When I first submitted, there was not complete clarity whether the MIB was in the IPSec charter.) This document is also fairly handy for just understanding all the magic numbers, and where they fit. The descriptions are quite complete, and there are reference clauses too. The MIB itself passes strict tests by SMICng. There are no syntax problems. (But there may be typos!) From owner-ipsec@lists.tislabs.com Tue Mar 23 16:41:12 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA15905; Tue, 23 Mar 1999 16:41:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23734 Tue, 23 Mar 1999 16:46:39 -0500 (EST) Message-Id: <199903232209.RAA27768@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-doi-tc-mib-00.txt Date: Tue, 23 Mar 1999 17:09:11 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] --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 DOI Textual Conventions MIB Author(s) : J. Shriver Filename : draft-ietf-ipsec-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-ietf-ipsec-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-ietf-ipsec-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-ietf-ipsec-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. --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: <19990322165907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-doi-tc-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990322165907.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Mar 24 06:24:56 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA19325; Wed, 24 Mar 1999 06:24:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25213 Wed, 24 Mar 1999 06:03:38 -0500 (EST) Message-ID: <36F8CB76.183C51D4@cyphers.net> Date: Wed, 24 Mar 1999 03:24:45 -0800 From: Will Price X-Mailer: Mozilla 4.51 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@tislabs.com Subject: Re: Configuration of mobile users References: <199903180455.WAA00739@pzero.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Richardson wrote: > [..] > > To compare/contrast, I think the major advantage of isakmp-mode-cfg > is that one doesn't burn entropy from the DH making an IPsec SA that > is only used for three or four packets. Secondly, it isn't clear that > all "VPN" SAs will necessarily have selectors that permit the DHCP > traffic. > > The major advantage of ipsec-dhcp is that it reuses existing > protocol definitions, infra-structure, and DHCP has a clear mechanism > for extensions. I think the definition of existing is questionable here. For many implementations, DHCP "existing" is not the case. The reality would likely be a complete reimplementation of DHCP for BITS implementations. That's just not going to happen when there aren't really significant benefits from the DHCP proposal over mode-cfg. > I would like to suggest a compromise/hybrid solution: let's define a > payload/exchange type which carries DHCP payloads within ISAKMP. > > This has all the advantages of isakmp-mode-cfg: > 1. no seperate SA > 2. the ISAKMP learns about the parameters directly > > The speaker on Monday from Microsoft (Bernard I think) expressed the > belief that many of the PPP configuration options should have been > done via a DHCP Inform. I'm not qualified to agree or disagree with > this statement, but if true, would tend to support using DHCP. > > In addition, DHCP leases need to be renewed periodically. This > provides a *NATURAL* keep alive message for road warriors. Further, > DHCP says specific things about what a host is supposed to do as it > shuts down wrt sending out DHCP releases. I really don't believe what needs to be done is so complex that we need to drag in other protocols like DHCP. mode-cfg presents a nice, coherent method of doing this that can be relatively easily implemented within the existing IKE implementations that everyone has now and everyone has access to, and I believe we should focus on that if there are specific features of the DHCP draft that need to be moved into mode-cfg *without* moving "DHCP" itself. Bringing DHCP into the discussion is ignoring the fact that DHCP might as well not exist for many implementations. - -- Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. Direct (408)346-5906 Cell/VM (650)533-0399 -----BEGIN PGP SIGNATURE----- Version: PGP 6.5b23 iQA/AwUBNvjLJ6y7FkvPc+xMEQIh9ACg7OPUoQOcq43TR1LElDuhC/1czqwAn0iB 2iyLsTquqFl0T6cKl0Ze0qPx =WdKo -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Mar 24 15:02:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27030; Wed, 24 Mar 1999 15:02:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27112 Wed, 24 Mar 1999 14:28:44 -0500 (EST) Message-ID: <000701be762f$7e6596c0$c36840ce@milleniumtechnology.net> From: "Robert Zachary" To: "Stephan Warren" , , , , , "DC Folks" Subject: RasExp bug Date: Wed, 24 Mar 1999 13:49:52 -0600 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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Ideas ?? MultiTech RasExpress modem server: Scenario: external user connects to b2l7.xxx.com 123.123.123.123 I nuke b2l7.xxx.com 123.123.123.123 Ras still shows user connected. can not ping 123.123.123.123 they are nuked and disconnected yet RAS still shows them connected. Hit me with them.... /--------------------------------------------------------------/ Confidentiality, Integrity, Availibilty Robert Zachary Information Security Manager Our-Town Internet comp-sec@our-town.com http://www.our-town.com http://www.milleniumtechnology.net From owner-ipsec@lists.tislabs.com Wed Mar 24 15:12:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27119; Wed, 24 Mar 1999 15:12:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27307 Wed, 24 Mar 1999 15:47:03 -0500 (EST) Message-Id: <199903242110.NAA21766@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: linux-ipsec@clinet.fi Cc: Kevin Lahey , ipsec@lists.tislabs.com Cc: keith owens Cc: Alan Cox Cc: Charlie Perkins Cc: Gina Swallow , djskinna@bunkie.indy.net Cc: win95netbugs-owner@lists.stanford.edu Subject: linux-ipsec: cornered: MTU and fragmentation bugs In-reply-to: <3.0.3.32.19990324121019.02f9ffe8@surfcity.research.att.com> Date: Wed, 24 Mar 1999 13:10:02 -0800 From: John Gilmore Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Our initial operational experience with IPSEC is that inserting it into transmission paths provokes operational Path MTU Discovery problems that were not previously apparent. I'm forwarding a pretty succinct note from John Denker of AT&T that describes the problems. Besides circumventing this problem in Linux IPSEC, it should be brought up in a few more general fora. I'm amazed that the original Path MTU Discovery RFC (1191) never considered the failure mode that happens if ICMP messages don't get back to the sender. (The fix, to terminate MTU discovery after a few unsuccessful retransmissions, would have been simple had it been thought of.) I'm surprised that the Linux kernel (2.0) is not sending ICMP "fragmentation required and DF set" responses. I hope this is fixed in 2.1; RFC 1191 requires it. I've cc'd Alan Cox (Linux networking maintainer) and Keith Owens (who has posted several clear notes to linux-kernel about some aspects of the issue). I would have been shocked, shocked! had there not been an RFC or Internet-Draft about Path MTU Discovery failures. But indeed, the IETF "TCP Implementation" working group is working on it: http://www.ietf.org/internet-drafts/draft-ietf-tcpimpl-pmtud-00.txt I've cc'd the author of this draft, Kevin Lahey, on this message. The draft should definitely add mentions of the interaction of Path MTU problems, IP tunnelling, and IPSEC, including problems getting ICMP messages out of tunnels, and MTU's that are reduced by the size of tunnel and IPSEC headers. It should also cross-reference the Path MTU and Tunnel MTU discussions in RFC 2003 (IP-in-IP). It sounds like we need some cross-fertilization between the TCPIMPL and IPSEC working groups, and with other groups using IP-in-IP encapsulation (RFC's 2003 and 1853) such as MOBILEIP. John Date: Wed, 24 Mar 1999 12:10:19 -0500 To: linux-ipsec@clinet.fi From: John Denker Subject: linux-ipsec: cornered: MTU and fragmentation bugs Hi -- At the risk of being forever banished from the hacker community, and having my wizardly pointy hat confiscated, let me say this: The MTU/fragmentation bug is *not* microsoft's fault! Eeeck! Here's the deal: 0) Path-MTU discovery is a good thing. Typically this is done by initially sending large packets with the DF bit set, and seeing if they get through. 1) The microsoft TCP clients negotiate for a large initial MSS. This is perfectly legal, and should result in efficiency if other players do their part. This is necessarily done with no knowledge of the actual path-MTU. 2) This makes it likely that packets will be sent that exceed the MTU of some router along the path -- especially when there is encapsulation going on at some point, such as the ipsec tunnel. 3) The RFCs say that when an oversized packet (with the DF bit set) arrives, a router MAY return an ICMP message of type host-unreachable explaining that fragmentation is needed and suggesting a new packet size. In practice, path-MTU discovery without these frag-needed messages is somewhat inefficient. 4) Heretofore linux has not generated these frag-needed messages. I consider this a weakness in linux. I have a patch for this, as mentioned in previous notes. 5) What's worse, there are some firewalls (the Firewall-One brand in particular, and quite likely others) that in their usual configuration do not pass these ICMP frag-needed datagrams. I consider this a weakness in the firewalls. This is a pain in the neck to fix. 6) What's *much* worse is that practically all the web servers in the world improperly assume that the routers MUST return a frag-needed message. As much as you might enjoy bashing microsoft, their web site is the only one I've been able to discover that is both efficient and robust... efficient in that it starts out by sending large packets, and robust that it will (even in the absence of frag-needed messages) back off if they don't get through. Here is a partial list of servers I've checked: www.ibm.com inefficient: always requests a small MSS www.snap.com inefficient: always requests a small MSS www.toad.com inefficient: never sets DF, always sends small packets www.sandelman.ottawa.on.ca inefficient: never sets DF, always sends small packets www.hotbot.com chokes www.aol.com chokes www.netscape.com chokes www.altavista.com chokes www.yahoo.com chokes www.clinet.fi chokes www.sgi.com chokes www.intel.com chokes www.compaq.com chokes www.psi.net chokes www.cygnus.com chokes www.quintillion.com chokes www.research.att.com chokes Except for the first four, these servers are grossly noncompliant with the RFCs. ======== Solution #1 (ideal): Fix linux and fix the firewalls so that ICMP frag-needed messages are returned to servers who depend on them. This results in maximum efficiency. Solution #2 (for users who can't easily fix their firewalls): ipsec must (at least optionally) support a "virtually-enormous tunnel" mode. In that mode, as I have previously discussed, when a packet arrives that is too big to be transported in a single envelope, it should be fragmented (*regardless* of whether the DF bit was set) and transported in multiple envelopes. If the DF bit was set on the raw packet (and perhaps not otherwise) the packet should be reassembled by the other security gateway before being sent on its way. This behavior, while perhaps very slightly inefficient, is much more robust in the face of all those real-world ill-behaved web servers. A tunnel with virtually-infinite MTU doesn't offend me in the least. I consider it consistent with the fact that the tunnel shows up as virtually a single hop, no matter how many real-ethernet hops are used to transport the envelopes. IMHO this solution #2 is a required feature, necessary for version 1.00. It should be at least a compile-time option. Making it a run-time option would be even nicer, with (I would think) hardly any extra work. Cheers --- jsd [John Gilmore here again:] John Denker, when you say a Web server "chokes", you appear to mean that: * It sends big packets with "DF". * It doesn't recover if it never sees ICMP frag-neededs. This is, in fact, compatible with the current RFC's. The problem is a protocol design bug, not an implementation bug. See draft-ietf-tcpimpl-pmtud-00.txt for more details. RFC 1191 does require routers to return ICMP messages when they can't fragment a datagram, though it doesn't use those all-important capital letters in exactly the right place (it says "is required to" rather than "MUST" in section 4), and I haven't found an RFC that specifically says MUST about this. The RFC 1191 requirement was added shortly after the "Gateway Requirements" RFC 1009 collected all the little requirements into one place. I don't think a newer collection of router requirements has ever been issued, so it's easy for router mfrs to miss this one. Here are a few explanations of the general Path MTU problem. I've cc'd these folks too, so they can add this info to their explanations. http://www.indy.net/~gswallow/rtfm/mtu/index.html http://www.euronet.nl/~gco_fvee/win95netbugs/faq-c.html#c10 http://www.uwsg.indiana.edu/hypermail/linux/net/9701.1/0097.html http://ftp.std.com/obi/Networking/rfc/rfc1435.txt From owner-ipsec@lists.tislabs.com Thu Mar 25 10:25:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03289; Thu, 25 Mar 1999 10:25:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00865 Thu, 25 Mar 1999 10:43:44 -0500 (EST) Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: linux-ipsec: cornered: MTU and fragmentation bugs To: gnu@toad.com (John Gilmore) Date: Wed, 24 Mar 1999 22:33:32 +0000 (GMT) Cc: linux-ipsec@clinet.fi, kml@nas.nasa.gov, ipsec@lists.tislabs.com, kaos@ocs.com.au, alan@lxorguk.ukuu.org.uk, perk@watson.ibm.com, gswallow@indy.net, djskinna@bunkie.indy.net, win95netbugs-owner@lists.stanford.edu In-Reply-To: <199903242110.NAA21766@toad.com> from "John Gilmore" at Mar 24, 99 01:10:02 pm Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] > I'm surprised that the Linux kernel (2.0) is not sending ICMP > "fragmentation required and DF set" responses. I hope this is fixed I am not aware of any circumstances where Linux does not generate the appropriate messages. I think people would have noticed before two years ago if it was doing this wrong. viz.. if (skb->len+encap > dev2->mtu && (iph->frag_off & htons(IP_DF))) { ip_statistics.IpFragFails++; ..... ip_send(rt,skb2,raddr,skb->len,dev2,dev2->pa_addr); > 4) Heretofore linux has not generated these frag-needed messages. I > consider this a weakness in linux. I have a patch for this, as mentioned > in previous notes. No patch ever seen. > 5) What's worse, there are some firewalls (the Firewall-One brand in > particular, and quite likely others) that in their usual configuration do > not pass these ICMP frag-needed datagrams. I consider this a weakness in > the firewalls. This is a pain in the neck to fix. It isnt the products, its the morons who install them. They have basically made the internet a 1500 mtu fixed size network. If you attempt to reason with the people who paid stupid amounts of money to have a 'highly certified security consultant' install it they know they paid $30K so even if they are wrong they'd get fired by their boss if they admitted it. It is perfectly possible to correctly install these products. > Solution #1 (ideal): Fix linux and fix the firewalls so that ICMP > frag-needed messages are returned to servers who depend on them. This > results in maximum efficiency. I've no evidence from the past two years to believe Linux does this wrongly. Alan From owner-ipsec@lists.tislabs.com Thu Mar 25 10:26:48 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03313; Thu, 25 Mar 1999 10:26:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01024 Thu, 25 Mar 1999 10:51:35 -0500 (EST) Message-Id: <199903251614.LAA15050@istari.sandelman.ottawa.on.ca> To: Will Price CC: ipsec@lists.tislabs.com Subject: Re: Configuration of mobile users In-Reply-To: Your message of "Wed, 24 Mar 1999 03:24:45 PST." <36F8CB76.183C51D4@cyphers.net> Date: Thu, 25 Mar 1999 11:14:26 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] >>>>> "Will" == Will Price writes: Will> I think the definition of existing is questionable here. For many Will> implementations, DHCP "existing" is not the case. The reality would Will> likely be a complete reimplementation of DHCP for BITS Will> implementations. That's just not going to happen when there aren't BITS have to implement something. Frankly, I'm not clear why you wouldn't just take the DHCP data and punt it up to the real stack and be done with. DHCP also has the advantage that it is already defined, and has clear mechanisms for doing extensions. Mostly we are just talking about using the DHCP Acquire/Inform stuff, not the "discovery" stuff. Will> I really don't believe what needs to be done is so complex that we Will> need to drag in other protocols like DHCP. mode-cfg presents a nice, Then, I think you don't completely understand the problem, and you don't understand DHCP. The problem is complicated enough to require DHCP, and DHCP is not so complicated as to be much different from mode-cfg. Will> into mode-cfg *without* moving "DHCP" itself. Bringing DHCP into the Will> discussion is ignoring the fact that DHCP might as well not exist for Will> many implementations. Don't invent new protocols when you don't have to. All native implementations of IPsec probably already have DHCP code available, and there is freely available reference code from ISC. :!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@lists.tislabs.com Thu Mar 25 10:33:21 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03429; Thu, 25 Mar 1999 10:33:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00862 Thu, 25 Mar 1999 10:43:43 -0500 (EST) Message-Id: <199903242232.OAA05834@gecko.nas.nasa.gov> To: John Gilmore cc: linux-ipsec@clinet.fi, ipsec@lists.tislabs.com, keith owens , Alan Cox , Charlie Perkins , Gina Swallow , djskinna@bunkie.indy.net, win95netbugs-owner@lists.stanford.edu Subject: Re: linux-ipsec: cornered: MTU and fragmentation bugs In-reply-to: Your message of "Wed, 24 Mar 1999 13:10:02 PST." <199903242110.NAA21766@toad.com> Date: Wed, 24 Mar 1999 14:32:05 -0800 From: "Kevin M. Lahey" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] In message <199903242110.NAA21766@toad.com>John Gilmore writes >I would have been shocked, shocked! had there not been an RFC or >Internet-Draft about Path MTU Discovery failures. But indeed, >the IETF "TCP Implementation" working group is working on it: > > http://www.ietf.org/internet-drafts/draft-ietf-tcpimpl-pmtud-00.txt > >I've cc'd the author of this draft, Kevin Lahey, on this message. The >draft should definitely add mentions of the interaction of Path MTU >problems, IP tunnelling, and IPSEC, including problems getting ICMP >messages out of tunnels, and MTU's that are reduced by the size of >tunnel and IPSEC headers. It should also cross-reference the Path MTU >and Tunnel MTU discussions in RFC 2003 (IP-in-IP). It sounds like we >need some cross-fertilization between the TCPIMPL and IPSEC working >groups, and with other groups using IP-in-IP encapsulation (RFC's 2003 >and 1853) such as MOBILEIP. I have a revised draft about ready to roll, so I'd be happy to add a caveat about tunneling and a reference to RFC 2003. I'd welcome input on the draft. Thanks, Kevin Lahey kml@nas.nasa.gov From owner-ipsec@lists.tislabs.com Thu Mar 25 10:36:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA03460; Thu, 25 Mar 1999 10:36:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00966 Thu, 25 Mar 1999 10:48:45 -0500 (EST) Date: Wed, 24 Mar 1999 22:24:50 -0700 (MST) From: Greg Swallow To: Alan Cox cc: John Gilmore , postal!clinet.fi!linux-ipsec@bunkie.indy.net, postal!nas.nasa.gov!kml@bunkie.indy.net, postal!lists.tislabs.com!ipsec@bunkie.indy.net, postal!ocs.com.au!kaos@bunkie.indy.net, postal!lxorguk.ukuu.org.uk!alan@bunkie.indy.net, postal!watson.ibm.com!perk@bunkie.indy.net, postal!gswallow@bunkie.indy.net, postal!bunkie.indy.net!djskinna@bunkie.indy.net, postal!lists.stanford.edu!win95netbugs-owner@bunkie.indy.net Subject: Re: linux-ipsec: cornered: MTU and fragmentation bugs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] On Wed, 24 Mar 1999, it was written: >> I'm surprised that the Linux kernel (2.0) is not sending ICMP >> "fragmentation required and DF set" responses. I hope this is fixed > >I am not aware of any circumstances where Linux does not generate >the appropriate messages. I think people would have noticed before >two years ago if it was doing this wrong. Ok, here we go...I'm still new to all of this but this is how I was able to interpret it...I'll gladly take criticism too so please give me plenty of it if I'm dead wrong here. Indeed Linux does generate "Fragmentation needed but DF bit set" messages--I've seen them when I had the hardest time with a Path MTU blackhole that affected the entire ISP I worked for at the time, and my Linux (2.0.3x) box was the best test environment I could conjure up. The problem is when you have an intermediate router or firewall that isn't generating/passing the ICMP messages on to the next hop... My problem addressing the issue is that I didn't think that MSS's can be set up differently for each half of the connection, e.g., my MSS from my modem to the terminal server is set to 1460, but from the terminal server to my modem it'ss set up at 966. Therefore, the terminal server was holding up the connections. Actually, I believe that the correct way to state this is that you can have a different MRU and MTU altogether and they don't have to match. Also, MRU's tend to be negotiable; MTU's tend not to be negotiable. Therefore if I've negotiated an MRU of 1500, but the terminal server has an MTU of 1006 then the Frag warnings are sent the other direction. The firewall on the other end (or commonly, IP Masquerading software) doesn't forward on the ICMP gripe. So we're not discussing whether Linux generates these ICMP messages; we're discussing how to set up your IP Masquerading software (or firewall). Most ICMP messages are fairly useful, and therefore I'd only explicitly restrict incoming ICMP echo requests and perhaps outgoing ICMP host unreachable messages. As for tunnelling, I've never run across an path MTU black hole across a tunnel. I had to use Windows NT's PPTP (hunk-o-junk) to do it, but while everyone else dialing into a living, breathing terminal server had the MTU issues, the people setting up VPN's had none. Of couse, the MRU and MTU of the Windoze NT box was hard coded to 1500 as well... +------------- Greg Swallow ---- djskinna@bunkie.indy.net -------------+ |Diplomacy is the art of saying "nice doggy" until you can find a rock.| +----------------------------------------------------------------------+ From owner-ipsec@lists.tislabs.com Thu Mar 25 12:03:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA04117; Thu, 25 Mar 1999 12:03:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01388 Thu, 25 Mar 1999 12:20:40 -0500 (EST) Message-Id: <199903251740.JAA14105@gallium.network-alchemy.com> To: alan@lxorguk.ukuu.org.uk (Alan Cox) cc: gnu@toad.com (John Gilmore), linux-ipsec@clinet.fi, kml@nas.nasa.gov, ipsec@lists.tislabs.com, kaos@ocs.com.au, perk@watson.ibm.com, gswallow@indy.net, djskinna@bunkie.indy.net, win95netbugs-owner@lists.stanford.edu Subject: Re: linux-ipsec: cornered: MTU and fragmentation bugs In-reply-to: Your message of "Wed, 24 Mar 1999 22:33:32 GMT." Date: Thu, 25 Mar 1999 09:40:56 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] > It isnt [sic] the products, its [sic] the morons who install them. They > have basically made the internet a 1500 mtu fixed size network. Indeed "they" have. When I first started living on an IPSec tunnel to my house, I had to figure out why it was that I couldn't surf abcnews.com. Every other site I tried worked fine, just not abcnews.com. It turns out that they're sending full ethernet-sized MTU datagrams with DF set on all their packets. Furthermore, they're clearly filtering all ICMP in their boarder gateway router... Sigh. We're just going to have to take the time to painfully educate these network managers if we want to see IPSec widely deployed. Calling them morons, while perhaps accurate, isn't going to fix the problem. :-) Derrell From owner-ipsec@lists.tislabs.com Thu Mar 25 12:44:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA04520; Thu, 25 Mar 1999 12:44:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01605 Thu, 25 Mar 1999 13:18:46 -0500 (EST) Message-ID: <36FA7262.1ABA2730@redcreek.com> Date: Thu, 25 Mar 1999 09:29:06 -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: ietf-ipsra@vpnc.org CC: "Pereira, Roy" , ipsec@lists.tislabs.com Subject: concerns regarding work load References: <199903180455.WAA00739@pzero.sandelman.ottawa.on.ca> <36FA2722.558C5D8A@shiva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Monday, I sent an email to Roy expressing some concerns I have regarding getting ipsra going. I wanted to cc this list, but didn't think the list was up and running yet. I'm also cc'ing the ipsec list with this, in case some folks that are interested in ipsra haven't had a chance to subscribe yet. I've cut and pasted some of the text from my original email below, with some contextual modifications. I assume that we'll get an acceptable charter hammered out, and ipsra will become a working group. I have no doubt that the security policy working group will also go forward, and it will be a very substantial undertaking. I have 2 concerns as a result: first, the policy group will produce much important work, and so will be very involved and very time consuming. This will impact upon Roy's ability to devote the required attention to ipsra. Second, Roy has a bit of a stake in which remote access mechanism we select, given that he has 2 drafts out detailing his company's implementation. While I don't think either of these issues should rule Roy out as chair for ipsra, I would be much more comfortable if he had a co-chair who could help with the workload, and who might openly entertain alternative approaches. It may be that his proposed mechanisms will turn out to be the best, but we need an open debate to determine this. I'd be willing to co-chair with Roy if everyone is comfortable with this. If for some reason this is not acceptable, then I'd like an opportunity to nominate someone else. Scott From owner-ipsec@lists.tislabs.com Thu Mar 25 14:34:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA05677; Thu, 25 Mar 1999 14:34:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01858 Thu, 25 Mar 1999 14:57:19 -0500 (EST) From: Richard Guy Briggs Message-Id: <199903252029.PAA20786@grendel.conscoop.ottawa.on.ca> Subject: Re: linux-ipsec: cornered: MTU and fragmentation bugs To: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Thu, 25 Mar 1999 15:28:57 -0500 (EST) Cc: gnu@toad.com, linux-ipsec@clinet.fi, kml@nas.nasa.gov, ipsec@lists.tislabs.com, kaos@ocs.com.au, alan@lxorguk.ukuu.org.uk, perk@watson.ibm.com, gswallow@indy.net, djskinna@bunkie.indy.net, win95netbugs-owner@lists.stanford.edu In-Reply-To: from "Alan Cox" at Mar 24, 99 10:33:32 pm X-Mailer: ELM [version 2.4 PL25 PGP8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] -----BEGIN PGP SIGNED MESSAGE----- > > I'm surprised that the Linux kernel (2.0) is not sending ICMP > > "fragmentation required and DF set" responses. I hope this is fixed > > I am not aware of any circumstances where Linux does not generate > the appropriate messages. I think people would have noticed before > two years ago if it was doing this wrong. > > viz.. > > if (skb->len+encap > dev2->mtu && (iph->frag_off & htons(IP_DF))) > { > ip_statistics.IpFragFails++; > ..... > ip_send(rt,skb2,raddr,skb->len,dev2,dev2->pa_addr); Where is this code from? I assume ip_forward()? If so, I found the ICMP message call that I think you intended to reference, but I don't quite know why you quoted the ip_send() above... Can it always be assumed that ip_fragment is called after checking DF? ip_fragment() is not exclusively called from ip_forward(). The place John Denker speaks of is in ip_fragment. If a packet is sent to ip_fragment() (such as at the end of ip_output()) without checking DF, then the packet gets dropped silently. > > 4) Heretofore linux has not generated these frag-needed messages. I > > consider this a weakness in linux. I have a patch for this, as mentioned > > in previous notes. > > No patch ever seen. In case you didn't get it: *** ip_fragment.c.old Tue Mar 23 17:22:41 1999 - --- ip_fragment.c Tue Mar 23 17:24:34 1999 *************** *** 685,692 **** - --- 685,693 ---- if (iph->frag_off & htons(IP_DF)) { ip_statistics.IpFragFails++; NETDEBUG(printk("ip_queue_xmit: frag needed\n")); + icmp_send(skb,ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED,htons(dev->mtu) , dev); /* jsd */ return; } /* > > 5) What's worse, there are some firewalls (the Firewall-One brand in > > particular, and quite likely others) that in their usual configuration do > > not pass these ICMP frag-needed datagrams. I consider this a weakness in > > the firewalls. This is a pain in the neck to fix. > > It isnt the products, its the morons who install them. They have basically > made the internet a 1500 mtu fixed size network. If you attempt to reason > with the people who paid stupid amounts of money to have a 'highly certified > security consultant' install it they know they paid $30K so even if they are > wrong they'd get fired by their boss if they admitted it. > > It is perfectly possible to correctly install these products. How easy will it be to fix this critical mass? > > Solution #1 (ideal): Fix linux and fix the firewalls so that ICMP > > frag-needed messages are returned to servers who depend on them. This > > results in maximum efficiency. > > I've no evidence from the past two years to believe Linux does this wrongly. That doesn't mean it doesn't exist... I'm still trying to verify it... > Alan slainte mhath, RGB - -- Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada rgb at conscoop dot ottawa dot on dot ca FreeS/WAN: Please send all spam to root@127.0.0.1 Marillion: -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNvqch9+sBuIhFagtAQHXGAQAhVeLYTC9/R/bYVQd57pC9E72IceKL0B8 w7Ke7ic0M7qdQ7+5FiNbiEAqFNnCBEe+qYaxgdlT/rnHN4ULrQnWY3oSsft6GVnb 9wWqZjvd6bFBaIGhqp59Ey0TMnetxesX4493y1CHs/oknje6iqTZIW0rdJpGhWRR C1CJw7rrws4= =VpnN -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Mar 25 16:11:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA12971; Thu, 25 Mar 1999 16:11:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02201 Thu, 25 Mar 1999 16:49:58 -0500 (EST) Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: linux-ipsec: cornered: MTU and fragmentation bugs To: rgb@conscoop.ottawa.on.ca (Richard Guy Briggs) Date: Thu, 25 Mar 1999 22:51:59 +0000 (GMT) Cc: alan@lxorguk.ukuu.org.uk, gnu@toad.com, linux-ipsec@clinet.fi, kml@nas.nasa.gov, ipsec@lists.tislabs.com, kaos@ocs.com.au, perk@watson.ibm.com, gswallow@indy.net, djskinna@bunkie.indy.net, win95netbugs-owner@lists.stanford.edu In-Reply-To: <199903252029.PAA20786@grendel.conscoop.ottawa.on.ca> from "Richard Guy Briggs" at Mar 25, 99 03:28:57 pm Content-Type: text Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] > The place John Denker speaks of is in ip_fragment. If a packet is > sent to ip_fragment() (such as at the end of ip_output()) without > checking DF, then the packet gets dropped silently. > > No patch ever seen. > > In case you didn't get it: This doesnt appear to make sense. > - --- 685,693 ---- > if (iph->frag_off & htons(IP_DF)) > { > ip_statistics.IpFragFails++; > NETDEBUG(printk("ip_queue_xmit: frag needed\n")); > + > icmp_send(skb,ICMP_DEST_UNREACH,ICMP_FRAG_NEEDED,htons(dev->mtu) > , dev); /* jsd */ > return; This shouldnt be causing any problems because for all the cases that matter its handled higher up Viz: IGMP - never sets DF ip_forward - checks DF UDP - references it in 2.0 but doesnt use it TCP - uses DF and sets the MTU below the point it will fragment locally. The only case I can see where it might be relevant and a bug is looping back an oversized multicast frame when running as a multicast router. Can someone tell me under what circumstances they observed the event occuring > Alan From owner-ipsec@lists.tislabs.com Thu Mar 25 19:32:31 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA14627; Thu, 25 Mar 1999 19:32:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02479 Thu, 25 Mar 1999 19:53:23 -0500 (EST) Message-ID: <36FADFD5.20B99266@siara.com> Date: Thu, 25 Mar 1999 17:16:05 -0800 From: "Sunil.Vallamkonda" X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: info request Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Hello, I am looking for recommendations on vendors with product offering for IPSec/IKE software toolkit/protocol suites. Any suggestions/pointers is welcome. Thx. Sunil. From owner-ipsec@lists.tislabs.com Thu Mar 25 20:59:55 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA24221; Thu, 25 Mar 1999 20:59:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA02746 Thu, 25 Mar 1999 21:42:49 -0500 (EST) Message-Id: <2.2.32.19990326030538.00b4b920@mailhost.hq.freegate.com> X-Sender: jtardo@mailhost.hq.freegate.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Mar 1999 19:05:38 -0800 To: ipsec@lists.tislabs.com From: Joe Tardo Subject: HASH(1) or no HASH(1)? Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Question on IKE Notify/Delete messages in Phase 2 Informational Exchanges, to which I can't seem to find a reference to in the archives. According to RFC 2407, page 21, "Note Bene:"a Notify payload is fully protected only in Quick Mode". However, RFC 2409, page 19, Section 5.7 ISAKMP Informational Exchanges, "This protocol protects ISAKMP Informational Exchanges when possible" and goes on to describe: Initiator Responder --------- --------- HDR*, HASH(1), N/D --> ... So, which is it, should Info N/D's be HASH protected whenever possible or not? I only ask because I'm finding a lot of (encrypted but un-HASH-protected) Phase 2 INVALID PAYLOAD notify's coming back in response to my HASH protected DELETEs. Thanks, Joe From owner-ipsec@lists.tislabs.com Fri Mar 26 02:58:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA09088; Fri, 26 Mar 1999 02:58:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA03249 Fri, 26 Mar 1999 03:11:10 -0500 (EST) From: Jac Kloots To: ipsec Subject: RE: info request Date: Fri, 26 Mar 1999 09:34:17 +0100 Message-ID: <000001be7763$70822e80$696d57c0@kloots.surfnet.nl> 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.2232.26 In-Reply-To: <36FADFD5.20B99266@siara.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] > > Hello, > > > I am looking for recommendations on vendors with product offering for > IPSec/IKE software toolkit/protocol suites. > Any suggestions/pointers is welcome. > > Thx. > Sunil. > Hi. Try contacting SSH for their SSH IPsec and SSH ISAKMP/Oakley Toolkit at http://www.ipsec.com. Just send them email and request this kit. Greetings, Jac Kloots SURFnet bv. --------- Jac Kloots SURFnet bv tel. +31(0)302305305 Radboudburcht fax +31(0)302305329 POBOX 19035 email: Jac.Kloots@surfnet.nl 3501 DA UTRECHT Netherlands From owner-ipsec@lists.tislabs.com Fri Mar 26 05:03:53 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA12746; Fri, 26 Mar 1999 05:03:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA03435 Fri, 26 Mar 1999 05:06:52 -0500 (EST) Message-Id: <3.0.5.32.19990326123125.00b02d40@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 26 Mar 1999 12:31:25 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: HASH(1) or no HASH(1)? In-Reply-To: <2.2.32.19990326030538.00b4b920@mailhost.hq.freegate.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id FAA03432 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] At 19:05 25.3.1999 -0800, you wrote: >[ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. >There is no need to resubscribe, if you are on the list, you will remain >on it. Just begin sending posts, and any administrative requests to >lists.tislabs.com as of now. List mail to tis.com will cease to be >delivered as of March 26, 1999. ] > >Question on IKE Notify/Delete messages in Phase 2 Informational Exchanges, >to which I can't seem to find a reference to in the archives. > >According to RFC 2407, page 21, "Note Bene:"a Notify payload is fully >protected only in Quick Mode". > >However, RFC 2409, page 19, Section 5.7 ISAKMP Informational Exchanges, >"This protocol protects ISAKMP Informational Exchanges when possible" and >goes on to describe: > >Initiator Responder >--------- --------- >HDR*, HASH(1), N/D --> ... > > >So, which is it, should Info N/D's be HASH protected whenever possible or >not? I only ask because I'm finding a lot of (encrypted but >un-HASH-protected) Phase 2 INVALID PAYLOAD notify's coming back in response >to my HASH protected DELETEs. > >Thanks, >Joe Info N/D messages have a hash if phase 1 is finished. If some implementation rejects hash values there, I'd call it broken. Furthermore, I would never send a notify for an informational exchange. This can easily result in a notify storm. Jörn From owner-ipsec@lists.tislabs.com Fri Mar 26 08:10:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14855; Fri, 26 Mar 1999 08:10:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04278 Fri, 26 Mar 1999 08:31:03 -0500 (EST) Message-Id: <3.0.32.19990326180624.00bb86ac@brahma> X-Sender: snm@brahma X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 26 Mar 1999 18:06:26 +0500 To: ipsec@lists.tislabs.com From: snmurthy Subject: IPSec IKE software Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Hi, INTOTO Inc, Santa Clara, CA is selling IPSec, IKE and other VPN and Security software. You can contact Sathyan Iyengar at sathyan@intotoinc.com S N Murthy From owner-ipsec@lists.tislabs.com Fri Mar 26 08:10:28 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA14870; Fri, 26 Mar 1999 08:10:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA04206 Fri, 26 Mar 1999 08:27:02 -0500 (EST) Message-Id: <4.1.19990326015205.00b01e00@intotoinc.com> X-Sender: sathyan@intotoinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 26 Mar 1999 01:58:12 -0800 To: "Sunil.Vallamkonda" , ipsec@lists.tislabs.com From: Sathyan Iyengar Subject: Re: info request In-Reply-To: <36FADFD5.20B99266@siara.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Hi, Intoto Inc. provides complete software for IKE and IPSEC supported on Embedded Systems running RTOS. Contact info@intotoinc.com. -Sathyan > >Hello, > > >I am looking for recommendations on vendors with product offering for >IPSec/IKE software toolkit/protocol suites. >Any suggestions/pointers is welcome. > >Thx. >Sunil. > > /****************************************************************************** Embedded Solutions for PCMCIA, Flash, 1394, IPSEC and NAT Intoto Inc. Ph : 408-844-0480 Ext:302 3160, De La Cruz Blvd. Fax : 408-844-0488 Suite #100/101, Santa Clara e-mail : sathyan@intotoinc.com CA - 95054, USA Web : www.intotoinc.com ******************************************************************************/ From owner-ipsec@lists.tislabs.com Fri Mar 26 10:09:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA16611; Fri, 26 Mar 1999 10:09:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05106 Fri, 26 Mar 1999 10:34:09 -0500 (EST) From: "Ken Lindberg" To: Subject: RE: info request Date: Fri, 26 Mar 1999 10:51:52 -0500 Message-ID: <001701be77a0$90c820e0$20acddcf@nomad.tril-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <36FADFD5.20B99266@siara.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Contact Trilogy Inc. (http://www.tril-inc.com) at AdmitOne@tril-inc.com for information about their AdmitOne IPsec client (NT/Win95/Win98). Ken Lindberg ken@imachines.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Sunil.Vallamkonda > Sent: Thursday, March 25, 1999 8:16 PM > To: ipsec@lists.tislabs.com > Subject: info request > > > [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. > There is no need to resubscribe, if you are on the list, you will remain > on it. Just begin sending posts, and any administrative requests to > lists.tislabs.com as of now. List mail to tis.com will cease to be > delivered as of March 26, 1999. ] > > Hello, > > > I am looking for recommendations on vendors with product offering for > IPSec/IKE software toolkit/protocol suites. > Any suggestions/pointers is welcome. > > Thx. > Sunil. > > From owner-ipsec@lists.tislabs.com Fri Mar 26 13:08:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA20155; Fri, 26 Mar 1999 13:08:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05759 Fri, 26 Mar 1999 12:28:08 -0500 (EST) Comments: Originally sent to TIS.COM Reply-To: From: bob@larribeau.com (Bob Larribeau) To: , , Subject: PPP/IPSEC Interoperability Workshop Date: Fri, 26 Mar 1999 09:38:51 -0800 Message-ID: <000301be77af$83b2d530$73e79ecd@senior> 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.2232.26 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Here is the application for the next PPP/IPSEC Interoperability Workshop. Please return completed applications to me by email. We will have this application up on our web site in a few days at http://www.ciug.org. We are sending the full application to the email lists in advance of that to give you a chance to register early. Bob Larribeau bob@larribeau.com ----------------------------------------------------------------------- Return your application via email and reserve your hotel rooms before May 3, 1999! To Networking Product Developers: Ericsson Datacom Access Products invites you to participate in the VPN Interoperability Workshop featuring IPSec/IKE, L2TP, and PPP features at Fess Parker's DoubleTree Resort in Santa Barbara, California. The VPN Workshop combines the ninth CalBUG (formerly CIUG) PPP Interoperability Workshop and the seventh IPSec Interoperability Workshop. The Workshop will be open to companies with products that implement any of the following protocols: IP Security (IPSec) Internet Key Exchange (IKE) IP Payload Compression (IPComp) PPP L2TP over Transport-Mode IPSec PPP Layer 2 Tunneling Protocol (PPP L2TP) without Flow Control Compression Control Protocol (CCP) with MPPC and MPPE MS Challenge Handshake Authentication Protocol (MS CHAP) Version 2 Extensible Authentication Protocol (EAP) Point to Point Tunneling Protocol (PPTP) PPP over Ethernet (PPPoE) The Workshop will provide an opportunity to test the interoperability of your products with products from all of the other companies attending. The participating companies are asked to bring products that are released, at beta or near beta level for the protocols being tested. Participants are engineering staff intimately familiar with the software and hardware that implements the capabilities being tested and are expected to have a thorough understanding of the protocols. This Workshop will be open to only the participants. This is not a spectator event; it is not open to observers. Some participants will be working with unreleased products and the other attendees are expected to respect their privacy. SPONSORSHIP: Ericsson is the host for the VPN Interoperability Workshop. MCI Worldcom Advanced Networks will provide the Backbone Test Ethernet and access to the real Internet. Madge will provide ISDN lines and CalBUG (formerly CIUG) will provide infrastructure equipment for the workshop test network. SCHEDULE: Sunday, May 23 12:00 Noon to 6:00 PM Arrival and Set Up Equipment 5:00 PM - 6:30 PM Reception Monday, May 24 7:00 AM to 8:30 AM Buffet Breakfast 8:00 AM Testing Begins 12:00 Noon Lunch 1:00 PM to 8:00 PM Testing Tuesday, May 25 7:00 AM to 8:30 AM Buffet Breakfast 8:00 AM to 8:00 PM Testing 12:00 Noon Lunch Wednesday, May 26 7:00 AM to 8:30 AM Buffet Breakfast 8:00 AM to 8:00 PM Testing 12:00 Noon Lunch 3:00 PM to 5:00 PM Group Meeting 6:00 PM Pizza Thursday, May 27 7:00 AM to 8:30 AM Buffet Breakfast 8:00 AM to 8:00 PM Testing 12:00 Noon Lunch Friday, May 28 7:00 AM to 8:30 AM Buffet Breakfast 8:00 AM to 5:00 PM Testing 12:00 Noon Box Lunch 3:00 PM Break Down Facility FEES: The charge for the Workshop is $300 per person. The fee is for the entire week and covers the cost of the meals and hotel facility. Each person attending must pay the full amount. There will be no provision for a daily rate for those not attending the entire week. Checks, wire transfers, or credit cards will be accepted. Cash payments are not available. Payment must be received in advance. Refunds will not be made for cancellations after May 10, 1999. Please fill out and return the payment form with your payment. FACILITIES: Tables and Power: Each participating company will be provided one table, 5 Amps of power, and one power strip. Bring additional power strips if you need them. If you know your test setup will require more than 5 Amps please provide that information in advance on the application form and it will be available. Backbone Ethernet Network: Each participating company will be provided a single RJ-45 cable attached to the backbone Ethernet network. The backbone Ethernet network will be a public class C network that is connected to the Internet via a router with all routes configured statically (no dynamic routing). In the application you will be asked to specify which of the following configurations you will need and the quantity. You may request multiple host or routed network addresses but you must bring your own switches/hubs to attach more than a single device to the backbone Ethernet network. Configurations 2 and 3 require you to bring your own router. Configuration 1: Host address; a single IP address assigned from the backbone Ethernet network (a public class C network). Configuration 2: Routed private network address; a single IP address assigned from the backbone Ethernet network (a public class C network) and a private class C network (to be assigned) with a static route configured in the backbone router to the single IP address. Configuration 3: Routed private and public network addresses; a single IP address assigned from the backbone Ethernet network (a public class C network) and a private class C network (to be assigned) and a public subnetwork (/29 subnet address to be assigned) with a static route for both networks configured in the backbone router to the single IP address. Note: you can not reach the Internet with private network addresses. If these configurations do not satisfy your requirements, please contact James Matheke at 614-723-1525 or jmatheke@wcom.net. File Transfer Servers: Servers will be available for file transfers as defined in the test procedures. CA Certificates: To arrange certificates with CA providers prior to the workshop, please go to www.vpnc.org for details. ISDN Lines: BRI and PRI lines will be provided for testing from a Madge switch. The BRI lines will be provisioned as NI-1 with CSV/D on each B channel. The BRI lines may be either a U or S/T interface. There will be a limited number of PRI lines available. The PRI lines will be assigned to those companies with products that do not support BRI. If you request a PRI line, please bring a CSU and the crossover cable to terminate the T1 interface. The PRI lines will be NI-2. Telephone Service: There will be a telephone on each table in the workshop for voice service provided by a networked PBX. SHIPPING EQUIPMENT TO FESS PARKER'S DOUBLETREE RESORT IN SANTA BARBARA, CALIFORNIA Participants will be responsible for bringing workstations and network equipment. You may ship your equipment to: Attention: Laurie Nathanson Your Name, Guest, Ericsson VPN Workshop Fess Parker's DoubleTree Resort 633 East Cabrillo Boulevard Santa Barbara, California 93103 805-564-4333 Schedule your equipment to arrive at Fess Parker's DoubleTree Resort between May 15-22, 1999. Please provide shipping information, such as date shipped, tracking number, and number of boxes to Fess Parker's DoubleTree Resort so receipt of your shipment may be confirmed and accepted. IMPORTANT: Please bring the shipping documents for the return of your equipment back to your company. These documents include the carrier form. International shipments must include all appropriate documents, including carrier forms and invoices. Additionally, please make arrangements with your carrier in advance for pickup of the equipment at Fess Parker's DoubleTree Resort on Friday, May 28, 1999. These two points are very important. Neither Ericsson nor Fess Parker's DoubleTree Resort will be able to provide shipping forms or customs forms to you. You have to bring your own. Also neither Ericsson nor Fess Parker's DoubleTree Resort will be able to store your equipment past May 28, 1999. ACCOMMODATIONS: Be sure to register by May 3, 1999, to insure that rooms will be available for you and your group. The block of rooms is available at: Fess Parker's DoubleTree Resort 633 East Cabrillo Boulevard Santa Barbara, California 93103 805-564-4333 Register under "Ericsson VPN Workshop" to get the Workshop rate of $135.00 plus tax per night. Rooms are available for check in May 23, 1999 through check out May 28, 1999. Check in time is 4:00 PM and check out time is 12:00 Noon. About Fess Parker's DoubleTree Resort: www.fessparkersdoubletree.com Fess Parker's DoubleTree Resort has many athletic adventures including an outdoor heated pool and whirlpool, tennis and basketball courts and an exercise room. There are waterfront running trails and bike and skate paths. Be sure to bring proper attire to take advantage of these features. Fess Parker's DoubleTree Resort provides complimentary transportation to and from the Santa Barbara Airport. There is an electric bus from the Resort to downtown Santa Barbara for your local transportation. The fare is 25 cents. You may not require a rental car during your stay in Santa Barbara. Airport Access: Airline service is available to Santa Barbara (SBA), California. Alternately, you may fly to Los Angeles (LAX), California and drive approximately two hours to Santa Barbara. Directions from Santa Barbara Airport: -From the airport, turn left onto William Moffet Road (at the curve, the road becomes Fairview Avenue). -Stay on Fairview Avenue. At the overpass, turn right onto the 101 South onramp. -Take the 101 freeway south (approximately 13 miles) then exit at Castillo St, Harbor. -Stay in the rightmost lane, and turn right at the light onto Castillo. -Get into the center lane right away and follow is all the way to the end of Castillo St. -Turn left onto Cabrillo Bl. -Follow Cabrillo Bl. along the ocean (about 1 mile) until you get to Calle Puerto Vallarta. -Turn left on Calle Puerto Vallarta (there is a rainbow structure in front of the light). -Your first left is the entrance to the hotel. It will lead you to the lobby and parking lot. Directions from Los Angeles Airport: -Take Century Boulevard to 405 North, about 2 miles. Exit in second lane from right. -Take 405 North to 101 North, signed to Ventura, about 10 miles. Exit in second lane from right. -Take 101 North through Ventura to Santa Barbara, about 75 miles. -Exit at Cabrillo Blvd offramp and turn right onto Cabrillo. -Follow Cabillo Blvd along the ocean (about 1 mile) until you get to Calle Puerto Vallarta. -Turn right on Calle Puerto Vallarta (there is a rainbow structure in front of the light). -Your first left is the entrance to the hotel. It will lead you to the lobby and parking lot. PRESS RELEASE: Ericsson plans to make a press release following the workshop. There will be no mention of any specific results of the testing in this release. Please indicate in the application if you want your company's name included in this release as a participant. If you include your public relations person in the application, that contact will be given the opportunity to review the release in advance. REGISTRATION: This will be a "self organizing" event. It will be your responsibility to develop your own test schedule and to arrange your own testing partners. This method has worked well in the past and we believe that it provides the most productive environment for testing. In the application you will be asked to list the days you will be available for testing. Please be accurate so everyone has an opportunity to test with you. Please fill out the Product Section of the application carefully defining the supported capability list for the protocol options you will test at the workshop. We will use the information to put together a binder of data to assist when you are testing with partners. To register for the VPN Interoperability Workshop fill out the following application and return it by email immediately to reserve your place. The email address is . If you have any questions, send email or call Bob Larribeau, bob@larribeau.com , 415-241-9920 Based on past workshops, expected attendance is 60 companies. Get the reservation in early to assure yourself a place. ------------------------------ PAYMENT FORM---------------------------- PLEASE RETURN THIS APPLICATION VIA EMAIL. Name: __________________________________ Company: _______________________________ Address: _________________________________ __________________________________________ City, State, Zip ________________________________ Country: _____________________________________ Phone: _________________________________ Fax: ___________________________________ Email: _________________________________ Number of Attendees: _________ x $300.00 = Total Payment $_____________ Refunds will not be made for cancellations after May 3, 1999. Pay by credit card: Fill out the form below and fax it to the CalBUG at (415) 753-6942. Credit Card Type (Circle One): American Express Visa Novus/Discover Master Charge JCB Credit Card Number: ______________________________ Expiration Date: _________________________________ Name: ____________________________________________ Signature: _______________________________________ Pay by check: Send a check made out to the CalBUG for $300 for each participant to: California Broadband User's Group, PO Box 27901-391, San Francisco, CA 94127 Wire funds to: California Broadband Users' Group Account Number 02882 07752 Bank of America #0288 288 West Portal Avenue San Francisco, CA 94127 USA ----------------------------------------------------------------------- APPLICATION PLEASE RETURN THIS APPLICATION VIA EMAIL. Please enter the name of the Workshop Coordinator who will coordinate your registration. We will send emails to this person to give the latest information on the workshop and to verify your registration. Name: __________________________________ Address: _________________________________ __________________________________________ City, State, Zip ________________________________ Country: _____________________________________ Phone: _________________________________ Fax: ___________________________________ Email: _________________________________ Do you want your company's name included in the Ericsson press release as a participant? Yes or No Provide the name, address, phone, fax, and email of your public relations contact. We will give this person an opportunity to review the release in advance. Names of ALL Participants (including the Workshop Coordinator listed above if they will attend): Name_____________________ Name_____________________ Name_____________________ Days available for testing: M Tu W Th F Number of tables: ---------------------------------------------------------------------- IP Addresses- Number of Host addresses (configuration 1): Number of Routed private network addresses (configuration 2): Number of Routed private and public network addresses (configuration 3): Additional Power Requirements: Number of BRI lines: 1 2 More than 2 (please specify) S/T or U interface: PRI (Yes or No): Additional Madge Switch Requirements: ---------------------------------------------------------------------- Features you will be TESTING: IPSec (Y/N) IKE (Y/N) IP Payload Compression (Y/N) L2TP over Transport-Mode IPSec (Y/N) L2TP without Flow Control (Y/N) CCP with MPPC (Y/N) CCP with MPPE (Y/N) MS CHAP Version 2 (Y/N) EAP (Y/N) PPTP (Y/N) PPP over Ethernet (PPPoE) (Y/N) ---------------------------------------------------------------------- Will you be providing: CA services (Y/N) For CA service providers, please contact paul.hoffman@vpnc.org to make arrangements for the participants to reach you prior to the workshop. For participants, please go to www.vpnc.org for details to arrange CA services prior to the workshop. ----------------------------------------------------------------------- Product Functionality Section: The purpose of this survey is to identify supported features so that vendors will know who is implementing what, can know who to discuss the detailed functionality with, and to identify products for more serious compatibility testing later. Fill out a Product Section to describe supported features for each device or software package you will have at the workshop. If the version is unreleased, indicate 'alpha', 'beta', RC (release candidate) or build number. Options marked with * are advanced features. --- 1--- Product Name: Software Version and OS compatibility: Product Type, check all that apply: Router_____ Firewall_____ IPSec Gateway_____ IPSec Host_____ VPN Client Software_____ End to End (Tunnel/Transport) Client_____ Other________________________ --- 2--- Product Name: Software Version and OS compatibility: Product Type, check all that apply: Router_____ Firewall_____ IPSec Gateway_____ IPSec Host_____ VPN Client Software_____ End to End (Tunnel/Transport) Client_____ Other________________________ --- 3--- Product Name: Software Version and OS compatibility: Product Type, check all that apply: Router_____ Firewall_____ IPSec Gateway_____ IPSec Host_____ VPN Client Software_____ End to End (Tunnel/Transport) Client_____ Other________________________ =====IPSEC=====IPSEC=====IPSEC=====IPSEC===== IPSec manual keys SA configuration (keys, SPI, algorithms) (Y/N) Minimum key length (Y/N) If yes, key length________________ AH tunnel (Y/N) AH transport (Y/N) ESP tunnel (Y/N) ESP transport (Y/N) Transport adjacency: applying more than one security protocol to the same IP datagram, without invoking tunneling, eg. [IP][AH][ESP][packet payload] (Y/N) Nested tunneling from the same box: "Tunneling IPSec in an IPSec tunnel", eg. [IP][IPSec][IP][IPSec][packet payload] where "[IPSec]" could be "[ESP]" or "[AH]" or "[AH][ESP]" and where "[packet payload]" could be a ULP or another entire IP datagram. (Y/N) Iterated tunneling on same box: "Terminate a tunnel on one interface and forward the packets out on a different tunnel on a different interface" (Y/N) ESP cipher algorithms- DES-CBC (Y/N) 3DES (Y/N) NULL encryption (Y/N) *RC5 (Y/N) *CAST (Y/N) *Blowfish (Y/N) *IDEA (Y/N) *DES-X (Y/N) ESP authenticators- HMAC-MD-5 (Y/N) HMAC-SHA-1 (Y/N) *HMAC RIPEMD-160 (Y/N) AH algorithms- HMAC-MD-5 (Y/N) HMAC-SHA-1 (Y/N) *HMAC RIPEMD-160 (Y/N) *IPP Compression Protocol- LZS (Y/N) DEFLATE (Y/N) =====IKE=====IKE=====IKE=====IKE===== IKE===== IKE Exchanges- Main/Quick mode (identity protect) (Y/N) *Aggressive mode (Y/N) *IKE Config (Y/N) *XAUTH (Y/N) *DHCP Inform for internal tunnel config (Y/N) *New Group Mode (Y/N) IKE Authentication methods- Preshared keys (Y/N) Minimum length (Y/N) If yes, length_____________ *RSA signature (Y/N) *DSS signature (Y/N) *RSA Encryption (Y/N) *Revised RSA encryption (Y/N) *GSSAPI-Kerberos v5 (Y/N) IKE Key Material- Groups supported (1,2,3,4,5,others)__________ *Elliptic Curve Groups_____________ *DH-less IKE_________ Main mode PFS (1 MM per quick mode) (Y/N) Quick mode PFS (Y/N) Minimum quickmode lifetime (bytes/secs)_________ IKE Encryption algorithms- DES (Y/N) 3DES (Y/N) CAST (Y/N) RC5 (Y/N) Blowfish (Y/N) IDEA (Y/N) Other__________________ IKE Hash algorithms- MD-5 (Y/N) SHA-1 (Y/N) *HMAC RIPEMD-160 optional (Y/N) IKE Certificates- *IKE Certificate Validation (Y/N) Validate subject name against IPSec policy data (Y/N) Normal operation requires on-line access to CA for enrollment (Y/N) Certificate Request Payload (Reqd/Optional/Not Used and Ignored)______________ *Certificate chains in band, means exchanged in IKE (Y/N) CRL support (Reqd/Optional/ None)___________ CRL retrieval mechanism (http, file, LDAP)______________ Normal operation (Reqd/Optional/ Don't Care and Not Used) on-line access to CRL distribution point __________________ IKE Optional payloads---------------- *IKE Cert types - CERT (Y/N) CRL (Y/N) ARL (Y/N) PKCS7 (Y/N) Certificate signature algorithms supported (MD5, SHA1, etc)__________ IPSec only certificate key usage (Reqd/Optional/Don't Care)___________ Other certificate restrictions______________ *IKE Cert request types - CERT (Y/N) CRL (Y/N) ARL (Y/N) PKCS7 (Y/N) IKE Other Options- *Vendor-ID (Y/N) *Commit bit (Y/N) *Use quick mode lifetime notifies (Y/N) *Use Initial Contact (Y/N) *Send delete payload for quickmode SAs (Y/N) *Send delete payload for main mode SAs (Y/N) *CA Interoperability Issues- *RFC2510 (Y/N) *PKCS 10/7 (Y/N) *PKCS #12 (Y/N) Manual certificate enrollment (Y/N) *Level of CA hierarchies supported (number levels/No)___________ *Support certs issued by a subordinate CA, which is a child of a different vendor CA (cross certification) (Y/N) For IPComp (RFC 2393)--------------------------------------------------------- Compression algorithms- DEFLATE - RFC 2394 (Y/N) LZS-RFC 2395 (Y/N) Negotiation mechanism- IKE (Y/N) Manually-configured (Y/N) Negotiated with- ESP/AH (Y/N) Standalone (Y/N) =====PPP=====PPP=====PPP=====PPP===== PPP===== LCP Options: Default MRU__________________________ Default MRRU_________________________ Authentication: CHAP authenticator (Y/N) CHAP authenticatee (Y/N) CHAP Re-challenge (Y/N) MS CHAP (Y/N) MS CHAP V2 (Y/N) Compression: STAC (Y/N) STAC DCP (Y/N) STAC Options _________ MPPC (Y/N) MPPE (Y/N) WCP (Y/N) Predictor (Y/N) Other__________________ IPCP: Numbered links (Y/N) Un-numbered links (Y/N) Tx if Un-numbered____________ Options supported____________ IP assignment (Y/N) IP Pool (Y/N) DHCP (Y/N) IPXCP: Numbered links (Y/N) Un-numbered links (Y/N) Tx if Un-numbered____________ Options supported____________ =====L2TP=====L2TP=====L2TP=====L2TP=====L2TP= Provide LAC (Y/N) Provide LNS (Y/N) Provide L2TP Client (Y/N) L2TP Access Concentrator (LAC) Options: Proxy LCP (Y/N) Proxy Authentication PAP (Y/N) Proxy Authentication CHAP (Y/N) Proxy Authentication MS-CHAP (Y/N) Tunnel Authentication (Y/N) Hidden AVPs (Y/N) Outgoing Calls (Y/N) Sequencing (Y/N) L2TPSEC (Y/N) L2TP secured by IPSec (Reqd/Optional/No)___________ If yes, IKE authentication using identity protect or aggressive mode__________ If yes, IKE authentication using (machine/user/other) credential___________ If yes, IKE authentication (pre-shared key only/certs only/both/other)__________ L2TP Network Server (LNS) Options: Proxy LCP (Y/N) Proxy Authentication PAP (Y/N) Proxy Authentication CHAP (Y/N) Proxy Authentication MS-CHAP (Y/N) Tunnel Authentication (Y/N) Hidden AVPs (Y/N) Outgoing Calls (Y/N) Sequencing (Y/N) MP (bundle tunneled links) (Y/N) ECP (Y/N) CCP (Y/N) Algorithms______________________________ CBCP (Y/N) L2TPSEC (Y/N) L2TP secured by IPSec (Reqd/Optional/No)___________ If yes, IKE authentication using identity protect or aggressive mode__________ If yes, IKE authentication using (machine/user/other) credential___________ If yes, IKE authentication (pre-shared key only/certs only/both/other)__________ Tunnel Types- Voluntary (Y/N) Compulsory (Y/N) Client L2TP Options: Tunnel Authentication (Y/N) Hidden AVPs (Y/N) Outgoing Calls (Y/N) Sequencing (Y/N) L2TPSEC (Y/N) L2TP secured by IPSec (Reqd/Optional/No)___________ If yes, IKE authentication using identity protect or aggressive mode__________ If yes, IKE authentication using (machine/user/other) credential___________ If yes, IKE authentication (pre-shared key only/certs only/both/other)__________ =====PPTP=====PPTP=====PPTP=====PPTP=====PPTP= PAC (Y/N) PNS (Y/N) PPTP Client (Y/N) PPTP Options - PAC: Outgoing calls (Y/N) Incoming calls (Y/N) PPTP secured by IPSec (Reqd/Optional/No)___________ Ring-time tunnel (Y/N) Username-based tunnel (Y/N) PPTP Options - PNS: Outgoing calls (Y/N) Incoming calls (Y/N) MP (bundle tunneled links) (Y/N) MPPE (Y/N) CCP (Y/N) Algorithms______________ PPTP secured by IPSec (Reqd/Optional/No)___________ Tunnel types - Voluntary (Y/N) Compulsory (Y/N) PPTP Options - Client: MPPE (Y/N) CCP (Y/N) Algorithms______________ PPTP secured by IPSec (Reqd/Optional/No)___________ =====EAP=====EAP=====EAP =====EAP ===== EAP== Identity (Y/N) Number of retries__________ Notification (Y/N) Nak (response only) (Y/N) MD5-Challenge (Y/N) S/Key (RFC 1760) (Y/N) Generic Token Card (Y/N) RADIUS EAP-Proxy (Y/N) Other________________________ =====PPPoE===== PPPoE ===== PPPoE ===== PPPoE == Client: Can select from multiple services (Y/N) AC-Cookie Tag (Y/N) Host-Uniq Tag (Y/N) Relay-Session-Id (Y/N) PPPoE Active Discovery Terminate (PADT) packet (Y/N) Server: Can offer multiple services (Y/N) AC-Cookie Tag (Y/N) Host-Uniq Tag (Y/N) Relay-Session-Id (Y/N) PPPoE Active Discovery Terminate (PADT) packet (Y/N) ---------------------------------------------------------------------------- ----------- From owner-ipsec@lists.tislabs.com Mon Mar 29 01:12:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA20476; Mon, 29 Mar 1999 01:12:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA14095 Mon, 29 Mar 1999 01:06:10 -0500 (EST) Message-ID: <36FF1DC0.8909FC6F@lmf.ericsson.se> Date: Mon, 29 Mar 1999 09:29:20 +0300 From: Ari Huttunen Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: 3DES with 40-bit key? Content-Type: multipart/mixed; boundary="------------42C63E1A418889DC1907E33B" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] This is a multi-part message in MIME format. --------------42C63E1A418889DC1907E33B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Many of you will think this issue is braindead. I agree. However, as I understand that from now on the only MUST IMPLEMENT algorithm for ISAKMP and IPSEC is 3DES, the issue of what to do with export control rises. So, assume that export control limits the key length to 40 bits. How would I specify and negotiate this with IKE? Ari Huttunen It's about authentication between peers, the rest is IKE. --------------42C63E1A418889DC1907E33B Content-Type: text/x-vcard; charset=us-ascii; name="Ari.Huttunen.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ari Huttunen Content-Disposition: attachment; filename="Ari.Huttunen.vcf" begin:vcard n:Huttunen;Ari tel;fax:+358-9-2992634 tel;work:+358-9-2992472 x-mozilla-html:FALSE org:L M Ericsson;LMF/T/TK version:2.1 email;internet:Ari.Huttunen@lmf.ericsson.se title:Software Designer adr;quoted-printable:;;Oy L M Ericsson Ab=0D=0ATelecom R&D;;;02420 Jorvas;Finland x-mozilla-cpt:;-30024 fn:Ari Huttunen end:vcard --------------42C63E1A418889DC1907E33B-- From owner-ipsec@lists.tislabs.com Mon Mar 29 01:18:25 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA20524; Mon, 29 Mar 1999 01:18:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA14229 Mon, 29 Mar 1999 01:43:00 -0500 (EST) Date: Sun, 28 Mar 1999 23:03:19 -0800 From: jim@mentat.com (Jim Gillogly) Message-Id: <199903290703.XAA29069@zendia.mentat.com> To: ipsec@lists.tislabs.com Subject: Re: 3DES with 40-bit key? X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Ari Huttunen wrote: > Many of you will think this issue is braindead. > I agree. However, as I understand that from now > on the only MUST IMPLEMENT algorithm for ISAKMP > and IPSEC is 3DES, the issue of what to do with > export control rises. So, assume that export > control limits the key length to 40 bits. How > would I specify and negotiate this with IKE? I wouldn't say it's a braindead idea -- just that it's wrong. 3DES is defined in RFC 2451 as having a 192-bit key; 168 bits participate in the key schedule. The key length is not negotiable for this cipher. If you were to do the equivalent of the CDMF transform to create a DES-like cipher with 40 bits of strength, it wouldn't be DES; similarly, a 40-bit version of 3DES would not be 3DES, and you would not have implemented this cipher, so you would not have satisfied any MUST IMPLEMENT clause. If you did something like this and tried to pass it off as a conforming IPSec implementation, it would be fraudulent. If you can't get export licenses for the algorithms you want, then you can't export them. Simple as that. By the way, the "weak ciphers for US export" limit has been raised to 56 bits with a BXA review. Jim Gillogly From owner-ipsec@lists.tislabs.com Mon Mar 29 03:08:09 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA21722; Mon, 29 Mar 1999 03:08:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA14734 Mon, 29 Mar 1999 03:35:05 -0500 (EST) Message-ID: <36FF408B.DD143198@utimaco.co.at> Date: Mon, 29 Mar 1999 10:57:47 +0200 From: Michael Schmidt Organization: Utimaco Safe Concept GmbH X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,de-DE, de-AU MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: 3DES with 40-bit key? References: <36FF1DC0.8909FC6F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] Hi, > Many of you will think this issue is braindead. > I agree. However, as I understand that from now > on the only MUST IMPLEMENT algorithm for ISAKMP > and IPSEC is 3DES, the issue of what to do with > export control rises. So, assume that export > control limits the key length to 40 bits. How > would I specify and negotiate this with IKE? Is there a new draft out? RFC 2406 states out that (standard) DES CBC and NULL Encryption are the only mandatory ESP algorithms. Same for RFC 2407. How far am I behind? Michael -- Michael Schmidt | Utimaco Safe Concept GmbH | Tel: ++43 732 655 755 - 35 Europaplatz 6 | Fax: ++43 732 655 755 - 5 A-4020 Linz, Austria | E-Mail: Michael.Schmidt@utimaco.co.at From owner-ipsec@lists.tislabs.com Mon Mar 29 05:31:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA25047; Mon, 29 Mar 1999 05:31:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA15129 Mon, 29 Mar 1999 05:23:49 -0500 (EST) Message-ID: <36FF5A20.5D0D8DE8@lmf.ericsson.se> Date: Mon, 29 Mar 1999 13:46:56 +0300 From: Ari Huttunen Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Re: 3DES with 40-bit key? References: <199903290703.XAA29069@zendia.mentat.com> Content-Type: multipart/mixed; boundary="------------DA05E7AB4FBE042BD205EBA9" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. There is no need to resubscribe, if you are on the list, you will remain on it. Just begin sending posts, and any administrative requests to lists.tislabs.com as of now. List mail to tis.com will cease to be delivered as of March 26, 1999. ] This is a multi-part message in MIME format. --------------DA05E7AB4FBE042BD205EBA9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit jim@mentat.com wrote: > > [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. > There is no need to resubscribe, if you are on the list, you will remain > on it. Just begin sending posts, and any administrative requests to > lists.tislabs.com as of now. List mail to tis.com will cease to be > delivered as of March 26, 1999. ] > > Ari Huttunen wrote: > > > Many of you will think this issue is braindead. > > I agree. However, as I understand that from now > > on the only MUST IMPLEMENT algorithm for ISAKMP > > and IPSEC is 3DES, the issue of what to do with > > export control rises. So, assume that export > > control limits the key length to 40 bits. How > > would I specify and negotiate this with IKE? > > I wouldn't say it's a braindead idea -- just that it's wrong. 3DES is > defined in RFC 2451 as having a 192-bit key; 168 bits participate in > the key schedule. The key length is not negotiable for this cipher. > If you were to do the equivalent of the CDMF transform to create a > DES-like cipher with 40 bits of strength, it wouldn't be DES; > similarly, a 40-bit version of 3DES would not be 3DES, and you would > not have implemented this cipher, so you would not have satisfied any > MUST IMPLEMENT clause. So, which algorithm would you recommend for an export hampered IPSec box to implement? Remember that it will have to be interoperable with the other routers out there, which by now will only have to support 3DES. (This was agreed to at last IETF, no RFCs have been changed yet.) Of course this is subject to security policy decisions. BTW, I find it hard to imagine someone implementing 3DES but not implementing DES. This too, however, is slightly beside the point. > > If you did something like this and tried to pass it off as a conforming > IPSec implementation, it would be fraudulent. If you can't get export > licenses for the algorithms you want, then you can't export them. > Simple as that. > > By the way, the "weak ciphers for US export" limit has been raised to > 56 bits with a BXA review. I wonder... If I remember correctly what the Wassenaar agreement stated, 56 bits was allowed for some uses, while still not allowed for all possible uses. In any case, for this discussion it can be any number of bits less than what 3DES needs. > > Jim Gillogly Ari Huttunen --------------DA05E7AB4FBE042BD205EBA9 Content-Type: text/x-vcard; charset=us-ascii; name="Ari.Huttunen.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ari Huttunen Content-Disposition: attachment; filename="Ari.Huttunen.vcf" begin:vcard n:Huttunen;Ari tel;fax:+358-9-2992634 tel;work:+358-9-2992472 x-mozilla-html:FALSE org:L M Ericsson;LMF/T/TK version:2.1 email;internet:Ari.Huttunen@lmf.ericsson.se title:Software Designer adr;quoted-printable:;;Oy L M Ericsson Ab=0D=0ATelecom R&D;;;02420 Jorvas;Finland x-mozilla-cpt:;-30024 fn:Ari Huttunen end:vcard --------------DA05E7AB4FBE042BD205EBA9-- From owner-ipsec@lists.tislabs.com Mon Mar 29 09:31:50 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28866; Mon, 29 Mar 1999 09:31:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16369 Mon, 29 Mar 1999 09:36:18 -0500 (EST) From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14079.35065.42637.412376@lohi.eng.telia.fi> Date: Mon, 29 Mar 1999 17:06:49 +0300 (EEST) To: Ari Huttunen Cc: ipsec@lists.tislabs.com Subject: Re: 3DES with 40-bit key? In-Reply-To: <36FF5A20.5D0D8DE8@lmf.ericsson.se> References: <199903290703.XAA29069@zendia.mentat.com> <36FF5A20.5D0D8DE8@lmf.ericsson.se> X-Mailer: VM 6.62 under Emacs 19.34.1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari Huttunen writes: > I wonder... If I remember correctly what the Wassenaar agreement > stated, 56 bits was allowed for some uses, while still not allowed > for all possible uses. In any case, for this discussion it can > be any number of bits less than what 3DES needs. the agreement didn't restrict the use of encryption, but export of encryption. if is fine with me to specify only 3des mandatory, since i don't need to import my security software. -- juha From owner-ipsec@lists.tislabs.com Mon Mar 29 09:35:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29023; Mon, 29 Mar 1999 09:35:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16382 Mon, 29 Mar 1999 09:37:17 -0500 (EST) Message-ID: <36FF91DF.662FE959@nt.com> Date: Mon, 29 Mar 1999 09:44:47 -0500 From: "Marcus Leech" X-Mailer: Mozilla 4.5 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Quick Mode and resistance to related-key cryptanalysis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A historical point: Was resistance to related-key cryptanalysis an explicit design goal for Quick Mode, or did it just happen by accident? Just curious. -- ---------------------------------------------------------------------- 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@lists.tislabs.com Mon Mar 29 09:37:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29083; Mon, 29 Mar 1999 09:37:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16499 Mon, 29 Mar 1999 09:56:56 -0500 (EST) Date: Mon, 29 Mar 1999 10:19:41 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: 3DES with 40-bit key? In-Reply-To: <36FF1DC0.8909FC6F@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 29 Mar 1999, Ari Huttunen wrote: > ...the only MUST IMPLEMENT algorithm for ISAKMP > and IPSEC is 3DES, the issue of what to do with > export control rises. So, assume that export > control limits the key length to 40 bits. How > would I specify and negotiate this with IKE? You can't. Even in the days when the MUST algorithm was 1DES, the key was 56 bits, not 40. 3DES's key length is fixed at 168 bits. IPSEC has never had any officially-defined provision for doing anything as weak as 40-bit keys; the IETF has fairly consistently taken the position that specifications for network security must not be watered down to please oppressive governments. You cannot build a standard-conforming IPSEC implementation which restricts keys to 40 bits (or, after the pending changes, 56 bits). It's not possible. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Mon Mar 29 09:38:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29138; Mon, 29 Mar 1999 09:38:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16444 Mon, 29 Mar 1999 09:48:49 -0500 (EST) Message-Id: <199903291512.JAA09482@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Ari Huttunen cc: ipsec@lists.tislabs.com, carney@securecomputing.com Subject: Re: 3DES with 40-bit key? In-reply-to: Your message of "Mon, 29 Mar 1999 13:46:56 +0300." <36FF5A20.5D0D8DE8@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Mar 1999 09:12:29 -0600 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hmmm, I don't remember the outcome of the "show of hands" vote to drop Single DES from the "Must" classification. I do remember that 3DES was selected as the "Must" of choice for a stronger encryption algorithm. As for export concerns, if it was me, I would implement both DES and 3DES (at a minimum) and only enable 3DES in the US/CAN version. It was a pretty straightforward outcome of making 3DES a "Must" that US companies would be hamstrung in that we would be unable to export a compliant ISAKMP/IKE/IPSEC implementation. Regards, Michael Carney - Secure Computing Corporation. From owner-ipsec@lists.tislabs.com Mon Mar 29 09:43:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29346; Mon, 29 Mar 1999 09:43:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16375 Mon, 29 Mar 1999 09:37:02 -0500 (EST) Date: Mon, 29 Mar 1999 09:59:59 -0500 Message-Id: <199903291459.JAA07578@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ari.Huttunen@lmf.ericsson.se Cc: ipsec@lists.tislabs.com Subject: Re: 3DES with 40-bit key? References: <36FF1DC0.8909FC6F@lmf.ericsson.se> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Ari" == Ari Huttunen writes: Ari> Hi, Many of you will think this issue is braindead. I Ari> agree. However, as I understand that from now on the only MUST Ari> IMPLEMENT algorithm for ISAKMP and IPSEC is 3DES, the issue of Ari> what to do with export control rises. So, assume that export Ari> control limits the key length to 40 bits. How would I specify Ari> and negotiate this with IKE? Are you talking about US export controls? The 40-bit limit is no longer in effect. Of course, the current limit is 56 bits... :-( paul From owner-ipsec@lists.tislabs.com Mon Mar 29 09:52:02 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29697; Mon, 29 Mar 1999 09:52:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16563 Mon, 29 Mar 1999 10:14:11 -0500 (EST) Date: Mon, 29 Mar 1999 07:34:34 -0800 From: jim@mentat.com (Jim Gillogly) Message-Id: <199903291534.HAA29218@zendia.mentat.com> To: ipsec@lists.tislabs.com Subject: Re: 3DES with 40-bit key? X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari Huttunen wrote: > So, which algorithm would you recommend for an export hampered > IPSec box to implement? Remember that it will have to be interoperable > with the other routers out there, which by now will only have to support > 3DES If you need to interoperate with a router that uses real 3DES, you need real 3DES. If it hands you a 192-bit key and you try to send it data encrypted with only 40 bits of that, it'll fail the authentication. I don't see that there's an issue. If you don't like the fact that you can't legally export it from the U.S., see your Congressman: there's a bill in process that offers export relief if someone outside the US and Canada is selling the same sort of thing. > > By the way, the "weak ciphers for US export" limit has been raised to > > 56 bits with a BXA review. > > I wonder... If I remember correctly what the Wassenaar agreement > stated, 56 bits was allowed for some uses, while still not allowed > for all possible uses. You can use 56 bits now for anything you used to be able to use 40 bits for, again assuming you've gotten the clearance from BXA. Of course, there are still countries for which you can't get a license. You can use stronger crypto for certain customers -- primarily fixed targets, mostly in the financial arena. See http://www.bxa.doc.gov/Encryption/EncrypolicyUpdate.htm . Jim Gillogly From owner-ipsec@lists.tislabs.com Mon Mar 29 10:08:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00431; Mon, 29 Mar 1999 10:08:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16542 Mon, 29 Mar 1999 10:10:37 -0500 (EST) Date: Mon, 29 Mar 1999 10:33:23 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: 3DES with 40-bit key? In-Reply-To: <36FF5A20.5D0D8DE8@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 29 Mar 1999, Ari Huttunen wrote: > BTW, I find it hard to imagine someone implementing 3DES but not > implementing DES. The Linux FreeS/WAN project has done just that. (Well, there is a DES implementation down inside, but it's no longer accessible without going in and tinkering with the source.) Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Mon Mar 29 11:08:35 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00978; Mon, 29 Mar 1999 11:08:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16761 Mon, 29 Mar 1999 11:21:15 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Mon, 29 Mar 1999 09:43:48 -0700 From: "Tolga Acar" To: , Cc: "Bob Jueneman" Subject: Re: 3DES with 40-bit key? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA16758 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>> Ari Huttunen 3/28/99 23:29:20 >>> >Many of you will think this issue is braindead. >I agree. However, as I understand that from now >on the only MUST IMPLEMENT algorithm for ISAKMP >and IPSEC is 3DES, the issue of what to do with >export control rises. So, assume that export >control limits the key length to 40 bits. How >would I specify and negotiate this with IKE? > >Ari Huttunen > >It's about authentication between peers, >the rest is IKE. If i'm not mistaken, there are fine prints in the US export regulations regarding exporting cryptography products. That is, the key size MUST be treated together with its intended and allowed usage. That assumes that whatever product you're trying to export must present "sufficient" evidence to government that it enforces key types/algorithms/usages in accordance with the US export regulations. Thus, for signature keys, there is no key size limit. For Encrypt-for-authentication keys, there is no size limit. For key management purposes, symmetric keys are restricted to 128 bits, and asymmetric keys are restricted to 1024 bits. For all other general purpose data encryption, you have 56-bit symmetric and 512-bit asymmetric keys. PLEASE DOUBLE CHECK THESE NUMBERS. They are by no means approved numbers by any institution or anyone. Then, I fail to understand the consideration on the 56-bit restriction on 3DES where the sole purpose of using it is authentication. Similarly, if the intended purpose is key management, 128 bits is allowed. Think in terms of double-key Triple DES - not a standard yet, but it could very well promoted to be. That is upto the company that tries to export its product. It is not that the US export regulations PROHIBIT such uses even with long keys, it is the product exporter that must show evidence that it is playing by the rules and enforcing policies. One such example is NICI - Novell International Cryptographic Infrastructure. - Tolga From owner-ipsec@lists.tislabs.com Mon Mar 29 11:16:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01049; Mon, 29 Mar 1999 11:16:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16780 Mon, 29 Mar 1999 11:24:42 -0500 (EST) Message-Id: <199903291624.LAA16776@lists.tislabs.com> From: "Costantini, Frank " To: ipsec@lists.tislabs.com Subject: IPSec for IP Telephony Date: Mon, 29 Mar 1999 11:16:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is the intent of the IPSEC community that secure IP Telephony applications utilize 3DES in CBC mode for encryption? Considering the extreme sensitivity that IP Telephony has for latency, CBC mode is not a good choice for a cryptographic mode for that application. Has a stream-cipher mode of operation for delay-sensitive IPSEC applications been defined somewhere? Frank Costantini From owner-ipsec@lists.tislabs.com Mon Mar 29 11:21:08 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01096; Mon, 29 Mar 1999 11:21:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16899 Mon, 29 Mar 1999 11:43:39 -0500 (EST) Message-Id: <3.0.6.32.19990329085956.007a7890@module-two.rwthayer.com> X-Sender: rodney@module-two.rwthayer.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 29 Mar 1999 08:59:56 -0800 To: Juha Heinanen , Ari Huttunen From: Rodney Thayer Subject: Re: 3DES with 40-bit key? Cc: ipsec@lists.tislabs.com In-Reply-To: <14079.35065.42637.412376@lohi.eng.telia.fi> References: <36FF5A20.5D0D8DE8@lmf.ericsson.se> <199903290703.XAA29069@zendia.mentat.com> <36FF5A20.5D0D8DE8@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:06 PM 3/29/99 +0300, Juha Heinanen wrote: >Ari Huttunen writes: > ... (Ignoring the nontechnical issues, like Wassenar and how you plan on getting 40bit watered-down 3des export approved...) If you use proper negotiated values in IKE, then you are shipping a "conforming" implementation in that you're being clear about what you're negotiation. In other words, you could, for example, ship a product that used one of the private values for your own (hacked, nonstandard, non-safe) 40-bit 3des variant. It would not interoperate with others, but it would honestly represent itself as to what ciphers it was or was not using. If you don't implement the must-to-implement IPsec cipher(s) as defined at the time of shipment (des, 3des, des-x, whatever), then of course you'd not be able to interoperate with someone who DID implement the must-to-implement set. So you'd get away with this in the cold cruel commercial world, where people often purchase matched sets of boxes from one single vendor. From owner-ipsec@lists.tislabs.com Mon Mar 29 11:51:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA01277; Mon, 29 Mar 1999 11:51:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17023 Mon, 29 Mar 1999 12:06:06 -0500 (EST) Message-Id: <36FFB84E.C82C4628@mitel.com> Date: Mon, 29 Mar 1999 12:28:46 -0500 From: Dave Perks Organization: Mitel Corporation X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en Mime-Version: 1.0 To: IP Security List Subject: Re: 3DES with 40-bit key? References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > You cannot build a standard-conforming IPSEC implementation which > restricts keys to 40 bits (or, after the pending changes, 56 bits). It's > not possible. Is something like http://www.counterpane.com/low-entropy.html an option? I quote the abstract w/o permission: ABSTRACT: We introduce the notion of key stretching, a mechanism to convert short s-bit keys into longer keys, such that the complexity required to brute-force search a (s+t)-bit keyspace is the same as the time required to brute-force search a s-bit key stretched by t bits. -- The opinions expressed in this message are my personal opinion and in no way reflect the views of my employer. Søren Kierkegaard says "Life can only be understood backwards; but it must be lived forwards." From owner-ipsec@lists.tislabs.com Mon Mar 29 12:08:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01461; Mon, 29 Mar 1999 12:08:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17541 Mon, 29 Mar 1999 12:43:11 -0500 (EST) Message-ID: <36FFC13A.55A90C4F@sympatico.ca> Date: Mon, 29 Mar 1999 13:06:50 -0500 From: Sandy Harris X-Mailer: Mozilla 4.5 [en]C-SYMPA (Win95; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: 3DES with 40-bit key? References: <199903291534.HAA29218@zendia.mentat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jim Gillogly wrote: > If you don't like the fact that you can't legally export it from the > U.S., see your Congressman: . . . Also check out GILC campaign to change Wassenaar: http://www.gilc.org/crypto/wassenaar > > > By the way, the "weak ciphers for US export" limit has been raised to > > > 56 bits with a BXA review. > > > > I wonder... If I remember correctly what the Wassenaar agreement > > stated, 56 bits was allowed for some uses, while still not allowed > > for all possible uses. > > You can use 56 bits now for anything you used to be able to use > 40 bits for, again assuming you've gotten the clearance from BXA. And 64 bits for mass-market software. The Canadian gov't's page on this: http://www.dfait-maeci.gc.ca/~eicb/notices/ser113-e.htm says (in point 13): > [This 64-bit restriction] will remain in effect for two years and > that the renewal of such controls for a successive period will require > the unanimous consent of the Wassenaar Arrangement Participating States. My guess would be this was a bone the US & others threw to countries like Canada & others who wanted Wassenaar chamged much more this round. Agree to 56/64 now and we'll review it in two years. Methinks we should all be in touch withour various governments to make certain this is not extended beyond the two years. From owner-ipsec@lists.tislabs.com Mon Mar 29 12:21:05 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01567; Mon, 29 Mar 1999 12:21:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17302 Mon, 29 Mar 1999 12:32:57 -0500 (EST) Date: Mon, 29 Mar 1999 12:56:09 -0500 Message-Id: <199903291756.MAA08203@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Frank.Costantini@ccmail.l-3com.com Cc: ipsec@lists.tislabs.com Subject: Re: IPSec for IP Telephony References: <199903291624.LAA16776@lists.tislabs.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Costantini," == Costantini, Frank <" > writes: Costantini,> Is the intent of the IPSEC community that secure IP Costantini,> Telephony applications utilize 3DES in CBC mode for Costantini,> encryption? Considering the extreme sensitivity that IP Costantini,> Telephony has for latency, CBC mode is not a good choice Costantini,> for a cryptographic mode for that application. Has a Costantini,> stream-cipher mode of operation for delay-sensitive Costantini,> IPSEC applications been defined somewhere? I don't understand the point. Encrypting a packet will add some latency, but I don't see any reason to prefer a stream cypher over a block cypher when doing packet oriented processing. Sure, 3DES may be slow in some implementations, but that's an implementation matter, not a fundamental property. If you were transmitting byte stream data, things might (or might not) be different, but we're talking IP packets... We've been doing some latency measurements and the numbers come out well below what would be an issue for VoIP (or for that matter, way below the wire delay for T1 never mind slower stuff). paul From owner-ipsec@lists.tislabs.com Mon Mar 29 12:55:41 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA01958; Mon, 29 Mar 1999 12:55:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA17760 Mon, 29 Mar 1999 13:25:24 -0500 (EST) Message-Id: <2.2.32.19990329184814.00f65de4@mailhost.hq.freegate.com> X-Sender: jtardo@mailhost.hq.freegate.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Mar 1999 10:48:14 -0800 To: Ari Huttunen , ipsec@lists.tislabs.com From: Joe Tardo Subject: Re: 3DES with 40-bit key? Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:29 AM 3/29/99 +0300, Ari Huttunen wrote: >Hi, > >Many of you will think this issue is braindead. >I agree. However, as I understand that from now >on the only MUST IMPLEMENT algorithm for ISAKMP >and IPSEC is 3DES, the issue of what to do with >export control rises. So, assume that export >control limits the key length to 40 bits. How >would I specify and negotiate this with IKE? > >Ari Huttunen Well, assuming you mean *export from the U.S.* as I read the regulations it's ok to ship 56-bit anything. So why not just use 3DES with the three identical keys, which is identical to 56-bit DES? Unappealing, and I'm not (necessarily) advocating this, but why is it any different than, say, 'salted' RC4 schemes which have been approved for export for years? These use the full 128-bit key size but reveal 88 bits in the protocol. --Joe From owner-ipsec@lists.tislabs.com Mon Mar 29 14:05:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02448; Mon, 29 Mar 1999 14:05:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18014 Mon, 29 Mar 1999 14:24:34 -0500 (EST) Message-Id: <199903291924.OAA18010@lists.tislabs.com> From: "Costantini, Frank " To: ipsec@lists.tislabs.com Subject: RE: IPSec for IP Telephony Date: Mon, 29 Mar 1999 14:37:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, The significant advantage of a stream cipher, operating in OFB or counter mode, over a CBC mode is that in a stream-cipher the keystream can be calculated in advance of the voice/video data being available from the codec. This essentially eliminates the 3DES (or other codebook) processing time from the latency equation (except for the exclusive-OR of keystream onto the data, which is essentially zero time). Since latency is a cumulative phenomenon, it seems such a simple cryptographic mode alternative would have some benefit without any negative consequences. If an implementer is trying to make a low-cost, IPSec-compatible telephone using only a low-end DSP, using this mode may reduce round-trip latency by 10 msec or so. While this may not seen like much, every little bit helps, and the savings essentially come for free. Frank Costantini Costantini,> Is the intent of the IPSEC community that secure IP Costantini,> Telephony applications utilize 3DES in CBC mode for Costantini,> encryption? Considering the extreme sensitivity that IP Costantini,> Telephony has for latency, CBC mode is not a good choice Costantini,> for a cryptographic mode for that application. Has a Costantini,> stream-cipher mode of operation for delay-sensitive Costantini,> IPSEC applications been defined somewhere? I don't understand the point. Encrypting a packet will add some latency, but I don't see any reason to prefer a stream cypher over a block cypher when doing packet oriented processing. Sure, 3DES may be slow in some implementations, but that's an implementation matter, not a fundamental property. If you were transmitting byte stream data, things might (or might not) be different, but we're talking IP packets... We've been doing some latency measurements and the numbers come out well below what would be an issue for VoIP (or for that matter, way below the wire delay for T1 never mind slower stuff). paul From owner-ipsec@lists.tislabs.com Mon Mar 29 14:12:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02522; Mon, 29 Mar 1999 14:12:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18053 Mon, 29 Mar 1999 14:29:24 -0500 (EST) Date: Mon, 29 Mar 1999 14:52:40 -0500 Message-Id: <199903291952.OAA08279@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: jtardo@freegate.com Cc: ipsec@lists.tislabs.com Subject: Re: 3DES with 40-bit key? References: <2.2.32.19990329184814.00f65de4@mailhost.hq.freegate.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Joe" == Joe Tardo writes: Joe> At 09:29 AM 3/29/99 +0300, Ari Huttunen wrote: >> Hi, >> >> Many of you will think this issue is braindead. I agree. However, >> as I understand that from now on the only MUST IMPLEMENT algorithm >> for ISAKMP and IPSEC is 3DES, the issue of what to do with export >> control rises. So, assume that export control limits the key >> length to 40 bits. How would I specify and negotiate this with >> IKE? >> >> Ari Huttunen Joe> Well, assuming you mean *export from the U.S.* as I read the Joe> regulations it's ok to ship 56-bit anything. Joe> So why not just use 3DES with the three identical keys, which is Joe> identical to 56-bit DES? Of course, that would just be DES. Calling it "triple DES" sounds like a false flag exercise. You can't do that, anyway, unless you do manual keying. If you want 56 bit keys, you need to implement DES, and you can only talk to other people if they are willing to implement DES. paul From owner-ipsec@lists.tislabs.com Mon Mar 29 14:29:29 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA02704; Mon, 29 Mar 1999 14:29:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18135 Mon, 29 Mar 1999 14:53:22 -0500 (EST) Message-ID: <36FFDFBA.25D9D234@sympatico.ca> Date: Mon, 29 Mar 1999 15:16:58 -0500 From: Sandy Harris X-Mailer: Mozilla 4.5 [en]C-SYMPA (Win95; U) X-Accept-Language: en,fr-CA MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: 3DES with 40-bit key? References: <2.2.32.19990329184814.00f65de4@mailhost.hq.freegate.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe Tardo wrote: > So why not just use 3DES with the three identical keys, which is identical > to 56-bit DES? RFC 2451 does not allow that. For IPSEC, 3DES has 3 different keys. They're right, too. Your suggestion gives the worst of both worlds: the proven insecurity of single DES with the overheads of 3DES. For details, see the (expired) draft: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-des3-00.txt > Unappealing, and I'm not (necessarily) advocating this, but why is it any > different than, say, 'salted' RC4 schemes which have been approved for > export for years? These use the full 128-bit key size but reveal 88 bits in > the protocol. It isn't any different. There are lots of ways to weaken ciphers. The US and other governments will be happy with any weakening that lets them break the ciphers. For the arguments on why not to do this for the Internet, see RFC 1984. For free code that implements IPSEC with 3DES see either of: http://www.xs4all.nl/~freeswan for Linux http://www.kame.net for *BSD, from Japan I know of no export restrictions on either of these. From owner-ipsec@lists.tislabs.com Mon Mar 29 16:53:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04384; Mon, 29 Mar 1999 16:53:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19013 Mon, 29 Mar 1999 17:28:55 -0500 (EST) Message-Id: <199903292228.RAA19009@lists.tislabs.com> From: "Costantini, Frank " To: ipsec@lists.tislabs.com Subject: RE: IPSec for IP Telephony Date: Mon, 29 Mar 1999 17:48:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk paul>Sure, but I've yet to see a DES implementation so poor that it added paul>anywhere near 10 ms to the latency, especially for the sort of packet paul>sizes you're likely to see for this application. paul> paul>Also, any compute-in-advance approaches only help under light load, paul>and do nothing for you under high load. paul> paul> paul In the low-end IPSec telephone terminal application I described, the speech load is constant, and a properly designed system would always be able to precompute the keystream in advance of the voice codec having the data available. For example, every 20 msec, on a H/W interrupt basis, the CPU performs a vocoding analysis operation, encrypts the resulting packet (or portion thereof) with precomputed Tx keystream and queues it for output, decrypts the incoming packet using precomputed Rx keystream, synthesizes the received voice, and calculates the two new keystream values for the next packet. The remaining CPU time until the next 20 msec interrupt is then available for management/supervisory functions. Also note that the round trip latency figure I quoted includes four instantiations of 3DES (#1 Tx -> #2 Rx -> #2 Tx -> #1 Rx) on a low-end, low-cost DSP (DSP because of the need for a voice codec function in an IP phone). Using counter mode synchronization allows precomputation of the receive keystream as well as the transmit keystream. I admit that for a router or high-end device, this issue is a "don't care". However, for internet telephony to take off, I think low-end, mass-market, inexpensive (less than $50 retail), desktop IP terminals will be necessary. Frank From owner-ipsec@lists.tislabs.com Mon Mar 29 16:54:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04416; Mon, 29 Mar 1999 16:54:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18985 Mon, 29 Mar 1999 17:18:33 -0500 (EST) Message-ID: <70C20C1647EBD11183F800805FA67B435F2EA5@vpnet.com> From: Gary Hines To: ipsec@lists.tislabs.com, "'jim@mentat.com'" Subject: RE: 3DES with 40-bit key? Date: Mon, 29 Mar 1999 14:40:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How do I get off this list? > ---------- > From: jim@mentat.com[SMTP:jim@mentat.com] > Sent: Sunday, March 28, 1999 11:03 PM > To: ipsec@lists.tislabs.com > Subject: Re: 3DES with 40-bit key? > > [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. > There is no need to resubscribe, if you are on the list, you will remain > on it. Just begin sending posts, and any administrative requests to > lists.tislabs.com as of now. List mail to tis.com will cease to be > delivered as of March 26, 1999. ] > > Ari Huttunen wrote: > > > Many of you will think this issue is braindead. > > I agree. However, as I understand that from now > > on the only MUST IMPLEMENT algorithm for ISAKMP > > and IPSEC is 3DES, the issue of what to do with > > export control rises. So, assume that export > > control limits the key length to 40 bits. How > > would I specify and negotiate this with IKE? > > I wouldn't say it's a braindead idea -- just that it's wrong. 3DES is > defined in RFC 2451 as having a 192-bit key; 168 bits participate in > the key schedule. The key length is not negotiable for this cipher. > If you were to do the equivalent of the CDMF transform to create a > DES-like cipher with 40 bits of strength, it wouldn't be DES; > similarly, a 40-bit version of 3DES would not be 3DES, and you would > not have implemented this cipher, so you would not have satisfied any > MUST IMPLEMENT clause. > > If you did something like this and tried to pass it off as a conforming > IPSec implementation, it would be fraudulent. If you can't get export > licenses for the algorithms you want, then you can't export them. > Simple as that. > > By the way, the "weak ciphers for US export" limit has been raised to > 56 bits with a BXA review. > > Jim Gillogly > From owner-ipsec@lists.tislabs.com Mon Mar 29 16:58:39 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04506; Mon, 29 Mar 1999 16:58:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19041 Mon, 29 Mar 1999 17:33:38 -0500 (EST) Message-ID: <4B01F81CE2B1D2119A0D006097BA9D1E0969C0@mailman.hifn.com> From: Robert Friend To: "'Sunil.Vallamkonda'" Cc: ipsec@lists.tislabs.com Subject: RE: info request Date: Mon, 29 Mar 1999 15:02:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Sunil, Hi/fn provides IPSec, IPPCP, and IKE software and hardware solutions. Regards, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Robert C. Friend Hi/fn Applications Engineering 5973 Avenida Encinas, Suite 110 voice: (760) 827-4542 Carlsbad, CA 92008 FAX: (760) 827-4577 email: rfriend@hifn.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -----Original Message----- > From: Sunil.Vallamkonda [SMTP:sunil@siara.com] > Sent: Thursday, March 25, 1999 5:16 PM > To: ipsec@lists.tislabs.com > Subject: info request > > [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. > There is no need to resubscribe, if you are on the list, you will remain > on it. Just begin sending posts, and any administrative requests to > lists.tislabs.com as of now. List mail to tis.com will cease to be > delivered as of March 26, 1999. ] > > Hello, > > > I am looking for recommendations on vendors with product offering for > IPSec/IKE software toolkit/protocol suites. > Any suggestions/pointers is welcome. > > Thx. > Sunil. > From owner-ipsec@lists.tislabs.com Mon Mar 29 17:09:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA04656; Mon, 29 Mar 1999 17:09:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19076 Mon, 29 Mar 1999 17:44:29 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199903292228.RAA19009@lists.tislabs.com> Date: Mon, 29 Mar 1999 18:10:25 -0500 To: "Costantini, Frank " From: Stephen Kent Subject: RE: IPSec for IP Telephony Cc: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Frank, We have had a number of other, optional, algorithms defined for IPsec. A stream cipher would be fine, so long as it carries an IV to deal with dropped or re-ordered packets. Also, note that ESP usually employs authentication, in the form of HMAC, which would introduce latency as well. if one omits authentication, and uses a stream cipher of the sort you describe, than an attacker could modify packets with complete control, which might be a concern. Steve From owner-ipsec@lists.tislabs.com Mon Mar 29 19:24:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA10066; Mon, 29 Mar 1999 19:24:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA19449 Mon, 29 Mar 1999 19:50:31 -0500 (EST) Date: Mon, 29 Mar 1999 20:13:14 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: 3DES with 40-bit key? In-Reply-To: <36FFB84E.C82C4628@mitel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 29 Mar 1999, Dave Perks wrote: > Is something like http://www.counterpane.com/low-entropy.html an option? > I quote the abstract w/o permission: > > ABSTRACT: We introduce the notion of key stretching, a mechanism to > convert short s-bit keys into longer keys... Fortunately (unfortunately?), the IKE mechanism for IPSEC key negotiation is completely defined and does not include any such chicanery. When it keys 3DES, it does it with 168 bits, not with 40 "stretched" to 168. You can't interoperate with it without using an honest 168 bits. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Tue Mar 30 01:35:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA02080; Tue, 30 Mar 1999 01:35:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA20379 Tue, 30 Mar 1999 01:55:51 -0500 (EST) Message-ID: From: Scott Cadzow To: "'Stephen Kent'" , "Costantini, Frank " Cc: ipsec@lists.tislabs.com Subject: RE: IPSec for IP Telephony Date: Tue, 30 Mar 1999 09:20:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Note that most digital radio telephone systems (DECT, GSM, TETRA) use streaming ciphers for link encryption, the analysis of each showing that block ciphers by having potential to induce delay are unacceptable to maintain QoS. If we extend the TDMA models of such systems to general packet mode speech then I believe the same conclusions will be reached - stream cipher is preferred. The derivation of a Time Variant Parameter is however for further study in IP telephony. Regards, Scott -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, March 30, 1999 1:10 AM To: Costantini, Frank Cc: ipsec@lists.tislabs.com Subject: RE: IPSec for IP Telephony Frank, We have had a number of other, optional, algorithms defined for IPsec. A stream cipher would be fine, so long as it carries an IV to deal with dropped or re-ordered packets. Also, note that ESP usually employs authentication, in the form of HMAC, which would introduce latency as well. if one omits authentication, and uses a stream cipher of the sort you describe, than an attacker could modify packets with complete control, which might be a concern. Steve From owner-ipsec@lists.tislabs.com Tue Mar 30 01:35:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA02090; Tue, 30 Mar 1999 01:35:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA20320 Tue, 30 Mar 1999 01:30:47 -0500 (EST) Message-Id: <3.0.1.32.19990330122918.00690b10@172.16.1.10> X-Sender: srinu@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 30 Mar 1999 12:29:18 +0500 To: ipsec@lists.tislabs.com From: "S. B. Kulkarni" Subject: Commit Bit Processing Cc: skelly@redcreek.com, rpereira@TimeStep.com, kivinen@ssh.fi, tjenkins@TimeStep.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have some doubts regarding processing of commit is concern, * Can the commit bit be set in any of the phases, I think some implementaions send INVALID_FLAG if it is set in phase-I. * CONNECT notify, is it now treated as one of the Quick mode exchange ? and When sending CONNECT notify should we use running IV of the quick mode or calculate new IV ? if it is treated as part of quick mode exchange then we should use running of the Quick mode. * Can the initiator set the commit bit in case of Quick mode, because what RFC says is, who ever sets the commit bit should send the CONNECT notify, and there is no point in sending the CONNECT notify along with the third message of quick mode. Thank You - Srinu ****************************************************************** S. B. Kulkarni Softeware Engineer 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@lists.tislabs.com Tue Mar 30 05:10:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA08673; Tue, 30 Mar 1999 05:10:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA21051 Tue, 30 Mar 1999 05:11:05 -0500 (EST) Message-Id: <3700A80D.11CF7A4B@telematics.com> Date: Tue, 30 Mar 1999 11:31:41 +0100 From: Anthony Walwyn Organization: ECI Telecom X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4m) Mime-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IPSec IP Telephony:End to End or Segment Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I've a question which I hope the experts on this list can answer/give their opinion. With respect to IP Telephony, should security be end-to-end or does it make sense to have it on just one segment, eg between two IP Telephony Gateways. Phone--PSTN--IPGW--IP Network--IPGW--PSTN-Phone If security is only implemented between the Gateways is the security risk unacceptable ?? If the phones were Internet-Phones, security could be implemented end-to-end using IPSec, but what happens if one end is an Internet Phone and one end is a normal PSTN Phone ? -- Anthony Walwyn Title: Senior Systems Engineer ECI Telecom, UK DCME Development, Voice: +44(0)1256 388065 ISIS House, Reading Road, Chineham Fax : +44(0)1256 388142 Basingstoke, Hampshire UK RG24 8TW Email: anthony.walwyn@telematics.com From owner-ipsec@lists.tislabs.com Tue Mar 30 07:08:42 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA09745; Tue, 30 Mar 1999 07:08:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA21451 Tue, 30 Mar 1999 07:04:14 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 To: Scott Cadzow Cc: "'Stephen Kent'" , "Costantini, Frank " , ipsec@lists.tislabs.com Subject: Re: IPSec for IP Telephony Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Mar 1999 07:27:22 -0500 From: "Steven M. Bellovin" Message-Id: <19990330122732.93EAD41F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Scott Cadzow writ es: > Note that most digital radio telephone systems (DECT, GSM, TETRA) use > streaming ciphers for link encryption, the analysis of each showing that > block ciphers by having potential to induce delay are unacceptable to > maintain QoS. If we extend the TDMA models of such systems to general packet > mode speech then I believe the same conclusions will be reached - stream > cipher is preferred. The derivation of a Time Variant Parameter is however > for further study in IP telephony. The characteristics of such systems are very different. The ones I've looked at use strict bit timing to clock the stream cipher, for example. They aren't packet-oriented, and there are no problems with out-of-order delivery, duplicate packets, etc. We're in a packet environment; our answers may be very different. That said, it isn't clear to me that IPSEC is the right answer in any event -- the overhead is high, relative to the very small packet size, and its strong protection properties interfere with header compression. Besides, the threat model is very, very different. We are dealing with very limited bandwidth on the access lines; our general answer doesn't seem to fit Internet telephony very well. From owner-ipsec@lists.tislabs.com Tue Mar 30 07:29:40 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10047; Tue, 30 Mar 1999 07:29:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA21575 Tue, 30 Mar 1999 07:58:55 -0500 (EST) Message-Id: <9191B3991E5DD2118B7F0008C7241AB501001A5B@PLCEX1.plc.com> From: "Chaffe, Tim" To: "'Anthony Walwyn'" , ipsec@lists.tislabs.com Subject: RE: IPSec IP Telephony:End to End or Segment Date: Tue, 30 Mar 1999 14:23:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's not an either/or it's situation dependent. Inside a corporate network it may not be necessary and the gateway does the work. (between two points of trust) In a public network, IPSEC from the end device may or may not be required, depending on user security needs. For the Internet Phone to normal PSTN Phone conversation the same applies. You either protect it for the IP part of the link or you don't. The voice part of the link continues as it always does. -----Original Message----- From: Anthony Walwyn [mailto:anthony.walwyn@telematics.com] Sent: 30 March 1999 11:32 To: ipsec@lists.tislabs.com Subject: IPSec IP Telephony:End to End or Segment Hi, I've a question which I hope the experts on this list can answer/give their opinion. With respect to IP Telephony, should security be end-to-end or does it make sense to have it on just one segment, eg between two IP Telephony Gateways. Phone--PSTN--IPGW--IP Network--IPGW--PSTN-Phone If security is only implemented between the Gateways is the security risk unacceptable ?? If the phones were Internet-Phones, security could be implemented end-to-end using IPSec, but what happens if one end is an Internet Phone and one end is a normal PSTN Phone ? -- Anthony Walwyn Title: Senior Systems Engineer ECI Telecom, UK DCME Development, Voice: +44(0)1256 388065 ISIS House, Reading Road, Chineham Fax : +44(0)1256 388142 Basingstoke, Hampshire UK RG24 8TW Email: anthony.walwyn@telematics.com From owner-ipsec@lists.tislabs.com Tue Mar 30 08:29:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10857; Tue, 30 Mar 1999 08:29:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA21724 Tue, 30 Mar 1999 08:31:48 -0500 (EST) Message-ID: <01BE7A82.C5AD2AF0.scottb@ktc.com> From: Scott Baldwin To: "'Gary Hines'" , "ipsec@lists.tislabs.com" , "'jim@mentat.com'" Subject: RE: 3DES with 40-bit key? Date: Tue, 30 Mar 1999 07:56:09 -0600 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes me too. I don't need these e-mails clogging up my mailbox right now. -----Original Message----- From: Gary Hines [SMTP:GHines@vpnet.com] Sent: Monday, March 29, 1999 4:41 PM To: ipsec@lists.tislabs.com; 'jim@mentat.com' Subject: RE: 3DES with 40-bit key? How do I get off this list? > ---------- > From: jim@mentat.com[SMTP:jim@mentat.com] > Sent: Sunday, March 28, 1999 11:03 PM > To: ipsec@lists.tislabs.com > Subject: Re: 3DES with 40-bit key? > > [ NOTICE! This list will be hosted at lists.tislabs.com as of March 26. > There is no need to resubscribe, if you are on the list, you will remain > on it. Just begin sending posts, and any administrative requests to > lists.tislabs.com as of now. List mail to tis.com will cease to be > delivered as of March 26, 1999. ] > > Ari Huttunen wrote: > > > Many of you will think this issue is braindead. > > I agree. However, as I understand that from now > > on the only MUST IMPLEMENT algorithm for ISAKMP > > and IPSEC is 3DES, the issue of what to do with > > export control rises. So, assume that export > > control limits the key length to 40 bits. How > > would I specify and negotiate this with IKE? > > I wouldn't say it's a braindead idea -- just that it's wrong. 3DES is > defined in RFC 2451 as having a 192-bit key; 168 bits participate in > the key schedule. The key length is not negotiable for this cipher. > If you were to do the equivalent of the CDMF transform to create a > DES-like cipher with 40 bits of strength, it wouldn't be DES; > similarly, a 40-bit version of 3DES would not be 3DES, and you would > not have implemented this cipher, so you would not have satisfied any > MUST IMPLEMENT clause. > > If you did something like this and tried to pass it off as a conforming > IPSec implementation, it would be fraudulent. If you can't get export > licenses for the algorithms you want, then you can't export them. > Simple as that. > > By the way, the "weak ciphers for US export" limit has been raised to > 56 bits with a BXA review. > > Jim Gillogly > From owner-ipsec@lists.tislabs.com Tue Mar 30 08:54:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11108; Tue, 30 Mar 1999 08:54:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21991 Tue, 30 Mar 1999 09:24:01 -0500 (EST) Date: Tue, 30 Mar 1999 09:46:41 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: IPSec IP Telephony:End to End or Segment In-Reply-To: <3700A80D.11CF7A4B@telematics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 30 Mar 1999, Anthony Walwyn wrote: > With respect to IP Telephony, should security be > end-to-end or does it make sense to have it on > just one segment, eg between two IP Telephony Gateways. Depends on what sort of threat you are trying to protect against. The PSTN is fairly secure against casual snooping, somewhat insecure (at the ends) against knowledgeable snoopers, and completely open to government agencies (and possibly others with plenty of cash). The only really strong security is end-to-end security, but weaker forms may still be useful, depending on circumstances. > Phone--PSTN--IPGW--IP Network--IPGW--PSTN-Phone > If security is only implemented between the Gateways > is the security risk unacceptable ?? Unacceptable to who, for what purpose? > If the phones were Internet-Phones, security could be > implemented end-to-end using IPSec, but what happens if > one end is an Internet Phone and one end is a normal PSTN Phone ? The "INSECURE!" light on your Internet Phone should light up. Henry Spencer henry@spsystems.net (henry@zoo.toronto.edu) From owner-ipsec@lists.tislabs.com Tue Mar 30 09:50:22 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA11552; Tue, 30 Mar 1999 09:50:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22235 Tue, 30 Mar 1999 10:09:27 -0500 (EST) Message-Id: <199903292253.AAA01321@waldorf.appli.se> To: Sandy Harris cc: ipsec@lists.tislabs.com Subject: Re: 3DES with 40-bit key? In-reply-to: Your message of "Mon, 29 Mar 1999 15:16:58 CDT." <36FFDFBA.25D9D234@sympatico.ca> Date: Tue, 30 Mar 1999 00:53:48 +0200 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Date: Mon, 29 Mar 1999 15:16:58 -0500 > From: Sandy Harris > > For free code that implements IPSEC with 3DES see either of: > > http://www.xs4all.nl/~freeswan for Linux > http://www.kame.net for *BSD, from Japan Of course do not forget http://www.openbsd.org, where you can find additional cryptographic transforms, like Blowfish, Cast and Skipjack. As for the initial question, Ari did not state from which country he wanted to export from. Some have understood it to be the US, others have guessed a Wassenar country. I did read up a bit on Wassenaar and found it not to be as bad as I initially been afraid of. Most cryptography software are actually exempt, by this general software note: ------------------------------------------------------------------------------ The Lists do not control "software" which is either: 1. Generally available to the public by being: a. Sold from stock at retail selling points without restriction, by means of: 1. Over-the-counter transactions; 2. Mail order transactions; or 3. Telephone call transactions; and b. Designed for installation by the user without further suhstantial support by the supplier; or 2. "In the public domain". --------------------------------------------------------------------------- The source is an OCR scan found on the net, http://www.jya.com/wa/walists.htm Even though the definition of "public domain" in there is rather vague, my personal opinion is that both BSD and GPL code is exempt from the Wassenaar agreement. Back to the subject, if I understand Ari's question right, it was: how do I provide no-stronger-than-N bits of protection if the only known transform to talk to other IKE's with are 3DES. My answer is along the line of another guy in the thread; by publishing 192-N bits of the key in a vendor defined NOTIFY STATUS message always sent out after every exchange, and going to your government and show them that you disclose the extra bits. Now, I don't particularily like this, given that the party you talk to might trust the actual keylengths, and send data it would not send at a lower security level. Maybe your government allows you to just log these extra bits in a write-only black-box memory of some sort, together with the SPIs. That'll at least protect your communication for the non-governmental bad guys. And the government can get at the extra bits when they need, with a warrant. The other ideas with using redundant patterns in the 3DES keys are simply impossible. The keys are never specified anywhere, they are computed with input from random data from both parties, there is no way of creating redundant key content. The only way to weaken the keys are to publish part of them. But first of all, I would ask you to question the specific governments position on cryptography export regulations. The more we are that question them, the better. Actually Ari, I thought you had your production in Finland, isn't it so? Or is it that your product does not fit the exemptions of the Wassennaar? I did not even find mentions of keylengths when I read it, but I just read here and there trying to see if I did illegal things, which I incidentally do not, as I interpret the rules (the biggest problem being, is the BSD license, a public domain license, as they view it? It's not what I call PD, but in their eyes it probably is). Niklas From owner-ipsec@lists.tislabs.com Tue Mar 30 09:52:37 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA11587; Tue, 30 Mar 1999 09:52:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22191 Tue, 30 Mar 1999 10:08:24 -0500 (EST) Message-Id: <199903300239.SAA20582@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: ipsec@lists.tislabs.com Subject: RSA claiming trademark on all uses of "RSA" to describe algorithm Date: Mon, 29 Mar 1999 18:39:09 -0800 From: John Gilmore Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > This is a stds-p1363 broadcast. See the IEEE P1363 web page > (http://grouper.ieee.org/groups/1363/) for more information, > including how to subscribe/unsubscribe. > -------------------------------------------------------------- > > Security Dynamics Technologies, Inc. has sent a letter to the P1363 > working group regarding trademark protection of the RSA name. The letter > is now available from our patents page > http://grouper.ieee.org/groups/1363/patents.html > or directly at > http://grouper.ieee.org/groups/1363/letters/SecurityDynamics.jpg Now that their patent is getting ready to expire (next fall), RSA is trying to crack down on anyone who refers to the use of the algorithm by calling it "RSA". They don't mind if you call it "type 1" or something else meaningless and irrelevant, though. This is a new low for a company known for self-serving legal bluster. You would think they'd prefer to have people mentioning their corporate name all over the place, but now that the algorithm has wide recognition, they seem to want to make sure that nobody *else* can say their product does RSA. Even if it does. If they can't keep you from competing, at least they want to prevent you from advertising that you compete. They aren't asking much... Perhaps we should have a little contest for what to call the RSA algorithm, given RSA's objection to calling a shovel a spade. ASR perhaps? Though ASS is tempting, I wouldn't want to gratuitously eliminate Ron Rivest's initial. SAR as in what a SARry company? RAS, to send a RASberry to the lawyers? "EFN" is rot13 of RSA, can we make up a good phrase that it's supposed to stand for? Electronic Freedom Now? (Well, after Oct 2000 anyway.) Extra Funny Name? Elegant Fraud Nixer? Embargoed For Now? STB is RSA+1 (as in IBM and HAL); any good phrases lurking in there? RAL are the first (rather than last) initials of the inventors. Then there's RRASLA, the first and last initials. There's always completely new names: "ExpoMax", "FactorThis!", "SuperSig", "RonFish", etc... John PS: The alternative, of course, is to ignore them and keep using the term "RSA". Let them prove to a court that they own the term, which was in use before they formed the company and which was created in the traditional scientific community naming convention (after the names of the inventors). Or intervene in their trademark filings, saying the term has wide use in the scientific and technical literature and that they're trying to inappropriately monopolize it to replace their expiring patent protection. Does anyone out there work for a company that would like to continue using the term "RSA" after you don't have to pay the company for the patent any more? (I'm sure if you continue to pay them, they'll be glad to let you keep using the word; but you might have other ideas.) Which would be cheaper? Having your lawyers write a few letters to trademark agencies in various countries now? Or negotiating with good old "How much you got?" RSA? From owner-ipsec@lists.tislabs.com Tue Mar 30 09:53:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA11602; Tue, 30 Mar 1999 09:53:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22194 Tue, 30 Mar 1999 10:08:26 -0500 (EST) Message-ID: <36FFD15D.30AA82A3@nortel.ca> Date: Mon, 29 Mar 1999 21:15:41 +0200 From: "Marcus Leech" Organization: Security Development X-Mailer: Mozilla 2.02 (X11; I; Linux 1.2.13 i486) MIME-Version: 1.0 To: Hilarie Orman CC: ipsec@lists.tislabs.com Subject: Re: Quick Mode and resistance to related-key cryptanalysis References: <199903292128.OAA04007@baskerville.CS.Arizona.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hilarie Orman wrote: > > What? In the generic sense, of course you shouldn't be able to relate > keys. Is there a specific definition of "related key cryptanalysis"? > > Hilarie Yes, I recall early on a discussion about simple transformations of existing keys in Quick Mode exchanges, it is exactly those simple, predictable key changes, that makes related-key cryptanalysis work. Granted, for many algorithms, related-key cryptanalysis is not particularly feasible, but for others, it's a concern. I'm not questioning that IKE Quick Mode *does* have the resistance property, only asking about whether it was a motivation. Just a curiosity thing. Related-key cryptanalysis relies on being able to either effect or predict a particular key-change (without actually knowing the keys), and using known or chosen plaintext, recover significant quantities of key bits. Suppose only that you knew that: K' = K+1 without actually knowing what the keys are. For certain algorithms, you can determine key bits using known or chosen plaintext, in concert with related-key "queries". Wagner/Schneier have a good paper on related-key cryptanalysis of various algorithms, including CAST, RC2, Biham-DES, and several others. -- ---------------------------------------------------------------------- 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@lists.tislabs.com Tue Mar 30 10:38:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12057; Tue, 30 Mar 1999 10:38:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA22397 Tue, 30 Mar 1999 10:46:06 -0500 (EST) Date: Tue, 30 Mar 1999 08:09:21 -0800 (PST) Message-Id: <199903301609.IAA06603@cayman-islands.isi.edu> From: Clifford Neuman To: gnu@toad.com CC: ipsec@lists.tislabs.com In-reply-to: <199903300239.SAA20582@toad.com> (message from John Gilmore on Mon, 29 Mar 1999 18:39:09 -0800) Subject: Re: RSA claiming trademark on all uses of "RSA" to describe algorithm Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Security Dynamics Technologies, Inc. has sent a letter to the P1363 > working group regarding trademark protection of the RSA name. Once we come up with the new phrase to refer to "the algorithm formerly known as RSA" (how bout TAFKAR), let's change all standards track documents to use the new name. Clifford Neuman From owner-ipsec@lists.tislabs.com Tue Mar 30 10:54:24 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12188; Tue, 30 Mar 1999 10:54:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22505 Tue, 30 Mar 1999 11:10:48 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 To: John Gilmore Cc: ipsec@lists.tislabs.com Subject: Re: RSA claiming trademark on all uses of "RSA" to describe algorithm Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Mar 1999 11:33:58 -0500 From: "Steven M. Bellovin" Message-Id: <19990330163407.9632441F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <199903300239.SAA20582@toad.com>, John Gilmore writes: > > PS: The alternative, of course, is to ignore them and keep using the > term "RSA". Let them prove to a court that they own the term, which > was in use before they formed the company and which was created in the > traditional scientific community naming convention (after the names of > the inventors). Or intervene in their trademark filings, saying the > term has wide use in the scientific and technical literature and that > they're trying to inappropriately monopolize it to replace their > expiring patent protection. If this is to be considered, we need a long list of scientific references from before the company was formed, right? From owner-ipsec@lists.tislabs.com Tue Mar 30 11:14:43 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA12412; Tue, 30 Mar 1999 11:14:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22571 Tue, 30 Mar 1999 11:28:39 -0500 (EST) Message-Id: <3.0.5.32.19990330115207.007ab890@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 30 Mar 1999 11:52:07 -0500 To: Henry Spencer , Dave Perks From: David Jablon Subject: Re: 3DES with 40-bit key? Cc: IP Security List In-Reply-To: References: <36FFB84E.C82C4628@mitel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 08:13 PM 3/29/99 -0500, Henry Spencer wrote: > On Mon, 29 Mar 1999, Dave Perks wrote: >> Is something like http://www.counterpane.com/low-entropy.html an option? >> ABSTRACT: We introduce the notion of key stretching, a mechanism to >> convert short s-bit keys into longer keys... 1) Key stretching, a.k.a. an iterated hash, is an old and limited notion. UNIX's crypt(3) password format is an example, and illustrates why this kind of protection doesn't last long. 2) Key amplification is a much better way to negotiate an "honest 168 bit" key from a smaller key in a network protocol. 3) Henry is right that IKE was not designed to tolerate anything less than full size keys: > Fortunately (unfortunately?), the IKE mechanism for IPSEC key negotiation > is completely defined and does not include any such chicanery. When it > keys 3DES, it does it with 168 bits, not with 40 "stretched" to 168. You > can't interoperate with it without using an honest 168 bits. If you legitimately need to use smaller keys, you might consider an extension based on a key amplification method, like EKE. Papers are at: -- dpj From owner-ipsec@lists.tislabs.com Tue Mar 30 11:58:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA12951; Tue, 30 Mar 1999 11:58:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22799 Tue, 30 Mar 1999 11:59:40 -0500 (EST) Message-ID: <01BE7AA8.466FA990.bdoud@ire-ma.com> From: Bob Doud To: "'Scott Cadzow'" , "'Stephen Kent'" , "Costantini, Frank " Cc: "ipsec@lists.tislabs.com" Subject: RE: IPSec for IP Telephony Date: Tue, 30 Mar 1999 12:24:35 -0500 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, I think you would find that the main reason that digital radio systems use a stream cipher is not for latency reasons but rather for error propagation concerns. When you use a block cipher such as DES in either CBC or CFB mode, you cause a propagation of a single-bit channel error into 1 or two blocks worth of errors upon decryption. This would be totally unacceptable over a radio link where you tend to get spurious errors here and there. I know of at least one company who does digital radio with DES running in the OFB mode, which makes it essentially a stream cipher. Bob Doud IRE Secure Solutions, Inc. -----Original Message----- From: Scott Cadzow [SMTP:Scott.Cadzow@etsi.fr] Sent: Tuesday, March 30, 1999 2:20 AM To: 'Stephen Kent'; Costantini, Frank Cc: ipsec@lists.tislabs.com Subject: RE: IPSec for IP Telephony Note that most digital radio telephone systems (DECT, GSM, TETRA) use streaming ciphers for link encryption, the analysis of each showing that block ciphers by having potential to induce delay are unacceptable to maintain QoS. If we extend the TDMA models of such systems to general packet mode speech then I believe the same conclusions will be reached - stream cipher is preferred. The derivation of a Time Variant Parameter is however for further study in IP telephony. Regards, Scott -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, March 30, 1999 1:10 AM To: Costantini, Frank Cc: ipsec@lists.tislabs.com Subject: RE: IPSec for IP Telephony Frank, We have had a number of other, optional, algorithms defined for IPsec. A stream cipher would be fine, so long as it carries an IV to deal with dropped or re-ordered packets. Also, note that ESP usually employs authentication, in the form of HMAC, which would introduce latency as well. if one omits authentication, and uses a stream cipher of the sort you describe, than an attacker could modify packets with complete control, which might be a concern. Steve From owner-ipsec@lists.tislabs.com Tue Mar 30 12:52:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13648; Tue, 30 Mar 1999 12:52:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22932 Tue, 30 Mar 1999 12:29:47 -0500 (EST) Date: Tue, 30 Mar 1999 12:53:03 -0500 Message-Id: <199903301753.MAA01698@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: smb@research.att.com Cc: gnu@toad.com, ipsec@lists.tislabs.com Subject: Re: RSA claiming trademark on all uses of "RSA" to describe algorithm References: <19990330163407.9632441F16@SIGABA.research.att.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Steven" == Steven M Bellovin writes: Steven> In message <199903300239.SAA20582@toad.com>, John Gilmore Steven> writes: >> PS: The alternative, of course, is to ignore them and keep using >> the term "RSA". Let them prove to a court that they own the term, >> which was in use before they formed the company and which was >> created in the traditional scientific community naming convention >> (after the names of the inventors). Or intervene in their >> trademark filings, saying the term has wide use in the scientific >> and technical literature and that they're trying to >> inappropriately monopolize it to replace their expiring patent >> protection. Steven> If this is to be considered, we need a long list of Steven> scientific references from before the company was formed, Steven> right? ... which was in 1982 (see http://www.rsa.com/about/). Here's one. "The mathematics of public-key cryptography", Sci.Am, August 1979. paul From owner-ipsec@lists.tislabs.com Tue Mar 30 12:54:27 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13689; Tue, 30 Mar 1999 12:54:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22876 Tue, 30 Mar 1999 12:18:19 -0500 (EST) Message-ID: <37010CAC.773FFB50@siara.com> Date: Tue, 30 Mar 1999 09:41:00 -0800 From: "Sunil.Vallamkonda" X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IPSec - Mobile IP users... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I have some questions re: IPSec wrt. to mobile users. 1) Do mobile users need IKE and DHCP to use IPSec ? whats the general consensus by customers ? 2) (a) When mobile users login, they normally dial-in to a Gateway. Does IPSec need to be enabled and used between the Gateway and the mobile user ? If so, it is always in transport mode of IPSec ? (b) Does the mobile user need to have two IPSec Sessions - one to the Gateway and other to the end (destination/termination) host ? If so, can Sessions be of tunnel mode ? 3) Any documents/website/ pointers on information on IPSec wrt. mobile users ? Thank you. Sunil. From owner-ipsec@lists.tislabs.com Tue Mar 30 12:54:38 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA13697; Tue, 30 Mar 1999 12:54:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22903 Tue, 30 Mar 1999 12:26:53 -0500 (EST) Message-ID: <37010ED1.655EE5EC@lmf.ericsson.se> Date: Tue, 30 Mar 1999 20:50:09 +0300 From: Ari Huttunen Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: niklas@appli.se CC: sandy.harris@sympatico.ca, ipsec@lists.tislabs.com Subject: Re: 3DES with 40-bit key? References: <199903292253.AAA01321@waldorf.appli.se> Content-Type: multipart/mixed; boundary="------------4675F57DB850C34E606F77F5" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------4675F57DB850C34E606F77F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit niklas@appli.se wrote: > As for the initial question, Ari did not state from which country he > wanted to export from. Some have understood it to be the US, others > have guessed a Wassenar country. I did read up a bit on Wassenaar and > found it not to be as bad as I initially been afraid of. I'm sorry for accidentally omitting this piece of information. What I meant was indeed exporting from US. Because of internal reasons we're actually having coding and exporting from Finland as well as re-exporting from US. The US version gets tagged with strict export control rules. > Back to the subject, if I understand Ari's question right, it was: how > do I provide no-stronger-than-N bits of protection if the only known > transform to talk to other IKE's with are 3DES. My answer is along > the line of another guy in the thread; by publishing 192-N bits of the > key in a vendor defined NOTIFY STATUS message always sent out after > every exchange, and going to your government and show them that you > disclose the extra bits. Never! I'd rate that criminal behaviour... > Now, I don't particularily like this, given that the party you talk to > might trust the actual keylengths, and send data it would not send at > a lower security level. Maybe your government allows you to just log > these extra bits in a write-only black-box memory of some sort, > together with the SPIs. That'll at least protect your communication > for the non-governmental bad guys. And the government can get at the > extra bits when they need, with a warrant. Actually I was thinking more of only allowing single-DES in the re-exported version and variable keylength algorithms with the length limited to 56 bits. This might not be very interoperable, particularly if our our implementation is the responding side, but at least it's exactly what it claims to be. I would very much prefer an interoperable way to limit the keysize, something that is controllable with the security policy. The default policy might be to not allow watered down cryptography, and the customer would have to specifically allow it. Ari Huttunen --------------4675F57DB850C34E606F77F5 Content-Type: text/x-vcard; charset=us-ascii; name="Ari.Huttunen.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Ari Huttunen Content-Disposition: attachment; filename="Ari.Huttunen.vcf" begin:vcard n:Huttunen;Ari tel;fax:+358-9-2992634 tel;work:+358-9-2992472 x-mozilla-html:FALSE org:L M Ericsson;LMF/T/TK version:2.1 email;internet:Ari.Huttunen@lmf.ericsson.se title:Software Designer adr;quoted-printable:;;Oy L M Ericsson Ab=0D=0ATelecom R&D;;;02420 Jorvas;Finland x-mozilla-cpt:;-30024 fn:Ari Huttunen end:vcard --------------4675F57DB850C34E606F77F5-- From owner-ipsec@lists.tislabs.com Tue Mar 30 13:40:23 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA14119; Tue, 30 Mar 1999 13:40:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23010 Tue, 30 Mar 1999 12:50:19 -0500 (EST) From: John Ioannidis Date: Tue, 30 Mar 1999 13:13:37 -0500 (EST) Message-Id: <199903301813.NAA19859@bual.research.att.com> To: Ari.Huttunen@lmf.ericsson.se, niklas@appli.se Subject: Re: 3DES with 40-bit key? Cc: ipsec@lists.tislabs.com, sandy.harris@sympatico.ca Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Your problem is that you want to ship something which is not IPSEC (at least according to what we have agreed "IPSEC" is) and still call it this way. You will be neither the first nor the last person to sell something which does not match what it's supposed to be (lots of major companies do that and prosper anyway), but this is not a technical issue and I don't see why we should be involved. Don't expect the rest of the world to want to interoperate with you, though. /ji From owner-ipsec@lists.tislabs.com Tue Mar 30 13:43:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA14131; Tue, 30 Mar 1999 13:43:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23121 Tue, 30 Mar 1999 13:16:28 -0500 (EST) From: gseguridad@msc.es Message-ID: <14DBB32E0DC0D211816600A0C99DE52405591F@mmsc00001.msc.es> To: ipsec@lists.tislabs.com, gnu@toad.com Subject: RE: RSA claiming trademark on all uses of "RSA" to describe algor ithm Date: Tue, 30 Mar 1999 20:01:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi John, Do you think "words can create trust"? Luis Saiz P.D. Remember from this list a couple of years ago: "Crypto can't create trust. It merely automates the trust that already exists for other reasons." --John Gilmore P.D.2 What about NPQ (N=P*Q or Non Polynomic Quest)? P.D.3 What will be the status in the countries where RSA patent is not applicable, after Fall 2000 we will not use RSA name? From owner-ipsec@lists.tislabs.com Tue Mar 30 14:44:15 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14939; Tue, 30 Mar 1999 14:44:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23053 Tue, 30 Mar 1999 13:01:12 -0500 (EST) From: Pat.Calhoun@Eng.Sun.Com (Patrice Calhoun) Message-Id: <199903301823.KAA27794@hsmpka.eng.sun.com> Date: Tue, 30 Mar 1999 10:23:54 -0800 To: "Sunil.Vallamkonda" , Reply-To: Subject: Re: IPSec - Mobile IP users... X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At the expense of sounding anal, I would prefer that we not use the terminology mobile users. IPSec cannot really solve the mobility problem, but it can solve the "portability" problem. The distinction here is that the mobile infrastructure must provide smooth (or fast) hand-off, and this is not within IPSec's charter. If we are talking about Mobile IP, a mobile node must communicate with a foreign agent (or be co-located, which means that it acts as both a mobile node AND a foreign agent). You can view the foreign agent as some form of gateway. If we are talking about PPP links, then the dial-up user must dial into a PPP server, also known as a Network Access Server (NAS). PatC > >Hello, > > >I have some questions re: IPSec wrt. to mobile users. > >1) Do mobile users need IKE and DHCP to use IPSec ? whats the general >consensus > by customers ? > >2) (a) When mobile users login, they normally dial-in to a Gateway. >Does IPSec need to be > enabled and used between the Gateway and the mobile user ? If so, >it is always in transport mode of > IPSec ? > > (b) Does the mobile user need to have two IPSec Sessions - one to >the Gateway and other to the > end (destination/termination) host ? If so, can Sessions be >of tunnel mode ? > >3) Any documents/website/ pointers on information on IPSec wrt. mobile >users ? > >Thank you. > >Sunil. > > From owner-ipsec@lists.tislabs.com Tue Mar 30 15:14:57 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA15692; Tue, 30 Mar 1999 15:14:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23519 Tue, 30 Mar 1999 14:27:55 -0500 (EST) Date: Tue, 30 Mar 1999 14:51:07 -0500 Message-Id: <199903301951.OAA01747@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ari.Huttunen@lmf.ericsson.se Cc: ipsec@lists.tislabs.com Subject: Re: 3DES with 40-bit key? References: <199903292253.AAA01321@waldorf.appli.se> <37010ED1.655EE5EC@lmf.ericsson.se> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Ari" == Ari Huttunen writes: Ari> Actually I was thinking more of only allowing single-DES in the Ari> re-exported version and variable keylength algorithms with the Ari> length limited to 56 bits. This might not be very interoperable, Ari> particularly if our our implementation is the responding side, Ari> but at least it's exactly what it claims to be. Ari> I would very much prefer an interoperable way to limit the Ari> keysize, something that is controllable with the security Ari> policy. The default policy might be to not allow watered down Ari> cryptography, and the customer would have to specifically allow Ari> it. I think you're all set then. DES has 56 bit keys. With variable length key systems, you can select the keylength. So the protocol allows what you need. (There is no way to say "3DES with 56 bit keys"; if that's what you mean then you ask for it by saying "DES".) As for policy, management of policy isn't currently standardized and in any case is a local matter, so you can already have your implementation do what it needs to. paul From owner-ipsec@lists.tislabs.com Tue Mar 30 15:28:36 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA16048; Tue, 30 Mar 1999 15:28:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23670 Tue, 30 Mar 1999 15:11:48 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Tue, 30 Mar 1999 13:34:13 -0700 From: "Hilarie Orman" To: , Cc: Subject: Re: Quick Mode and resistance to related-key cryptanalysis Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA23667 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Certainly one designs keying protocols with the idea that keys should be as independent as possible, given the amount of effort available. There are multiple reasons for this, and related key cryptanalysis of particular ciphers is one of them. Hilarie >>> "Marcus Leech" 03/29/99 12:15PM >>> wrote that Hilarie Orman wrote: > > What? In the generic sense, of course you shouldn't be able to relate > keys. Is there a specific definition of "related key cryptanalysis"? Yes, I recall early on a discussion about simple transformations of existing keys in Quick Mode exchanges, it is exactly those simple, predictable key changes, that makes related-key cryptanalysis work. Granted, for many algorithms, related-key cryptanalysis is not particularly feasible, but for others, it's a concern. From owner-ipsec@lists.tislabs.com Tue Mar 30 16:46:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA20583; Tue, 30 Mar 1999 16:46:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24657 Tue, 30 Mar 1999 17:28:59 -0500 (EST) Message-ID: <37015660.EEA9E31A@cs.umass.edu> Date: Tue, 30 Mar 1999 17:55:28 -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 IP22) MIME-Version: 1.0 To: IP Security WG List CC: "Sunil.Vallamkonda" Subject: Re: IPsec/IKE products [Re: info request] References: <36FADFD5.20B99266@siara.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sunil.Vallamkonda writes: > I am looking for recommendations on vendors with product offering for > IPSec/IKE software toolkit/protocol suites. > Any suggestions/pointers is welcome. See Ted Ts'o's list of "companies which are implementing (or planning to implement) IPsec/ISAKMP": http://web.mit.edu/tytso/www/ipsec/companies.html -Lewis -- "Hackers can't and have not accessed our satellites. It is impossible for a hacker to get into the system." -- UK MoD spokesman, 1 Mar 1999 From owner-ipsec@lists.tislabs.com Tue Mar 30 16:50:07 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA20821; Tue, 30 Mar 1999 16:50:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24592 Tue, 30 Mar 1999 17:22:43 -0500 (EST) Message-ID: <370154E7.6A48D356@cs.umass.edu> Date: Tue, 30 Mar 1999 17:49:11 -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 IP22) MIME-Version: 1.0 To: IP Security WG List Subject: Re: IPSec for IP Telephony Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>> ----- The following addresses had permanent fatal errors ----- >>> This is in reply to <199903291624.LAA16776@lists.tislabs.com>. Frank Costantini writes: > Is the intent of the IPSEC community that secure IP Telephony > applications utilize 3DES in CBC mode for encryption? Considering the > extreme sensitivity that IP Telephony has for latency, CBC mode is not > a good choice for a cryptographic mode for that application. DES-CBC is the default encryption algorithm for the stopgap confidentiality service built into RTP [RFC 1889]. (The forthcoming revision of RTP, draft-ietf-avt-rtp-new-03, suggests use of IPsec services instead.) RFC 1889 says of DES-CBC: "This method is chosen because it has been demonstrated to be easy and practical to use in experimental audio and video tools in operation on the Internet." I don't know any details of the operational experience cited by the RFC, however. -Lewis -- "Hackers can't and have not accessed our satellites. It is impossible for a hacker to get into the system." -- UK MoD spokesman, 1 Mar 1999 From owner-ipsec@lists.tislabs.com Tue Mar 30 18:49:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA27251; Tue, 30 Mar 1999 18:49:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA24930 Tue, 30 Mar 1999 19:13:09 -0500 (EST) Message-ID: <37016EC7.9F07D053@cs.umass.edu> Date: Tue, 30 Mar 1999 19:39:35 -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 IP22) MIME-Version: 1.0 To: IP Security WG List CC: Lewis McCarthy Subject: Re: IPSec IP Telephony:End to End or Segment References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > The PSTN is fairly secure against casual snooping, somewhat insecure > (at the ends) against knowledgeable snoopers, and completely open to > government agencies (and possibly others with plenty of cash). I'm rather curious about what will happen when governments' legal wiretappability requirements for telecom carriers collide with RFC 1984 and IP telephony secured with end-to-end encryption. This assumes the latter technology becomes widely used, which isn't a foregone conclusion IMHO. How sturdy will the Danvers Doctrine be when (e.g.) the FBI wants CALEA-style call-content intercepts of IP telephony sessions? Maybe LEAs that can't resort to drastic methods will just be out of luck in the end. But in the interim I expect they will try to map their PSTN wiretap capabilities into the IPTEL model. -Lewis http://www.cs.umass.edu/~lmccarth I speak at most for myself, except where specifically stated otherwise. -- Vote for your favorite RFC at http://www.rfc-editor.org/voterfc.html From owner-ipsec@lists.tislabs.com Tue Mar 30 19:11:18 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA29766; Tue, 30 Mar 1999 19:11:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA25062 Tue, 30 Mar 1999 19:44:21 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 To: Lewis McCarthy Cc: IP Security WG List Subject: Re: IPSec IP Telephony:End to End or Segment Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Mar 1999 20:07:36 -0500 From: "Steven M. Bellovin" Message-Id: <19990331010741.360F641F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <37016EC7.9F07D053@cs.umass.edu>, Lewis McCarthy writes: > Henry Spencer writes: > > The PSTN is fairly secure against casual snooping, somewhat insecure > > (at the ends) against knowledgeable snoopers, and completely open to > > government agencies (and possibly others with plenty of cash). > > I'm rather curious about what will happen when governments' legal > wiretappability requirements for telecom carriers collide with RFC > 1984 and IP telephony secured with end-to-end encryption. CALEA does not prohibit end-to-end encryption, nor does it mandate any form of key escrow. *If* the end-to-end encryption is provided by the carrier -- say, if the carrier does the key distribution -- then there is an obligation (in the U.S., of course -- your government may vary) on the carrier to turn over the key. If the communicating parties set up their own session, say via something like PGPphone, CALEA doesn't apply. (Rather, the obligation on the carrier would be to turn over the ciphertext, and let Ft. Meade figure it out.) From owner-ipsec@lists.tislabs.com Tue Mar 30 22:31:51 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA23830; Tue, 30 Mar 1999 22:31:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA25688 Tue, 30 Mar 1999 23:20:59 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: rah@pop.sneaker.net Message-Id: In-Reply-To: <14DBB32E0DC0D211816600A0C99DE52405591F@mmsc00001.msc.es> Date: Tue, 30 Mar 1999 23:42:43 -0500 To: ipsec@lists.tislabs.com From: Robert Hettinga Subject: RE: RSA claiming trademark on all uses of "RSA" to describe algor ithm Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I changed my mind. :-). Since S and A don't own stock in it anymore, let's just call it R. ;-). Cheers, RAH ----------------- Robert A. Hettinga Philodox Financial Technology Evangelism 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From owner-ipsec@lists.tislabs.com Tue Mar 30 22:32:52 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA23919; Tue, 30 Mar 1999 22:32:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA25648 Tue, 30 Mar 1999 23:16:40 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: rah@pop.sneaker.net Message-Id: In-Reply-To: <199903300239.SAA20582@toad.com> Date: Tue, 30 Mar 1999 23:30:28 -0500 To: John Gilmore , ipsec@lists.tislabs.com From: Robert Hettinga Subject: Re: RSA claiming trademark on all uses of "RSA" to describe algorithm Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:39 PM -0500 on 3/29/99, John Gilmore wrote: > Embargoed For Now? I like this one... Cheers, RAH ----------------- Robert A. Hettinga Philodox Financial Technology Evangelism 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' From owner-ipsec@lists.tislabs.com Tue Mar 30 22:33:00 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA23934; Tue, 30 Mar 1999 22:33:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA25724 Tue, 30 Mar 1999 23:26:53 -0500 (EST) Message-ID: <3701AA0F.9914CCDA@cs.umass.edu> Date: Tue, 30 Mar 1999 23:52:31 -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 IP22) MIME-Version: 1.0 To: IP Security WG List CC: "Steven M. Bellovin" , Lewis McCarthy Subject: Re: IPSec IP Telephony:End to End or Segment References: <19990331010741.360F641F16@SIGABA.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve Bellovin writes: > CALEA does not prohibit end-to-end encryption, nor does it mandate any > form of key escrow. Agreed. > If the communicating parties set > up their own session, say via something like PGPphone, CALEA doesn't > apply. (Rather, the obligation on the carrier would be to turn over > the ciphertext, and let Ft. Meade figure it out.) Right, but my point is that the FBI and their friends in domestic surveillance will (presumably) demand from the U.S. Congress the same access to useful plaintext voice call content -- with proper authorization -- they already have in the PSTN. I don't expect the Atty. General and Dir. FBI to say "oh well, I guess we can't tap any more phone calls in transit" without a big fight. This is what I meant when I referred to "CALEA-style" intercepts in my previous message. I'm trying to anticipate the next generation of CALEA-like legislation. I don't know what Congress might mandate as a remedy, but generally I expect they would/will try to meet the "legitimate needs of law enforcement" in this matter. I'm concerned that they may regulate end-user software and dedicated hardware, and/or try to inject key escrow (GAK) into IP telephony protocols. [There's a stub section for key escrow support in the most recent draft I've seen of H.235, the ITU-T draft recommendation on "Security and Encryption for H Series (H.323 and other H.245 based) multimedia terminals". It's labelled For Future Study in the 25 Feb 1998 draft.] -Lewis From owner-ipsec@lists.tislabs.com Wed Mar 31 07:04:33 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA05937; Wed, 31 Mar 1999 07:04:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26905 Wed, 31 Mar 1999 07:11:09 -0500 (EST) Message-ID: <3702161F.10945993@cyphers.net> Date: Wed, 31 Mar 1999 04:34:52 -0800 From: Will Price X-Mailer: Mozilla 4.51 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: mode-cfg implementations? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Are there any companies with implementations of mode-cfg in hardware or software? Is there a list of companies implementing this extension or a test server for it? - -- Will Price, Architect/Sr. Mgr., PGP Client Products Total Network Security Division Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5 iQA/AwUBNwIV9qy7FkvPc+xMEQI0iwCgzXrFCzSYxWGMID3nk+j6WKdufUAAn1JR yLq6jKewnjHE0Zv3qY7wwKTI =8Fug -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Wed Mar 31 08:44:54 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10094; Wed, 31 Mar 1999 08:44:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27250 Wed, 31 Mar 1999 08:37:53 -0500 (EST) Date: Wed, 31 Mar 1999 17:01:13 +0300 (EET DST) Message-Id: <199903311401.RAA11526@torni.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Will Price Cc: ipsec@lists.tislabs.com Subject: mode-cfg implementations? In-Reply-To: <3702161F.10945993@cyphers.net> References: <3702161F.10945993@cyphers.net> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Will Price writes: > Are there any companies with implementations of mode-cfg in hardware > or software? Our IPSEC Express Toolkit has it as an optional feature. > Is there a list of companies implementing this extension > or a test server for it? The http://isakmp-test.ssh.fi/ test site will have limited support for testing it. It will respond to configuration mode exchanges, and it will always fill in 127.0.0.1 to all ip-numbers (address, netmask, dns, nbns, dhcp), and one hour address expiry. There is no way to configure it to initiate the configuration mode exchanges, but if there is real need for that I can add it to the user interface. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Mar 31 09:25:59 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA13435; Wed, 31 Mar 1999 09:25:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27451 Wed, 31 Mar 1999 09:11:48 -0500 (EST) Message-Id: <199903311434.GAA11693@gallium.network-alchemy.com> To: "S. B. Kulkarni" cc: ipsec@lists.tislabs.com, skelly@redcreek.com, rpereira@TimeStep.com, kivinen@ssh.fi, tjenkins@TimeStep.com Subject: Re: Commit Bit Processing In-reply-to: Your message of "Tue, 30 Mar 1999 12:29:18 +0500." <3.0.1.32.19990330122918.00690b10@172.16.1.10> Date: Wed, 31 Mar 1999 06:34:02 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > * Can the commit bit be set in any of the phases, I think some > implementaions send INVALID_FLAG if it is set in phase-I. The ISAKMP RFC says that it can be set during Phase 1, but no sane IKE implementation would do this. > * CONNECT notify, is it now treated as one of the Quick mode exchange ? and > When sending CONNECT notify should we use running IV of the quick mode or > calculate new IV ? if it is treated as part of quick mode exchange then we > should use running of the Quick mode. It's treated as part of the QM exchange and uses the QM running IV. > * Can the initiator set the commit bit in case of Quick mode, because what > RFC says is, who ever sets the commit bit should send the CONNECT notify, > and there is no point in sending the CONNECT notify along with the third > message of quick mode. Again the RFCs are ambigous on this, but it only makes sense as something set by the responder. The other ambiguity (from previous bake-off experience) is whether the initiator should reflect the COMMIT bit back in his final message. While there's no real value to it, there were implementations that expected this, and so most implementations do so. Derrell From owner-ipsec@lists.tislabs.com Wed Mar 31 10:43:14 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA19770; Wed, 31 Mar 1999 10:43:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA27763 Wed, 31 Mar 1999 09:31:02 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF9411FC@exchange> From: Tim Jenkins To: "Derrell D. Piper" , "S. B. Kulkarni" Cc: ipsec@lists.tislabs.com, skelly@redcreek.com, Roy Pereira , kivinen@ssh.fi Subject: RE: Commit Bit Processing Date: Wed, 31 Mar 1999 09:55:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Derrell D. Piper [mailto:ddp@Network-Alchemy.COM] > Sent: March 31, 1999 9:34 AM > To: S. B. Kulkarni > Cc: ipsec@lists.tislabs.com; skelly@redcreek.com; > rpereira@TimeStep.com; > kivinen@ssh.fi; tjenkins@TimeStep.com > Subject: Re: Commit Bit Processing > > > > * Can the initiator set the commit bit in case of Quick > mode, because what > > RFC says is, who ever sets the commit bit should send the > CONNECT notify, > > and there is no point in sending the CONNECT notify along > with the third > > message of quick mode. > > Again the RFCs are ambigous on this, but it only makes sense > as something set > by the responder. There are applications that want to consider using the commit bit in both directions. One of the specific ones I've seen is for key recovery. See , for example. > > The other ambiguity (from previous bake-off experience) is whether the > initiator should reflect the COMMIT bit back in his final > message. While > there's no real value to it, there were implementations that > expected this, > and so most implementations do so. > > Derrell > I agree that there's much confusion with this bit. (I would argue that reflecting back the commit bit is wrong, since it implies the initiator also wants to send a CONNECTED notification.) I'll be releasing an update to the re-keying document within a week, and the commit bit gets a fair amount of discussion in this document. From owner-ipsec@lists.tislabs.com Wed Mar 31 11:23:30 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22864; Wed, 31 Mar 1999 11:23:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28257 Wed, 31 Mar 1999 11:14:47 -0500 (EST) Message-Id: <199903311647.LAA09745@gcsd02.CSE.L-3COM.COM> From: "Costantini, Frank " To: "\"Anthony Walwyn\" " , ipsec@lists.tislabs.com Subject: RE: IPSec IP Telephony:End to End or Segment Date: Wed, 31 Mar 1999 11:33:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The problem you'll encounter on making an end-to-end secure call where one or both of the end parties is on the PSTN is that there are no standards for voice encryption over the PSTN. Many companies (including mine) have products available for PSTN voice encryption, but they are not interoperable. The PSTN devices encrypt the vocoded speech and forward the digital data over the phone lines using an integral modem, i.e. V.32. For a call through an IP telephony gateway, the gateway would have to detect the modem tones, and translate the underlying data into IP packets (like it would do for a FAX). Until/unless the PSTN encryptors standardize on an interoperable protocol like the FAX community did years ago, I don't think end-to-end secure calls involving a gateway will occur. The only other option would be for the gateway to encode the modem tones using PCM (64 kbps), and leave them for the end terminal to decode, but this is messy too. Frank Costantini Anthony Walwyn wrote: Hi, I've a question which I hope the experts on this list can answer/give their opinion. With respect to IP Telephony, should security be end-to-end or does it make sense to have it on just one segment, eg between two IP Telephony Gateways. Phone--PSTN--IPGW--IP Network--IPGW--PSTN-Phone If security is only implemented between the Gateways is the security risk unacceptable ?? If the phones were Internet-Phones, security could be implemented end-to-end using IPSec, but what happens if one end is an Internet Phone and one end is a normal PSTN Phone ? -- Anthony Walwyn Title: Senior Systems Engineer ECI Telecom, UK DCME Development, Voice: +44(0)1256 388065 ISIS House, Reading Road, Chineham Fax : +44(0)1256 388142 Basingstoke, Hampshire UK RG24 8TW Email: anthony.walwyn@telematics.com From owner-ipsec@lists.tislabs.com Wed Mar 31 12:54:44 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA29534; Wed, 31 Mar 1999 12:54:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28458 Wed, 31 Mar 1999 12:02:13 -0500 (EST) Message-Id: <199903311724.JAA11941@gallium.network-alchemy.com> To: Tim Jenkins cc: "S. B. Kulkarni" , ipsec@lists.tislabs.com, skelly@redcreek.com, Roy Pereira , kivinen@ssh.fi Subject: Re: Commit Bit Processing In-reply-to: Your message of "Wed, 31 Mar 1999 09:55:09 EST." <319A1C5F94C8D11192DE00805FBBADDF9411FC@exchange> Date: Wed, 31 Mar 1999 09:24:29 -0800 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > There are applications that want to consider using the commit bit > in both directions. One of the specific ones I've seen is for key > recovery. See , for example. Tim, Be that as it may, that's not why the COMMIT bit was invented. The COMMIT bit was designed to ensure that the QM responder has his SA's in place before receiving encrypted traffic under the newly negotiated IPSec SA's. [begin soapbox] If others want to use it for key recovery, don't expect them to interoperate with anyone else. It's precisely because of arguments like this that the IKE/IPSec protocol attained its ridiculous level of complexity. KISS. The COMMIT bit has an obvious meaning and that is that it should be set in the responder. If you reflect it back fine, my implementation doesn't care and I interoperate with people who do in their fielded implementations. It's absolutely imperative that we stive for interopatibility amongst our IKE/IPSec implementations. If we don't, we'll read about it in the press, again, ("major problems with IKE") and our prospective customers will continue to defer their purchasing decisions. Adding overloaded meaning to the COMMIT bit is not good engineering. [end of soapbox] Derrell From owner-ipsec@lists.tislabs.com Wed Mar 31 13:18:01 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01374; Wed, 31 Mar 1999 13:18:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28517 Wed, 31 Mar 1999 12:30:43 -0500 (EST) Message-Id: <319A1C5F94C8D11192DE00805FBBADDF94132D@exchange> From: Tim Jenkins To: Dan Harkins Cc: "Derrell D. Piper" , "S. B. Kulkarni" , ipsec@lists.tislabs.com, skelly@redcreek.com, Roy Pereira , kivinen@ssh.fi Subject: RE: Commit Bit Processing Date: Wed, 31 Mar 1999 12:55:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The only thing I can add to the commit bit issues, and I agree with what you've got, is that there are implementations out there that are using the commit bit to force the 'fourth' quick mode message solely for the purposes of causing re-transmission of the third quick mode message. This 1) is not it's intent, and 2) doesn't fix the problem, it only defers it. (It doesn't fix the problem if the 'fourth' quick mode message is dropped.) So, if you add to your list: o use of the commit bit is not intended to solve re-transmission issues associated with dropped quick mode packets. (or something like that), I'll consider the usage description of the commit bit closed. However, as others have pointed out before me, it doesn't solve the potential denial-of-service attack associated with the use of the bit. Regardless, I will keep the stuff about the commit bit in my document for now. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: March 31, 1999 12:32 PM > To: Tim Jenkins > Cc: Derrell D. Piper; S. B. Kulkarni; ipsec@lists.tislabs.com; > skelly@redcreek.com; Roy Pereira; kivinen@ssh.fi > Subject: Re: Commit Bit Processing > > > On Wed, 31 Mar 1999 09:55:09 EST Tim Jenkins wrote > > > > I agree that there's much confusion with this bit. (I would argue > > that reflecting back the commit bit is wrong, since it implies the > > initiator also wants to send a CONNECTED notification.) > > > > I'll be releasing an update to the re-keying document within a week, > > and the commit bit gets a fair amount of discussion in this > document. > > A couple of IETFs ago I presented a list of the ambiguities and issues > associated with IKE/ISAKMP/DOI and the commit bit was one of them. It > seemed to me that the general consensus was that: > > o the commit bit made sense only in Quick Mode. > o using the commit bit only extends Quick Mode by one message-- > from the responder back to the initiator. > o that it is sent as part of the Quick Mode and not as a > separate Informational exchange. > ... > From owner-ipsec@lists.tislabs.com Wed Mar 31 13:38:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA03037; Wed, 31 Mar 1999 13:38:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28480 Wed, 31 Mar 1999 12:10:07 -0500 (EST) Message-Id: <199903311732.JAA10803@potassium.network-alchemy.com> To: Tim Jenkins cc: "Derrell D. Piper" , "S. B. Kulkarni" , ipsec@lists.tislabs.com, skelly@redcreek.com, Roy Pereira , kivinen@ssh.fi Subject: Re: Commit Bit Processing In-reply-to: Your message of "Wed, 31 Mar 1999 09:55:09 EST." <319A1C5F94C8D11192DE00805FBBADDF9411FC@exchange> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10800.922901537.1@network-alchemy.com> Date: Wed, 31 Mar 1999 09:32:17 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 31 Mar 1999 09:55:09 EST Tim Jenkins wrote > > I agree that there's much confusion with this bit. (I would argue > that reflecting back the commit bit is wrong, since it implies the > initiator also wants to send a CONNECTED notification.) > > I'll be releasing an update to the re-keying document within a week, > and the commit bit gets a fair amount of discussion in this document. A couple of IETFs ago I presented a list of the ambiguities and issues associated with IKE/ISAKMP/DOI and the commit bit was one of them. It seemed to me that the general consensus was that: o the commit bit made sense only in Quick Mode. o using the commit bit only extends Quick Mode by one message-- from the responder back to the initiator. o that it is sent as part of the Quick Mode and not as a separate Informational exchange. Is this not acceptable? Do we want to revisit the commit bit again? If there are other issues that need to be addressed lemme know and I'll add them to http://www.lounge.org/ike_doi_errata.html. I guess if the authors of the problematic RFCs would get off their duffs-- myself included-- and come out with a draft to depricate the RFC then we could put these issues to rest. It would be nice to get some closure in Oslo. Dan. From owner-ipsec@lists.tislabs.com Wed Mar 31 17:42:26 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA16439; Wed, 31 Mar 1999 17:42:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29839 Wed, 31 Mar 1999 18:11:37 -0500 (EST) Message-ID: <3702B103.2687933E@siara.com> Date: Wed, 31 Mar 1999 15:34:27 -0800 From: "Sunil.Vallamkonda" X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: [Fwd: Returned mail: User unknown] Content-Type: multipart/mixed; boundary="------------7E92F99B89AC33C6A651A669" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------7E92F99B89AC33C6A651A669 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Hello, > > Is there any document or draft or rfc that explains how the SPD and SADB > entries should look like and their > relationships and also with interfaces and accesslists in IPSec and IKE ? > > Thx. > > Sunil. --------------7E92F99B89AC33C6A651A669 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from gateway2.mtv.siara.com by siara.com with smtp id m10SURp-001xj9C; Wed, 31 Mar 1999 15:31:01 -0800 (PST) Received: from relay.gw.tislabs.com ([192.94.214.100]) by gateway2.mtv.siara.com via smtpd (for [192.168.1.48]) with SMTP; 31 Mar 1999 23:57:32 UT Received: by relay.gw.tislabs.com; id SAA05124; Wed, 31 Mar 1999 18:41:44 -0500 (EST) Date: Wed, 31 Mar 1999 18:41:44 -0500 (EST) From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-Id: <199903312341.SAA05124@relay.gw.tislabs.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="SAA05124.922923704/relay.gw.tislabs.com" Auto-Submitted: auto-generated (failure) X-Mozilla-Status2: 00000000 This is a MIME-encapsulated message --SAA05124.922923704/relay.gw.tislabs.com The original message was received at Wed, 31 Mar 1999 18:41:33 -0500 (EST) from uucp@localhost ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to smtp.gw.tislabs.com: >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown --SAA05124.922923704/relay.gw.tislabs.com Content-Type: message/delivery-status Reporting-MTA: dns; relay.gw.tislabs.com Arrival-Date: Wed, 31 Mar 1999 18:41:33 -0500 (EST) Final-Recipient: rfc822; ipsec@tislabs.com Action: failed Status: 5.1.1 Remote-MTA: dns; smtp.gw.tislabs.com Diagnostic-Code: smtp; 550 ... User unknown Last-Attempt-Date: Wed, 31 Mar 1999 18:41:44 -0500 (EST) --SAA05124.922923704/relay.gw.tislabs.com Content-Type: message/rfc822 Return-Path: Received: by relay.gw.tislabs.com; id SAA05120; Wed, 31 Mar 1999 18:41:33 -0500 (EST) Received: from unknown(209.31.24.130) by relay.gw.tislabs.com via smap (4.1) id xma005113; Wed, 31 Mar 99 18:41:15 -0500 Received: from [192.168.1.48] by ns1.siara.com via smtpd (for relay.gw.tislabs.com [192.94.214.100]) with SMTP; 31 Mar 1999 23:56:58 UT Received: from siara.com by siara.com with esmtp id m10SUQv-001xj9C; Wed, 31 Mar 1999 15:30:05 -0800 (PST) Sender: sunil Message-ID: <3702AFF3.3134C48@siara.com> Date: Wed, 31 Mar 1999 15:29:55 -0800 From: "Sunil.Vallamkonda" X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Rohit CC: Wang Huaibo , ipsec@tis.com Subject: Info request.. References: <3.0.6.32.19990302193159.012698f0@hydmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Is there any document or draft or rfc that explains how the SPD and SADB entries should look like and their relationships and also with interfaces and accesslists in IPSec and IKE ? Thx. Sunil. --SAA05124.922923704/relay.gw.tislabs.com-- --------------7E92F99B89AC33C6A651A669-- From owner-ipsec@lists.tislabs.com Wed Mar 31 18:03:17 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA17342; Wed, 31 Mar 1999 18:03:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29971 Wed, 31 Mar 1999 18:42:25 -0500 (EST) Message-ID: <3702B839.C57A98A3@siara.com> Date: Wed, 31 Mar 1999 16:05:13 -0800 From: "Sunil.Vallamkonda" X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IPSec - SPD/SADB and Mobile IP References: <199903312359.SAA05517@relay.gw.tislabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Hello, > > 1)Is there any document or draft or rfc that explains how the SPD and SADB > entries should look like and their > relationships and also with interfaces and accesslists in IPSec and IKE ? > > 2) Erik Nordmark wrote: > > > > My first email on this subject suggested that a correspondent node should > > > perform outbound IPsec processing twice: first looking up a security policy > > > using the home address as the destination address selector and applying the > > > resulting security associations, and then doing another security policy > > > database lookup using the care-of address as the destination address > > > selector and applying the additional security associations. > > > > Let me try to add some more complexity to the brew: > > When two mobile nodes communicate there are actually 4 IP addresses > > in use since each of them have a care-of-address and a home address. > > Does that mean you need to do 4 SPD lookups for the 4 combinations of > > source and destination? > > Source home address -> Destination home address > > Source home address -> Destination COA > > Source COA -> Destination home address > > Source COA -> Destination COA > > > > What about the case when the correspondent doesn't have a binding cache > > entries - perhaps due to transient behavior (the first few packets) or > > perhaps due to the mobile wanting location privacy. > > Does the policy have to be coordinated between the correspondent host > > and the home agent that will tunnel the packet in those cases? > > What about when the CH and the HA are part of different admin domains? > > > > Erik From owner-ipsec@lists.tislabs.com Wed Mar 31 18:30:32 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA18102; Wed, 31 Mar 1999 18:30:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA00007 Wed, 31 Mar 1999 19:03:27 -0500 (EST) Message-Id: <4.2.0.32.19990331074444.0235a510@mail.imc.org> X-Sender: phoffman@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.32 (Beta) Date: Wed, 31 Mar 1999 07:45:30 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: RE: RSA claiming trademark on all uses of "RSA" to describe algor ithm In-Reply-To: References: <14DBB32E0DC0D211816600A0C99DE52405591F@mmsc00001.msc.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I suggest that we wait until RSA sends a letter to the IETF or to individual IPsec implementors about this. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Mar 31 20:46:47 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA00445; Wed, 31 Mar 1999 20:46:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA00384 Wed, 31 Mar 1999 21:19:55 -0500 (EST) Message-ID: <3702DD42.3EE8A5EB@cyphers.net> Date: Wed, 31 Mar 1999 18:43:18 -0800 From: Will Price X-Mailer: Mozilla 4.51 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: RSA claiming trademark on all uses of "RSA" to describealgor ithm References: <14DBB32E0DC0D211816600A0C99DE52405591F@mmsc00001.msc.es> <4.2.0.32.19990331074444.0235a510@mail.imc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Waiting until this becomes a critical problem for all implementors does not seem a prudent course of action. The list has been shown documented proof that RSADSI is initiating legal proceedings against those who use the name of its algorithm. Just because RSADSI may for the time being politely overlook the IETF does not mean that this issue is not important now. In September of 2000 when no one needs a license for the algorithm formerly known as "RSA", all of the implementors on this list will be in a serious legal bind if the products have not already been modified for this. This means we need probably 6 months to get the change into the drafts, and at *least* 6 months to hit everyone's product release cycles. I think the evidence we have been shown is clearly enough cause for us to rename the algorithm here so that all implementors can use a common reference. I don't think there is any one sacred name any of us would like to choose, so I wonder if someone on the list would be willing to setup a web page with a poll question on this giving perhaps the top ten choices and then narrowing to the top 5 to select the name. The name with the most votes wins. Paul Hoffman wrote: > > I suggest that we wait until RSA sends a letter to the IETF or to > individual IPsec implementors about this. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Mar 31 21:30:49 1999 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA03417; Wed, 31 Mar 1999 21:30:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA00523 Wed, 31 Mar 1999 22:08:25 -0500 (EST) Message-ID: <3702E8A2.15F9B7AB@mit.edu> Date: Wed, 31 Mar 1999 22:31:46 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.30 i586) X-Accept-Language: en MIME-Version: 1.0 To: Will Price CC: ipsec@lists.tislabs.com Subject: Re: RSA claiming trademark on all uses of "RSA" to describealgor ithm References: <14DBB32E0DC0D211816600A0C99DE52405591F@mmsc00001.msc.es> <4.2.0.32.19990331074444.0235a510@mail.imc.org> <3702DD42.3EE8A5EB@cyphers.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I council calm here. Using my MIT hat, I have asked some questions internally about whether or not RSADSI can make such a claim. Personally I want to see what answer I get before I go off and come up with another name... -Jeff Will Price wrote: > Waiting until this becomes a critical problem for all implementors does > not seem a prudent course of action. The list has been shown documented > proof that RSADSI is initiating legal proceedings against those who use > the name of its algorithm. Just because RSADSI may for the time being > politely overlook the IETF does not mean that this issue is not important > now. In September of 2000 when no one needs a license for the algorithm > formerly known as "RSA", all of the implementors on this list will be in a > serious legal bind if the products have not already been modified for > this. This means we need probably 6 months to get the change into the > drafts, and at *least* 6 months to hit everyone's product release cycles. > I think the evidence we have been shown is clearly enough cause for us to > rename the algorithm here so that all implementors can use a common reference. > > I don't think there is any one sacred name any of us would like to choose, > so I wonder if someone on the list would be willing to setup a web page > with a poll question on this giving perhaps the top ten choices and then > narrowing to the top 5 to select the name. The name with the most votes wins. > > Paul Hoffman wrote: > > > > I suggest that we wait until RSA sends a letter to the IETF or to > > individual IPsec implementors about this. > > > > --Paul Hoffman, Director > > --VPN Consortium