From owner-ietf-ipsra@mail.vpnc.org Wed May 2 05:34:36 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04384 for ; Wed, 2 May 2001 05:34:35 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id BAA29123 for ietf-ipsra-bks; Wed, 2 May 2001 01:59:11 -0700 (PDT) Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA29118 for ; Wed, 2 May 2001 01:59:09 -0700 (PDT) Received: from oleane (dyn-1-1-106.Vin.dialup.oleane.fr [195.25.4.106]) by smtp4.cluster.oleane.net with SMTP id f428x7w21820 for ; Wed, 2 May 2001 10:59:08 +0200 (CEST) Message-ID: <018701c0d2e6$3972a6a0$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPsec Global Summit Date: Wed, 2 May 2001 10:59:40 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0184_01C0D2F6.FC6C07E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0184_01C0D2F6.FC6C07E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, The third edition of the IPsec Global Summit will be organised next = 23-26 October in Paris. A call for proposals is online at: http://www.upperside.fr/ipsec2001/ipsec01cfp.htm ------=_NextPart_000_0184_01C0D2F6.FC6C07E0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello,
The third edition of the IPsec Global Summit will be = organised=20 next 23-26 October in Paris.
A call for proposals is online at:
http://www.uppe= rside.fr/ipsec2001/ipsec01cfp.htm
 
 
------=_NextPart_000_0184_01C0D2F6.FC6C07E0-- From owner-ietf-ipsra@mail.vpnc.org Wed May 2 08:10:04 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07145 for ; Wed, 2 May 2001 08:10:03 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id EAA14485 for ietf-ipsra-bks; Wed, 2 May 2001 04:36:46 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA14480 for ; Wed, 2 May 2001 04:36:44 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06040; Wed, 2 May 2001 07:36:43 -0400 (EDT) Message-Id: <200105021136.HAA06040@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ipsra@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhcp-11.txt Date: Wed, 02 May 2001 07:36:43 -0400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Remote Access Working Group of the IETF. Title : DHCPv4 Configuration of IPSEC Tunnel Mode Author(s) : B. Patel, B. Aboba, S. Kelly, V. Gupta Filename : draft-ietf-ipsec-dhcp-11.txt Pages : 16 Date : 01-May-01 In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a 'virtual' address from the corporate network, and then tunneling traffic via IPSec from the host's ISP-assigned address to the corporate security gateway. In IPv4, Dynamic Host Configuration Protocol (DHCP) provides for such remote host configuration. This draft explores the requirements for host configuration in IPSec tunnel mode, and describes how DHCPv4 may be leveraged for configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-11.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-dhcp-11.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-dhcp-11.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: <20010501140543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010501140543.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ipsra@mail.vpnc.org Wed May 2 13:38:06 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18142 for ; Wed, 2 May 2001 13:38:05 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA10141 for ietf-ipsra-bks; Wed, 2 May 2001 09:54:38 -0700 (PDT) Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA10136 for ; Wed, 2 May 2001 09:54:35 -0700 (PDT) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.22) with SMTP id TAA18469 for ; Wed, 2 May 2001 19:54:37 +0300 (EEST) Received: (qmail 25040 invoked from network); 2 May 2001 16:54:37 -0000 Received: from lavuaari.hel.fi.ssh.com (HELO ryijy.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 2 May 2001 16:54:37 -0000 Received: (from kivinen@localhost) by ryijy.hel.fi.ssh.com (8.11.0/8.11.0) id f42H1ab05903; Wed, 2 May 2001 20:01:36 +0300 (EEST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15088.15727.655054.772697@ryijy.hel.fi.ssh.com> Date: Wed, 2 May 2001 20:01:35 +0300 From: Tero Kivinen To: ietf-ipsra@vpnc.org Subject: Re: Straw poll, round 2 X-Mailer: VM 6.89 under Emacs 2.7.1 In-Reply-To: paul.hoffman@vpnc.org's message of "Wed, 18 Apr 2001 19:04:47 +0000 (UTC)" References: Organization: SSH Communications Security Oy X-Edit-Time: 0 min X-Total-Time: 0 min Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit getcert -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-ipsra@mail.vpnc.org Wed May 2 17:40:05 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24338 for ; Wed, 2 May 2001 17:40:04 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA25009 for ietf-ipsra-bks; Wed, 2 May 2001 14:05:05 -0700 (PDT) Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA25004 for ; Wed, 2 May 2001 14:05:04 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Wed, 2 May 2001 14:04:44 -0700 To: ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: Results of protocol straw poll Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. Thank you to everyone who expressed short or long opinions on the protocol straw poll. There were 18 public messages and 4 private messages. The totals are: GetCert: 4 PIC: 7 No new protocol: 8 Whatever the leader is: 3 I think it is safe to assume that the "whatever the leader" votes were for "the leader between PIC and GetCert". This shows a majority of folks want the WG to move forwards with PIC. I note again that this is not a strong majority; it is closely trailed by "no new protocol". So, would the PIC authors let the WG know that status of the current draft? draft-ietf-ipsra-pic-01.txt has now expired, but it can easily be revived by turning in a -02 document. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Wed May 2 21:54:37 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29166 for ; Wed, 2 May 2001 21:54:37 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id SAA09435 for ietf-ipsra-bks; Wed, 2 May 2001 18:13:33 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA09423 for ; Wed, 2 May 2001 18:13:30 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 18:13:22 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8AW48; Wed, 2 May 2001 18:02:43 -0700 From: "Scott G. Kelly" To: Thomas Narten Cc: ietf-ipsra@vpnc.org, dhcp-v4@bucknell.edu, Marcus Leech Message-ID: <3AF0ADBD.541ED3C5@redcreek.com> Date: Wed, 02 May 2001 18:00:45 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: draft-ietf-ipsec-dhcp-09.txt References: <200104241831.OAA09411@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thomas Narten wrote: > > 6.2. DHCPOFFER message processing > > > > Typically, the security gateway will also store the xid and the chaddr > > gleaned from the DHCPDISCOVER in a table so as to be able to route the > > corresponding DHCPOFFER message(s) back to the remote host. > > This would appear to be a fundamental change in relay agent model > compared to standard DHCP. That is, traditional relay agents are > stateless. All the info that a relay agent needs in order to relay > DHCP packets is contained in those packets. No per-client state is > needed. The above text suggests that the relay agent caches the > chaddr field in order to be able to route back DHCP responses. Why is > this needed? Isn't this info in the packet that needs to be relayed? > > The answer appears to be no, as the chaddr field as defined in this > document isn't sufficiently useful for this. > > Wouldn't it be better to (say) have the relay agent add a relay agent > option that includes information about the SA over which the packet > was received? When the server responds, that relay agent option could > contain the information needed properly forward the packet. This would > be consistent with existing DHCP specifications and would eliminate > the need for the relay agent to maintain per-client state. The text in the latest rev (11) has been modified to suggest using the relay option, but I wonder if this doesn't raise backward compatibility issues. A large number of deployed dhcp servers do not support the relay agent option, and in these cases, per-client state must be maintained. I wonder if we shouldn't have some language to this effect. Does anyone disagree? Scott From owner-ietf-ipsra@mail.vpnc.org Wed May 2 23:14:51 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00933 for ; Wed, 2 May 2001 23:14:51 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id TAA13665 for ietf-ipsra-bks; Wed, 2 May 2001 19:29:18 -0700 (PDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA13659; Wed, 2 May 2001 19:29:16 -0700 (PDT) Received: from gwzpc (sjc-vpn-tmp182.cisco.com [10.21.64.182]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id TAA29899; Wed, 2 May 2001 19:28:46 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Paul Hoffman / VPNC" , Subject: RE: Results of protocol straw poll Date: Wed, 2 May 2001 19:26:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] writes: > Greetings again. Thank you to everyone who expressed short or long > opinions on the protocol straw poll. There were 18 public messages > and 4 private messages. The totals are: > > GetCert: 4 > PIC: 7 > No new protocol: 8 > Whatever the leader is: 3 > > I think it is safe to assume that the "whatever the leader" votes > were for "the leader between PIC and GetCert". Why? By your count, the leader is "No new protocol". BTW, I saw several votes for protocols other than PIC and GetCert which do not appear to be reflected in the above. In particular, Uri Blumenthal voted for CRACK, and Bill Sommerfeld said "either getcert or pic". Does Uri's vote not count? If not, why not? True, CRACK wasn't mentioned as an option in your original message, but neither was "Whatever" (since when is "Whatever" a valid vote, except possibly in Florida ;-). Is Bill's a vote for both or neither? > > This shows a majority of folks want the WG to move forwards with PIC. Interesting math. Mod 11? > I note again that this is not a strong majority; it is closely > trailed by "no new protocol". No, it is _led_ by "no new protocol". > So, would the PIC authors let the WG > know that status of the current draft? draft-ietf-ipsra-pic-01.txt > has now expired, but it can easily be revived by turning in a -02 > document. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ietf-ipsra@mail.vpnc.org Wed May 2 23:21:31 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01004 for ; Wed, 2 May 2001 23:21:30 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id TAA14226 for ietf-ipsra-bks; Wed, 2 May 2001 19:55:56 -0700 (PDT) Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA14222; Wed, 2 May 2001 19:55:53 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Wed, 2 May 2001 19:55:36 -0700 To: , From: Paul Hoffman / VPNC Subject: RE: Results of protocol straw poll Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 7:26 PM -0700 5/2/01, Glen Zorn wrote: >Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] writes: > >> Greetings again. Thank you to everyone who expressed short or long >> opinions on the protocol straw poll. There were 18 public messages >> and 4 private messages. The totals are: >> >> GetCert: 4 >> PIC: 7 >> No new protocol: 8 >> Whatever the leader is: 3 >> >> I think it is safe to assume that the "whatever the leader" votes >> were for "the leader between PIC and GetCert". > >Why? By your count, the leader is "No new protocol". No, by my count the "whatever the leader" folks bring PIC up to 10. If you want to interpret the votes for "whichever is the leader" as going towards "no new protocol", that's fine, but it seems pretty unlikely that this was their intention. > BTW, I saw several >votes for protocols other than PIC and GetCert which do not appear to be >reflected in the above. Correct. > In particular, Uri Blumenthal voted for CRACK ...which I counted as "no new protocol"... >, and >Bill Sommerfeld said "either getcert or pic". ...which I counted as "whatever the leader is"... > Does Uri's vote not count? Yes, it does. As did yours (which was sent to me privately and not sent to the mailing list). --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Thu May 3 00:49:16 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02155 for ; Thu, 3 May 2001 00:49:15 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id VAA15261 for ietf-ipsra-bks; Wed, 2 May 2001 21:03:37 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA15254; Wed, 2 May 2001 21:03:36 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4343Gd29322; Wed, 2 May 2001 21:03:16 -0700 (PDT) Received: from gdburns-pc1.cisco.com ([144.254.225.12]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AEL35799; Wed, 2 May 2001 21:03:07 -0700 (PDT) Message-Id: <4.2.0.58.20010502205509.01a45b30@mira-sjcm-3> X-Sender: gdburns@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 02 May 2001 20:58:10 -0700 To: Paul Hoffman / VPNC , , From: Greg Burns Subject: RE: Results of protocol straw poll In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:55 PM 5/2/01 -0700, Paul Hoffman / VPNC wrote: >At 7:26 PM -0700 5/2/01, Glen Zorn wrote: >>Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] writes: >> >>> Greetings again. Thank you to everyone who expressed short or long >>> opinions on the protocol straw poll. There were 18 public messages >>> and 4 private messages. The totals are: >>> >>> GetCert: 4 >>> PIC: 7 >>> No new protocol: 8 >>> Whatever the leader is: 3 >>> >>> I think it is safe to assume that the "whatever the leader" votes >>> were for "the leader between PIC and GetCert". >> >>Why? By your count, the leader is "No new protocol". > >No, by my count the "whatever the leader" folks bring PIC up to 10. If you >want to interpret the votes for "whichever is the leader" as going towards >"no new protocol", that's fine, but it seems pretty unlikely that this was >their intention. It is incorrect, at least, to say that PIC+3 constitutes a majority, since I count 22 votes cast. Maybe you want to have a run-off between PIC and no new protocol. -- Greg >> BTW, I saw several >>votes for protocols other than PIC and GetCert which do not appear to be >>reflected in the above. > >Correct. > >> In particular, Uri Blumenthal voted for CRACK > >...which I counted as "no new protocol"... > >>, and >>Bill Sommerfeld said "either getcert or pic". > >...which I counted as "whatever the leader is"... > >> Does Uri's vote not count? > >Yes, it does. As did yours (which was sent to me privately and not sent to >the mailing list). > >--Paul Hoffman, Director >--VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Thu May 3 07:06:57 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18437 for ; Thu, 3 May 2001 07:06:56 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id DAA18584 for ietf-ipsra-bks; Thu, 3 May 2001 03:17:42 -0700 (PDT) Received: from hygro.adsl.duke.edu (IDENT:root@cichlid.adsl.duke.edu [152.16.64.203]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA18576 for ; Thu, 3 May 2001 03:17:39 -0700 (PDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f43AGu402673; Thu, 3 May 2001 06:16:57 -0400 Message-Id: <200105031016.f43AGu402673@hygro.adsl.duke.edu> To: "Scott G. Kelly" cc: ietf-ipsra@vpnc.org, dhcp-v4@bucknell.edu, Marcus Leech Subject: Re: draft-ietf-ipsec-dhcp-09.txt In-Reply-To: Message from "Scott G. Kelly" of "Wed, 02 May 2001 18:00:45 PDT." <3AF0ADBD.541ED3C5@redcreek.com> Date: Thu, 03 May 2001 06:16:56 -0400 From: Thomas Narten Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The text in the latest rev (11) has been modified to suggest using the > relay option, but I wonder if this doesn't raise backward compatibility > issues. A large number of deployed dhcp servers do not support the relay > agent option, and in these cases, per-client state must be maintained. I > wonder if we shouldn't have some language to this effect. Does anyone > disagree? I would spin the backwards compatability issue differently. In both cases, it would seem that new code needs to be written, since neither approach is presumably widely deployed today. Do we recommend that implementors implement an existing standard that *is* being implemented in deployed in some environments because it meets a need (i.e., the reason the relay agent option was defined in the first place) or do we recommend a different and non-standard way? The choice seems obvious to me. Thomas From owner-ietf-ipsra@mail.vpnc.org Thu May 3 12:40:59 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29646 for ; Thu, 3 May 2001 12:40:58 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA16958 for ietf-ipsra-bks; Thu, 3 May 2001 09:05:18 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA16947 for ; Thu, 3 May 2001 09:05:16 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 09:05:07 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8AXPX; Thu, 3 May 2001 08:55:51 -0700 From: "Scott G. Kelly" To: Thomas Narten Cc: ietf-ipsra@vpnc.org, dhcp-v4@bucknell.edu, Marcus Leech Message-ID: <3AF17F0F.3F9AB4A6@redcreek.com> Date: Thu, 03 May 2001 08:53:51 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: draft-ietf-ipsec-dhcp-09.txt References: <200105031016.f43AGu402673@hygro.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Thomas, Thomas Narten wrote: > > > The text in the latest rev (11) has been modified to suggest using the > > relay option, but I wonder if this doesn't raise backward compatibility > > issues. A large number of deployed dhcp servers do not support the relay > > agent option, and in these cases, per-client state must be maintained. I > > wonder if we shouldn't have some language to this effect. Does anyone > > disagree? > > I would spin the backwards compatability issue differently. In both > cases, it would seem that new code needs to be written, since neither > approach is presumably widely deployed today. Do we recommend that > implementors implement an existing standard that *is* being > implemented in deployed in some environments because it meets a need > (i.e., the reason the relay agent option was defined in the first > place) or do we recommend a different and non-standard way? The choice > seems obvious to me. I think I understand your position, and I agree from a philosophical standpoint. I have always thought the relay agent option was the best way to implement this. However, from a practical standpoint, we could not have deployed the units we have out there which use DHCP (in the thousands, I think) if we had relied upon the relay agent option. I am not advocating that we suggest an alternative method which may be used even if the relay option is available; I am suggesting adding text (an implementation note?) explaining that if the relay agent option is not supported, that state must be maintained in order for this to work. This might help to avoid implementer confusion. I don't feel strongly about this, but thought (based on years of implementing protocols based upon RFC's) that some clarifying language might be useful. Scott From owner-ietf-ipsra@mail.vpnc.org Thu May 3 16:16:12 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07599 for ; Thu, 3 May 2001 16:16:06 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA01013 for ietf-ipsra-bks; Thu, 3 May 2001 12:32:47 -0700 (PDT) Received: from dfmail.f-secure.com (dfmail.f-secure.com [194.252.6.39]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA01006 for ; Thu, 3 May 2001 12:32:46 -0700 (PDT) Received: (qmail 6098 invoked by uid 0); 3 May 2001 19:31:54 -0000 Received: from fsav4im2.f-secure.com (HELO fsav4im2) (194.197.29.47) by dfmail.f-secure.com with SMTP; 3 May 2001 19:31:54 -0000 Received: from dfintra.f-secure.com ([194.197.29.8]:3236) (HELO dfintra.f-secure.com) by fsav4im2 ([194.197.29.47]:25) (F-Secure Anti-Virus for Internet Mail 5.0.53 Release) with SMTP; Thu, 3 May 2001 19:39:01 -0000 Received: (qmail 25718 invoked from network); 3 May 2001 19:32:47 -0000 Received: from unknown (HELO F-Secure.com) (10.128.129.176) by dfintra.f-secure.com with SMTP; 3 May 2001 19:32:47 -0000 Message-ID: <3AF1B23B.F15AB00@F-Secure.com> Date: Thu, 03 May 2001 22:32:11 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Burns CC: Paul Hoffman / VPNC , gwz@cisco.com, ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll References: <4.2.0.58.20010502205509.01a45b30@mira-sjcm-3> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Greg Burns wrote: > > At 07:55 PM 5/2/01 -0700, Paul Hoffman / VPNC wrote: > >At 7:26 PM -0700 5/2/01, Glen Zorn wrote: > >>Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] writes: > >> > >>> Greetings again. Thank you to everyone who expressed short or long > >>> opinions on the protocol straw poll. There were 18 public messages > >>> and 4 private messages. The totals are: > >>> > >>> GetCert: 4 > >>> PIC: 7 > >>> No new protocol: 8 > >>> Whatever the leader is: 3 > >>> > >>> I think it is safe to assume that the "whatever the leader" votes > >>> were for "the leader between PIC and GetCert". > >> > >>Why? By your count, the leader is "No new protocol". > > > >No, by my count the "whatever the leader" folks bring PIC up to 10. If you > >want to interpret the votes for "whichever is the leader" as going towards > >"no new protocol", that's fine, but it seems pretty unlikely that this was > >their intention. > > It is incorrect, at least, to say that PIC+3 constitutes a majority, since > I count 22 votes cast. > > Maybe you want to have a run-off between PIC and no new protocol. What exactly does "no new protocol" mean? a) After finalizing the DHCP draft this WG is closed? All those who currently use CRACK, Hybrid, X-Auth, L2TP, whatever, shall continue to use these protocols. b) This WG chooses between alternatives like CRACK, Hybrid, X-Auth, L2TP, whatever, and does something to standardize its usage for remote access? I voted for PIC, but I like either of these choices less than GetCert. I think the majority is clearly "GetCert or PIC". Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Integrated Solutions for Enterprise Security From owner-ietf-ipsra@mail.vpnc.org Thu May 3 16:44:28 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09418 for ; Thu, 3 May 2001 16:44:26 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA02670 for ietf-ipsra-bks; Thu, 3 May 2001 13:01:18 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA02663; Thu, 3 May 2001 13:01:15 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f43Jwaf12513; Thu, 3 May 2001 12:59:20 -0700 (PDT) Received: from gdburns-pc1.cisco.com (dhcp-n-194.cisco.com [171.70.28.194]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AEM11244; Thu, 3 May 2001 12:59:57 -0700 (PDT) Message-Id: <4.2.0.58.20010503124757.01ae01b0@mira-sjcm-3> X-Sender: gdburns@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 03 May 2001 12:54:57 -0700 To: Ari Huttunen From: Greg Burns Subject: Re: Results of protocol straw poll Cc: Paul Hoffman / VPNC , gwz@cisco.com, ietf-ipsra@vpnc.org In-Reply-To: <3AF1B23B.F15AB00@F-Secure.com> References: <4.2.0.58.20010502205509.01a45b30@mira-sjcm-3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:32 PM 5/3/01 +0300, Ari Huttunen wrote: >Greg Burns wrote: > > > > At 07:55 PM 5/2/01 -0700, Paul Hoffman / VPNC wrote: > > >At 7:26 PM -0700 5/2/01, Glen Zorn wrote: > > >>Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] writes: > > >> > > >>> Greetings again. Thank you to everyone who expressed short or long > > >>> opinions on the protocol straw poll. There were 18 public messages > > >>> and 4 private messages. The totals are: > > >>> > > >>> GetCert: 4 > > >>> PIC: 7 > > >>> No new protocol: 8 > > >>> Whatever the leader is: 3 > > >>> > > >>> I think it is safe to assume that the "whatever the leader" votes > > >>> were for "the leader between PIC and GetCert". > > >> > > >>Why? By your count, the leader is "No new protocol". > > > > > >No, by my count the "whatever the leader" folks bring PIC up to 10. If you > > >want to interpret the votes for "whichever is the leader" as going towards > > >"no new protocol", that's fine, but it seems pretty unlikely that this was > > >their intention. > > > > It is incorrect, at least, to say that PIC+3 constitutes a majority, since > > I count 22 votes cast. > > > > Maybe you want to have a run-off between PIC and no new protocol. > >What exactly does "no new protocol" mean? >a) After finalizing the DHCP draft this WG is closed? All those who >currently use > CRACK, Hybrid, X-Auth, L2TP, whatever, shall continue to use these > protocols. >b) This WG chooses between alternatives like CRACK, Hybrid, X-Auth, L2TP, >whatever, > and does something to standardize its usage for remote access? I prefer b). >I voted for PIC, but I like either of these choices less than GetCert. I think >the majority is clearly "GetCert or PIC". A majority voted for either GetCert or PIC. A larger majority voted for either GetCert or no new protocol. A larger majority voted for either PIC or no new protocol. You assume people voting for GetCert prefer PIC over no new protocol. I don't see how you can justifiably infer that. You can't install PIC with 10 of 22 votes. This isn't a minority government in a multi-party parliament. One solution is chosen. The others are tossed. -- Greg >Ari > >-- >Ari Huttunen phone: +358 9 2520 0700 >Software Architect fax : +358 9 2520 5001 > >F-Secure Corporation http://www.F-Secure.com > >F(ully)-Secure products: Integrated Solutions for Enterprise Security From owner-ietf-ipsra@mail.vpnc.org Thu May 3 16:54:25 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09672 for ; Thu, 3 May 2001 16:54:24 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA03041 for ietf-ipsra-bks; Thu, 3 May 2001 13:11:16 -0700 (PDT) Received: from spsystems.net (spsystems.net [209.47.149.227]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA03036 for ; Thu, 3 May 2001 13:11:14 -0700 (PDT) Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id QAA21613; Thu, 3 May 2001 16:10:53 -0400 (EDT) Date: Thu, 3 May 2001 16:10:52 -0400 (EDT) From: Henry Spencer To: ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll In-Reply-To: <3AF1B23B.F15AB00@F-Secure.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 3 May 2001, Ari Huttunen wrote: > > It is incorrect, at least, to say that PIC+3 constitutes a majority, since > > I count 22 votes cast. > > Maybe you want to have a run-off between PIC and no new protocol. > > What exactly does "no new protocol" mean? > a) After finalizing the DHCP draft this WG is closed? While that may not be the best thing to do, the possibility *is* worth considering. The urge to *do* something runs deep, but "take no action" is a valid and legitimate approach, and sometimes the best one. We can all think of standards committees which would have done the world a favor if they had made that choice. The IETF standards process has been described as operating on "rough consensus and working code". To my mind, the main conclusion that comes out of the straw poll is that this working group has not achieved even a rough consensus. Can that be changed? If not, then "take no action" *is* the right conclusion. Henry Spencer henry@spsystems.net From owner-ietf-ipsra@mail.vpnc.org Thu May 3 17:30:31 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10793 for ; Thu, 3 May 2001 17:30:29 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA06582 for ietf-ipsra-bks; Thu, 3 May 2001 13:53:25 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA06577 for ; Thu, 3 May 2001 13:53:25 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 13:53:17 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8AYG3; Thu, 3 May 2001 13:52:56 -0700 From: "Scott G. Kelly" To: Henry Spencer Cc: ietf-ipsra@vpnc.org Message-ID: <3AF1C4B0.3ACCAE89@redcreek.com> Date: Thu, 03 May 2001 13:50:56 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Results of protocol straw poll References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Comments below... Henry Spencer wrote: > > On Thu, 3 May 2001, Ari Huttunen wrote: > > > It is incorrect, at least, to say that PIC+3 constitutes a majority, since > > > I count 22 votes cast. > > > Maybe you want to have a run-off between PIC and no new protocol. > > > > What exactly does "no new protocol" mean? > > a) After finalizing the DHCP draft this WG is closed? > > While that may not be the best thing to do, the possibility *is* worth > considering. The urge to *do* something runs deep, but "take no action" > is a valid and legitimate approach, and sometimes the best one. We can > all think of standards committees which would have done the world a favor > if they had made that choice. > > The IETF standards process has been described as operating on "rough > consensus and working code". To my mind, the main conclusion that comes > out of the straw poll is that this working group has not achieved even a > rough consensus. Can that be changed? If not, then "take no action" *is* > the right conclusion. > > Henry Spencer > henry@spsystems.net The "no new protocol" votes are actually votes for the status quo. The status quo is xauth, and the many issues associated with this have been discussed to death on multiple lists. The primary problem we are trying to solve pertains to use of legacy user authentications systems (primarily RADIUS) for authenticating IPsec remote access users. This is a security area working group - our primary consideration must be to provide secure solutions. It is clear that xauth is trivially susceptible to DoS attacks, among other things, and that should be a strong incentive against implementing it. It is also clear that adding complexity to IKE for this purpose increases the probability of introducing significant security-compromising errors to implementations. Hence, we should prefer solutions which use IKE as is, if possible. Given the constraints, the IKE and GetCert qualify, while "no new protocol" does not. It was stated at the outset that the vote would not be a 50% + 1 straight vote. The fact that there are those here who do not wish to adequately address security should not sway this working group from its course. We should choose one of these protocols and finish our work. Scott From owner-ietf-ipsra@mail.vpnc.org Thu May 3 17:31:57 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10828 for ; Thu, 3 May 2001 17:31:56 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA06311 for ietf-ipsra-bks; Thu, 3 May 2001 13:49:31 -0700 (PDT) Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA06306 for ; Thu, 3 May 2001 13:49:30 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Thu, 3 May 2001 13:49:12 -0700 To: ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: Re: Results of protocol straw poll Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: When the straw poll was taken, the call said "Note that this is a straw poll, not a "50%+1" straight vote. In the IETF tradition, the WG chairs will view the results and look for consensus." A few people here seem to think that the best way to find consensus is to look narrowly at the responses as precise and accurate voting; I don't. We have a mandate from our Area Director to move forwards with a protocol unless there is overwhelming WG resistance to doing so. At the Minneapolis meeting, we heard no such overwhelming resistance. In the straw poll, there was no such overwhelming resistance (although there was certainly more than was voiced in Minneapolis). Those WG members who feel that I interpreted the results of the straw poll incorrectly should take your concerns to the WG's responsible Area Director (Marcus Leech ). If he agrees with you (which is not bloody likely, of course), I'm quite willing to reinterpret the results. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Thu May 3 18:25:12 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11978 for ; Thu, 3 May 2001 18:25:11 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA11191 for ietf-ipsra-bks; Thu, 3 May 2001 14:39:27 -0700 (PDT) Received: from spsystems.net (spsystems.net [209.47.149.227]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA11165 for ; Thu, 3 May 2001 14:39:25 -0700 (PDT) Received: (from henry@localhost) by spsystems.net (8.9.3/8.9.3) id RAA23778; Thu, 3 May 2001 17:39:03 -0400 (EDT) Date: Thu, 3 May 2001 17:39:02 -0400 (EDT) From: Henry Spencer To: ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll In-Reply-To: <3AF1C4B0.3ACCAE89@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 3 May 2001, Scott G. Kelly wrote: > The "no new protocol" votes are actually votes for the status quo... Or for continued experimentation, with standardization to follow at a later date, perhaps because neither of the options offered seems attractive. > It was stated at the outset that the vote would not > be a 50% + 1 straight vote. The purpose of a straw poll is to assess the degree of consensus, not to make a final decision. But think about what the poll reveals. The group lacks consensus on which option to choose, but much more seriously, it also lacks consensus that either option is acceptable. This is a real issue which should not be swept under the rug. > The fact that there are those here who do > not wish to adequately address security should not sway this working > group from its course. We should choose one of these protocols and > finish our work. In other words, "we should ignore the requirement for consensus, because we know we're right and the people saying no are wrong"? The question of whether *either* of these protocols constitutes a suitable end to this work -- and if not, whether there are any other options which might, and if not, whether this work *should* proceed to a standard -- is legitimate and deserves consideration, not dismissal. "A motion to adjourn is always in order." Henry Spencer henry@spsystems.net From owner-ietf-ipsra@mail.vpnc.org Thu May 3 21:52:16 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17835 for ; Thu, 3 May 2001 21:52:15 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id RAA21992 for ietf-ipsra-bks; Thu, 3 May 2001 17:43:30 -0700 (PDT) Received: from potassium.cips.nokia.com (Potassium.Network-Alchemy.COM [199.46.17.146]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA21987 for ; Thu, 3 May 2001 17:43:29 -0700 (PDT) Received: from potassium.cips.nokia.com (localhost [127.0.0.1]) by potassium.cips.nokia.com (8.11.1/8.11.1) with ESMTP id f440Xrx69419; Thu, 3 May 2001 17:33:53 -0700 (PDT) (envelope-from dharkins@potassium.cips.nokia.com) Message-Id: <200105040033.f440Xrx69419@potassium.cips.nokia.com> To: "Scott G. Kelly" cc: ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll In-Reply-To: Your message of "Thu, 03 May 2001 13:50:56 PDT." <3AF1C4B0.3ACCAE89@redcreek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <69416.988936433.1@potassium.cips.nokia.com> Date: Thu, 03 May 2001 17:33:53 -0700 From: Dan Harkins Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 03 May 2001 13:50:56 PDT you wrote > > The "no new protocol" votes are actually votes for the status quo. The > status quo is xauth Actually that's not true. One of the "no new protocol" votes was actually a vote for CRACK. Dan. From owner-ietf-ipsra@mail.vpnc.org Fri May 4 03:15:21 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06239 for ; Fri, 4 May 2001 03:15:21 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id XAA07874 for ietf-ipsra-bks; Thu, 3 May 2001 23:36:59 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by above.proper.com (8.9.3/8.9.3) with ESMTP id XAA07865 for ; Thu, 3 May 2001 23:36:56 -0700 (PDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f446aBO09932; Fri, 4 May 2001 08:36:11 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f446aAJ11874; Fri, 4 May 2001 09:36:10 +0300 (EET DST) Message-ID: <3AF24DDA.7C220776@lmf.ericsson.se> Date: Fri, 04 May 2001 09:36:10 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ipsra@vpnc.org CC: Henry Spencer Subject: Re: Results of protocol straw poll References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >considering. The urge to *do* something runs deep, >but "take no action" is a valid and legitimate approach, >and sometimes the best one. We can Perhaps it's too late since I didn't cast my "vote" in due time. But I just wanted to voice my opinion that I (and Ericsson) care about the results of this group. We want a _standard_ protocol for doing IPsec remote access. I don't have much of an opinion of what solution should be picked, but I'm sure I want the result of this WG. I do not want us to do nothing. I do not want us to be forced to use non-standard or even proprietary schemes, with the need to perhaps support multiple such schemes in products. Jari From owner-ietf-ipsra@mail.vpnc.org Fri May 4 10:09:43 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12786 for ; Fri, 4 May 2001 10:09:41 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA14040 for ietf-ipsra-bks; Fri, 4 May 2001 06:30:34 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA14033; Fri, 4 May 2001 06:30:32 -0700 (PDT) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f44DU8Q13312; Fri, 4 May 2001 06:30:08 -0700 (PDT) Received: from stephanent3 (ott-b1-dhcp-10-85-28-184.cisco.com [10.85.28.184]) by toque.cisco.com (Mirapoint) with SMTP id ADW00930; Fri, 4 May 2001 09:30:01 -0400 (EDT) Message-ID: <0f7601c0d49e$90447260$b81c550a@cisco.com> From: "Stephane Beaulieu" To: "Scott G. Kelly" , "Henry Spencer" Cc: , References: <3AF1C4B0.3ACCAE89@redcreek.com> Subject: XAUTH Bashing (was Re: Results of protocol straw poll) Date: Fri, 4 May 2001 09:31:45 -0400 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi All, I know this is not the proper forum to discuss Xauth issues, but someone else raised them, so I will politely respond, and encourage any further comments on Xauth, or more specifically its implementation details or security concerns (those that are VALID at least) to be discussed on ietf-xauth@vpnc.org "Scott G. Kelly" wrote: > > It is clear that xauth is trivially susceptible to DoS attacks, among > other things, and that should be a strong incentive against implementing > it. Scott, You often wildly make these kinds of allegations against XAUTH, yet you've never demonstrated or discussed the rationale behind them. Would you care to share these with me please (preferably on the ietf-xauth@vpnc.org mailing list). I think it is important that you do this, because, for some reason, some people actually believe you, and then they send me emails asking when I'm going to fix these problems in the draft. Of, course, I have no idea what they are talking about. DoS attacks? Please explain. This is the first of heard of it. P.S. Just to make my position clear on Xauth (w/regards to this WG). Even though I am the author, I don't think that Xauth is the best solution for this problem. I think the models of Hybrid or CRACK are much better than all the other candidates. I specifically prefer Hybrid because it will allow me to re-use much of the code base I already have. Hybrid is actually VERY trivial once you already have Xauth. Stephane. From owner-ietf-ipsra@mail.vpnc.org Fri May 4 10:30:44 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13281 for ; Fri, 4 May 2001 10:30:43 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA16613 for ietf-ipsra-bks; Fri, 4 May 2001 06:52:43 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA16608 for ; Fri, 4 May 2001 06:52:42 -0700 (PDT) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f44Dqfa25077; Fri, 4 May 2001 06:52:41 -0700 (PDT) Received: from stephanent3 (ott-b1-dhcp-10-85-28-184.cisco.com [10.85.28.184]) by toque.cisco.com (Mirapoint) with SMTP id ADW01263; Fri, 4 May 2001 09:52:10 -0400 (EDT) Message-ID: <0f8801c0d4a1$a801d750$b81c550a@cisco.com> From: "Stephane Beaulieu" To: "Scott G. Kelly" , "Henry Spencer" Cc: References: <3AF1C4B0.3ACCAE89@redcreek.com> Subject: Re: Results of protocol straw poll Date: Fri, 4 May 2001 09:53:53 -0400 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.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > The "no new protocol" votes are actually votes for the status quo. The > status quo is xauth, and the many issues associated with this have been > discussed to death on multiple lists. I thought status quo was to have everyone disagree, have no one listen to each other, have people bury their head in the sand, and have vendors chose their own routes because they don't believe this WG will produce a protocol which will meet their requirements in a timely fashion. If a protocol is chosen without a good CLEAR majority, I suspect status quo is what you'll get. If you can't get the vendors to agree (much less commit) to something, then it aint gonna happen, (except maybe on paper). my 2cents (Canadian for what that's worth ;) Stephane. From owner-ietf-ipsra@mail.vpnc.org Fri May 4 11:57:43 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15090 for ; Fri, 4 May 2001 11:57:41 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA21675 for ietf-ipsra-bks; Fri, 4 May 2001 08:20:16 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA21666 for ; Fri, 4 May 2001 08:20:10 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA02817; Fri, 4 May 2001 08:12:11 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 4 May 2001 08:12:11 -0700 (PDT) From: Bernard Aboba To: "Scott G. Kelly" cc: Thomas Narten , ietf-ipsra@vpnc.org, dhcp-v4@bucknell.edu, Marcus Leech Subject: Re: draft-ietf-ipsec-dhcp-09.txt In-Reply-To: <3AF17F0F.3F9AB4A6@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is there some text that someone would like to add to the draft to address this issue? On Thu, 3 May 2001, Scott G. Kelly wrote: > Hi Thomas, > > Thomas Narten wrote: > > > > > The text in the latest rev (11) has been modified to suggest using the > > > relay option, but I wonder if this doesn't raise backward compatibility > > > issues. A large number of deployed dhcp servers do not support the relay > > > agent option, and in these cases, per-client state must be maintained. I > > > wonder if we shouldn't have some language to this effect. Does anyone > > > disagree? > > > > I would spin the backwards compatability issue differently. In both > > cases, it would seem that new code needs to be written, since neither > > approach is presumably widely deployed today. Do we recommend that > > implementors implement an existing standard that *is* being > > implemented in deployed in some environments because it meets a need > > (i.e., the reason the relay agent option was defined in the first > > place) or do we recommend a different and non-standard way? The choice > > seems obvious to me. > > I think I understand your position, and I agree from a philosophical > standpoint. I have always thought the relay agent option was the best > way to implement this. However, from a practical standpoint, we could > not have deployed the units we have out there which use DHCP (in the > thousands, I think) if we had relied upon the relay agent option. I am > not advocating that we suggest an alternative method which may be used > even if the relay option is available; I am suggesting adding text (an > implementation note?) explaining that if the relay agent option is not > supported, that state must be maintained in order for this to work. This > might help to avoid implementer confusion. > > I don't feel strongly about this, but thought (based on years of > implementing protocols based upon RFC's) that some clarifying language > might be useful. > > Scott > From owner-ietf-ipsra@mail.vpnc.org Fri May 4 12:25:53 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16081 for ; Fri, 4 May 2001 12:25:52 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA25617 for ietf-ipsra-bks; Fri, 4 May 2001 08:38:51 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA25602 for ; Fri, 4 May 2001 08:38:48 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 08:38:39 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8A6Q3; Fri, 4 May 2001 08:37:46 -0700 From: "Scott G. Kelly" To: Dan Harkins Cc: ietf-ipsra@vpnc.org Message-ID: <3AF2CC50.2E793565@redcreek.com> Date: Fri, 04 May 2001 08:35:44 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Results of protocol straw poll References: <200105040033.f440Xrx69419@potassium.cips.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Dan, Dan Harkins wrote: > > On Thu, 03 May 2001 13:50:56 PDT you wrote > > > > The "no new protocol" votes are actually votes for the status quo. The > > status quo is xauth > > Actually that's not true. One of the "no new protocol" votes was actually > a vote for CRACK. > Sorry for the misunderstanding - I stand corrected. I'd be personally interested to hear if any other "no new protocol" votes were also intended to be definitive votes for CRACK. Scott From owner-ietf-ipsra@mail.vpnc.org Fri May 4 12:49:57 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16702 for ; Fri, 4 May 2001 12:49:57 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA01271 for ietf-ipsra-bks; Fri, 4 May 2001 09:11:59 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA01267 for ; Fri, 4 May 2001 09:11:58 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 09:11:50 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8A6SV; Fri, 4 May 2001 09:03:38 -0700 From: "Scott G. Kelly" To: Henry Spencer Cc: ietf-ipsra@vpnc.org Message-ID: <3AF2D25F.B792B400@redcreek.com> Date: Fri, 04 May 2001 09:01:35 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Results of protocol straw poll References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Henry, I think some things were muddled in the translation of my thoughts. I'll try to clarify. Henry Spencer wrote: > > On Thu, 3 May 2001, Scott G. Kelly wrote: > > The "no new protocol" votes are actually votes for the status quo... > > Or for continued experimentation, with standardization to follow at a > later date, perhaps because neither of the options offered seems > attractive. Let's be very clear on context here. Two coupled proposals were made for remote access in the ipsec wg around 3 years ago: mode-cfg and xauth. I believe that very few vendors paid much attention to these for a long time, as most were scrambling to get other aspects of their implementations in order, and at least one had alternative solutions to these problems. Around 2 years ago (or so), vendors began to express more interest in resolving the remote access problem in ipsec, and the ipsra group was proposed. It was at this point that the proposed mechanisms first garnered a significant amount of attention. A number of people subsquently raised serious concerns about these mechanisms, and some of those folks are highly respected contributors to numerous security area working groups. The end result was the current direction of the ipsra group: DHCP for configuration, PIC or GetCert for user authentication needs. In the straw poll, many of the those who chose "no new protocol" work for vendors who have already deployed mode-cfg and xauth, so I assumed that they were implicitly voting for these, given their vested interest. I see that I was incorrect in at least one case, and have asked for further corrections in a related post. I would not rule out other proposals (continued experimentation), but I don't think that's what we'll get if we don't resolve this. Rather, I think vendors have a strong incentive to keep using what they've been using, resulting in a defacto standard which is less than desirable from a security standpoint. > > It was stated at the outset that the vote would not > > be a 50% + 1 straight vote. > > The purpose of a straw poll is to assess the degree of consensus, not to > make a final decision. But think about what the poll reveals. The group > lacks consensus on which option to choose, but much more seriously, it > also lacks consensus that either option is acceptable. This is a real > issue which should not be swept under the rug. Yes, I agree. However, there seems to be an element here who wishes to prevent this work from proceeding. I believe that if nothing is done by this group, we will have a less than desirable defacto standard in short order. > > The fact that there are those here who do > > not wish to adequately address security should not sway this working > > group from its course. We should choose one of these protocols and > > finish our work. > > In other words, "we should ignore the requirement for consensus, because > we know we're right and the people saying no are wrong"? Not exactly, but the relative security of our solution must be a signicant consideration in the final analysis. Obviously, the ideal outcome is to reach agreement on this point if possible. On the other hand, there are a number of respected security experts who support the pic/getcert approach for security reasons. Surely we must weigh this accordingly, given that this is a security area working group? > The question of whether *either* of these protocols constitutes a suitable > end to this work -- and if not, whether there are any other options which > might, and if not, whether this work *should* proceed to a standard -- is > legitimate and deserves consideration, not dismissal. "A motion to > adjourn is always in order." > Either of these options solves the problem within the working group's charter constraints, so either would constitute a suitable end to the work. As for other options, I don't think anyone has proposed any which meet the charter constraints. Scott From owner-ietf-ipsra@mail.vpnc.org Fri May 4 13:29:32 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17570 for ; Fri, 4 May 2001 13:29:32 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id JAA03750 for ietf-ipsra-bks; Fri, 4 May 2001 09:51:50 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA03744 for ; Fri, 4 May 2001 09:51:48 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA02898; Fri, 4 May 2001 09:43:18 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 4 May 2001 09:43:18 -0700 (PDT) From: Bernard Aboba To: Stephane Beaulieu cc: "Scott G. Kelly" , Henry Spencer , ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll In-Reply-To: <0f8801c0d4a1$a801d750$b81c550a@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I thought status quo was to have everyone disagree, have no one listen to > each other, have people bury their head in the sand, and have vendors chose > their own routes because they don't believe this WG will produce a protocol > which will meet their requirements in a timely fashion. That's a blunt but accurate description of the status quo ;) > If a protocol is chosen without a good CLEAR majority, I suspect status quo > is what you'll get. If you can't get the vendors to agree (much less > commit) to something, then it aint gonna happen, (except maybe on paper). > I'd also note that we now have other WGs (IPS) creating their own IPSEC key exchange methods in order to get around the "don't touch IKE" limitations. So in addition to a potential explosion of vendor-specific routes, we also are now facing proliferation of application-specific key exchange methods as well. As a result, IPSEC is very likely to become the next RPC - a standardized framework that is used largely for creation of proprietary protocols. We're more than half-way there. So unless any proposal has a realistic chance of putting a stop to this, I'd say that it's not worth doing, because we'll still have all the problems we had before magnified by whatever time it takes to produce the (probably ineffective) cure. From owner-ietf-ipsra@mail.vpnc.org Fri May 4 14:53:52 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19137 for ; Fri, 4 May 2001 14:53:52 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA07988 for ietf-ipsra-bks; Fri, 4 May 2001 11:01:03 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA07982 for ; Fri, 4 May 2001 11:01:02 -0700 (PDT) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f44I10a17461 for ; Fri, 4 May 2001 11:01:01 -0700 (PDT) Received: from DDUKESW2K (sjc-vpn1-9.cisco.com [10.21.96.9]) by toque.cisco.com (Mirapoint) with SMTP id ADW05186; Fri, 4 May 2001 14:00:30 -0400 (EDT) Message-ID: <009201c0d4c4$3d052600$6501a8c0@cisco.com> From: "Darren Dukes" To: "ietf-ipsra" Subject: Re: Results of protocol straw poll Date: Fri, 4 May 2001 14:01:25 -0400 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Below is a review of who voted for what and why (those posted to the list at least). Hopefully this will clear up some of the questions of intent. Note - 5 of 6 No New Protocol votes were for Hybrid or Crack. - one PIC vote would rather see us start all over again. - All "Either" votes were for GETCERT or PIC - Three No New Protocol voters prefers PIC over GETCERT I agree with Paul that there appears to be narrow agreement on PIC, although I would prefer a solution that was a lot less complex. Speculating further, if the "don't add to IKE" rule didn't exist I think Hybrid or Crack would have been chosen long ago and this group would be done. Oh well can't change that, enjoy. GetCert - 3 ~~~~~~~ Bernard Aboba - V2 Marcus Leech - V2 Tero Kivinen - getcert. PIC- 5 ~~~ Steve Robinson - PIC, but doesn't like either (doesn't like extra server). Rather see "start from scratch" option. Sankar Ramamoorthi - Better code reuse. Scott G. Kelly -No Comment Ari Huttunen - PIC has a better chance of quickly replacing XAuth and Hybrid. Peter Maricle - PIC Either PIC or GETCERT - 3 ~~~~~~~~~~~~~~~~~~~~~ Ricky Charlet - Votes for Leader, tie goes to PIC. Richard Welty - Agrees with Ricky, votes for leader. Bill Sommerfeld - Either Getcert or PIC. No New Protocol - 6 ~~~~~~~~~~~~~~ Stephane Beaulieu - Prefer Hybrid or Crack, PIC/GETCERT too tough to implement Scott Fanning - L2TP Hybrid or Crack can solve this. Will Price - Replies to Scott Fanning, agrees that solutions already exist. Uri Blumenthal - Prefers CRACK David Mason - Prefers "that-whick-must-not-be-named" [XAUTH?] but PIC if that won't happen. Andrew Krywaniuk - Prefers (in order) Hybrid, Crack, PIC, Getcert Yuri Poeluev - PIC/GETCERT limited on small devices, prefers PIC if No New Protocol is not accepted. Yet more details - Full Replies ***************** Bernard Aboba >GetCert v2 (the new and improved version) ***************** Steve Robinson >PIC > >It is a simpler solution, and IP Security is complex enough as it is. But to >be honest, I don't like PIC because I don't want to be dependent on a server >outside of the scope of my security software on the host machine (this was the >reason I voted for GetCert the first time). I feel like I'm trying to choose >the lesser of two evils here -- if we had a fourth option "try again from >scratch" I'd vote for it over "no new protocol" even though I don't have a >better idea to present at this time. *************** Stephane Beaulieu > No new protocol. > > Reason: I'd prefer something that's easier to implement, and (more > importantly) easy to deploy. If Hybrid or CRACK were candidates, I'd vote > for them. *************** Scott Fanning >No new protocol. > >Between L2TP, Hybrid, CRACK and the other "unnamed" methods, I think we >can solve this problem. **************** Will Price > No new protocol. > > Agreed that adequate solutions to this problem set already exist. *************** Uri Blumenthal > I prefer CRACK. *************** David Mason >No new protocol. > >For now I prefer that-which-must-not-be-named. Barring that I'd vote for >PIC. *************** Andrew Krywanuik >In order of preference: > >1. Hybrid >2. Crack >3. PIC >4. GetCert > >Justification: > >- PIC/GetCert address what I believe to be non-existant flaws in the >Hybrid/Crack approach. > >- Hybrid and Crack are functionally equivalent, however Hybrid reuses code >that many IPsec implementers already have. > >- PIC and GetCert are functionally similar, however I believe that PIC will >integrate into existing gateways better. **************** Ricky Charlet >Howdy, > >Count my vote with the leader, wether it is PIC or getCert (in case of >a tie I vote for PIC). ***************** Sankar Ramamoorthi >PIC >Better code reusability. ***************** Richard Welty >i agree; this requires a sensible resolution. >PIC or Getcert, whichever is leading the vote. ***************** Bill Sommerfeld > either getcert or pic ***************** Peter Maricle >PIC >For reasons others have already pointed out. ***************** Scott G. Kelly > PIC ***************** Ari Huttunen >PIC >I think PIC has a better chance of quickly replacing X-Auth and Hybrid. ***************** Yuri Poeluev >No new protocol" - is the first choice > When running IKE on small constrained devices "PIC"/"GetCert" > introduces a potential problem due to code size, OS limitations, > and other similar constraints. > >"PIC" - is the second preferred choice, but *only if the first one is not accepted* > By choosing it there is a possibility of reusing ISAKMP code from IKE > implementation. Again it's an issue for the constrained devices. ************ Tero Kivinen >getcert ************ Marcus Leech >getcert2 From owner-ietf-ipsra@mail.vpnc.org Fri May 4 16:04:53 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19938 for ; Fri, 4 May 2001 16:04:52 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA14921 for ietf-ipsra-bks; Fri, 4 May 2001 12:30:51 -0700 (PDT) Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA14917 for ; Fri, 4 May 2001 12:30:49 -0700 (PDT) Received: (qmail 20891 invoked from network); 4 May 2001 19:29:02 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 4 May 2001 19:29:02 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Fri, 4 May 2001 15:29:03 -0400 Received: from andrewk3 ([138.120.114.30]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAAD47 for ; Fri, 4 May 2001 15:29:02 -0400 Reply-To: From: "Andrew Krywaniuk" Cc: Subject: RE: Results of protocol straw poll Date: Fri, 4 May 2001 15:24:07 -0400 Message-Id: <006701c0d4cf$ddf084a0$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <3AF2CC50.2E793565@redcreek.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Scott, Your comments were clearly misleading, which I find odd, since the evidence to impeach them is publicly available (see Darren's summary). Most of the "no new protocol" votes were for hybrid, which is a different protocol from XAuth. Several people have said that they would be okay with the IPSRA group standardizing Hybrid without standardizing XAuth in its Cert/Preshared key modes. Several of the "no new protocol" voters also said that they would be willing to implement CRACK. Not everyone put it as their first choice, but they wrote it only their ballot as an acceptable option. So either you didn't read the straw poll ballots very carefully, or your read them and chose to misinterpret them. I wonder if everyone can figure it out...? Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ietf-ipsra@mail.vpnc.org > [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Scott G. Kelly > Sent: Friday, May 04, 2001 11:36 AM > To: Dan Harkins > Cc: ietf-ipsra@vpnc.org > Subject: Re: Results of protocol straw poll > > > Hi Dan, > > Dan Harkins wrote: > > > > On Thu, 03 May 2001 13:50:56 PDT you wrote > > > > > > The "no new protocol" votes are actually votes for the > status quo. The > > > status quo is xauth > > > > Actually that's not true. One of the "no new protocol" > votes was actually > > a vote for CRACK. > > > > Sorry for the misunderstanding - I stand corrected. I'd be personally > interested to hear if any other "no new protocol" votes were also > intended to be definitive votes for CRACK. > > Scott > From owner-ietf-ipsra@mail.vpnc.org Fri May 4 17:33:27 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21185 for ; Fri, 4 May 2001 17:33:27 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id NAA19844 for ietf-ipsra-bks; Fri, 4 May 2001 13:41:29 -0700 (PDT) Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA19837 for ; Fri, 4 May 2001 13:41:27 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <006701c0d4cf$ddf084a0$1e72788a@andrewk3.ca.newbridge.com> References: <006701c0d4cf$ddf084a0$1e72788a@andrewk3.ca.newbridge.com> Date: Fri, 4 May 2001 13:41:06 -0700 To: ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: RE: Results of protocol straw poll Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Two methods for achieving consensus and do good engineering work are to make personal attacks on each other and to try to speak for people with whom you disagree. There are also other methods. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Fri May 4 17:34:22 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21208 for ; Fri, 4 May 2001 17:34:21 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA20835 for ietf-ipsra-bks; Fri, 4 May 2001 13:53:36 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA20825 for ; Fri, 4 May 2001 13:53:34 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 13:53:27 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8A7XQ; Fri, 4 May 2001 13:53:25 -0700 From: "Scott G. Kelly" To: andrew.krywaniuk@alcatel.com Cc: ietf-ipsra@vpnc.org Message-ID: <3AF3164A.758250AB@redcreek.com> Date: Fri, 04 May 2001 13:51:22 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Results of protocol straw poll References: <006701c0d4cf$ddf084a0$1e72788a@andrewk3.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrew Krywaniuk wrote: > > Scott, > > Your comments were clearly misleading, which I find odd, since the evidence > to impeach them is publicly available (see Darren's summary). > > Most of the "no new protocol" votes were for hybrid, which is a different > protocol from XAuth. Several people have said that they would be okay with > the IPSRA group standardizing Hybrid without standardizing XAuth in its > Cert/Preshared key modes. Have I missed something? I can't find my copy of the hybrid draft, but I believe hybrid simply modifies xauth, and requires both mode-cfg and xauth in it's current incarnation. Is this wrong? > Several of the "no new protocol" voters also said that they would be willing > to implement CRACK. Not everyone put it as their first choice, but they > wrote it only their ballot as an acceptable option. What I asked in the email in which you just replied to is, who prefers CRACK as a first choice? > So either you didn't read the straw poll ballots very carefully, or your > read them and chose to misinterpret them. I wonder if everyone can figure it > out...? It is true that I did not review them together before making my comment, but I believe that most of those suggesting "no new protocol" have already implemented xauth, and I assume that not doing anymore work would be their first choice. Here is Darren's summary: > No New Protocol - 6 > ~~~~~~~~~~~~~~ > Stephane Beaulieu - Prefer Hybrid or Crack, PIC/GETCERT too tough to > implement > Scott Fanning - L2TP Hybrid or Crack can solve this. > Will Price - Replies to Scott Fanning, agrees that solutions already exist. > Uri Blumenthal - Prefers CRACK > David Mason - Prefers "that-whick-must-not-be-named" [XAUTH?] but PIC if > that won't happen. > Andrew Krywaniuk - Prefers (in order) Hybrid, Crack, PIC, Getcert > Yuri Poeluev - PIC/GETCERT limited on small devices, prefers PIC if No New > Protocol is not accepted. All of these folks have already implemented xauth. As I said, I believe hybrid is a modified version of xauth. Is this incorrect? Scott > > Andrew > ------------------------------------------- > Upon closer inspection, I saw that the line > dividing black from white was in fact a shade > of grey. As I drew nearer still, the grey area > grew larger. And then I was enlightened. > > > -----Original Message----- > > From: owner-ietf-ipsra@mail.vpnc.org > > [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Scott G. Kelly > > Sent: Friday, May 04, 2001 11:36 AM > > To: Dan Harkins > > Cc: ietf-ipsra@vpnc.org > > Subject: Re: Results of protocol straw poll > > > > > > Hi Dan, > > > > Dan Harkins wrote: > > > > > > On Thu, 03 May 2001 13:50:56 PDT you wrote > > > > > > > > The "no new protocol" votes are actually votes for the > > status quo. The > > > > status quo is xauth > > > > > > Actually that's not true. One of the "no new protocol" > > votes was actually > > > a vote for CRACK. > > > > > > > Sorry for the misunderstanding - I stand corrected. I'd be personally > > interested to hear if any other "no new protocol" votes were also > > intended to be definitive votes for CRACK. > > > > Scott > > From owner-ietf-ipsra@mail.vpnc.org Fri May 4 17:53:57 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21393 for ; Fri, 4 May 2001 17:53:56 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id OAA22557 for ietf-ipsra-bks; Fri, 4 May 2001 14:15:37 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA22546; Fri, 4 May 2001 14:15:35 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 14:15:28 -0700 Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8A8L8; Fri, 4 May 2001 14:15:23 -0700 From: Ricky Charlet To: Paul Hoffman / VPNC Cc: ietf-ipsra@vpnc.org Message-ID: <3AF30F44.EEDA386@redcreek.com> Date: Fri, 04 May 2001 14:21:24 -0600 Organization: Redcreek Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Results of protocol straw poll References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Paul Hoffman / VPNC wrote: > > Greetings again. Thank you to everyone who expressed short or long > opinions on the protocol straw poll. There were 18 public messages > and 4 private messages. The totals are: > > GetCert: 4 > PIC: 7 > No new protocol: 8 > Whatever the leader is: 3 > > I think it is safe to assume that the "whatever the leader" votes > were for "the leader between PIC and GetCert". > > This shows a majority of folks want the WG to move forwards with PIC. > I note again that this is not a strong majority; it is closely > trailed by "no new protocol". So, would the PIC authors let the WG > know that status of the current draft? draft-ietf-ipsra-pic-01.txt > has now expired, but it can easily be revived by turning in a -02 > document. > > --Paul Hoffman, Director > --VPN Consortium When shall the first interoperability testing of PIC begin? -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ietf-ipsra@mail.vpnc.org Fri May 4 18:53:35 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21959 for ; Fri, 4 May 2001 18:53:34 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA27382 for ietf-ipsra-bks; Fri, 4 May 2001 15:17:15 -0700 (PDT) Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75]) by above.proper.com (8.9.3/8.9.3) with SMTP id PAA27378 for ; Fri, 4 May 2001 15:17:13 -0700 (PDT) Received: (qmail 27390 invoked from network); 4 May 2001 22:15:28 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 4 May 2001 22:15:28 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Fri, 4 May 2001 18:15:30 -0400 Received: from andrewk3 ([138.120.114.30]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA92 for ; Fri, 4 May 2001 18:15:30 -0400 Reply-To: From: "Andrew Krywaniuk" To: Subject: RE: Results of protocol straw poll Date: Fri, 4 May 2001 18:09:42 -0400 Message-Id: <006a01c0d4e7$1ecf9b70$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <3AF3164A.758250AB@redcreek.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > Most of the "no new protocol" votes were for hybrid, which > is a different > > protocol from XAuth. Several people have said that they > would be okay with > > the IPSRA group standardizing Hybrid without standardizing > XAuth in its > > Cert/Preshared key modes. > > Have I missed something? I can't find my copy of the hybrid > draft, but I > believe hybrid simply modifies xauth, and requires both mode-cfg and > xauth in it's current incarnation. Is this wrong? Hybrid only requires parts of XAuth and Mode-Cfg. As has been pointed out on this mailing list several times before, a WG-standardized version of Hybrid does not necessarily have to reference XAuth and Hybrid. It could incorporate all the text into one document. > > Several of the "no new protocol" voters also said that they > would be willing > > to implement CRACK. Not everyone put it as their first > choice, but they > > wrote it only their ballot as an acceptable option. > > What I asked in the email in which you just replied to is, who prefers > CRACK as a first choice? In the straw poll, votes for "either PIC or GetCert" were allowed. Votes for "no new protocol" were mostly for "either Hybrid or CRACK". Only one of the votes appeared to be for XAuth specifically, although even that was unclear (it was for "that which must not be named"). I believe that XAuth is an acceptable remote access model under some circumstances, but if this WG was to devise a single all-encompasing remote access model it should be either Hybrid or CRACK. > I believe that most of those suggesting "no new protocol" have > already implemented xauth, and I assume that not doing anymore work > would be their first choice. Yeah, but many of us have also implemented Hybrid. You're right that not doing any more work would be my first choice, but you're wrong about what that implies. My second choice would still be CRACK, which would involve rewriting all our code just to get a less flexible but functionally equivalent alternative to Hybrid. What does that imply? Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ietf-ipsra@mail.vpnc.org Fri May 4 19:18:39 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22239 for ; Fri, 4 May 2001 19:18:38 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA28543 for ietf-ipsra-bks; Fri, 4 May 2001 15:43:45 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA28536 for ; Fri, 4 May 2001 15:43:42 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id PAA03202; Fri, 4 May 2001 15:35:19 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 4 May 2001 15:35:19 -0700 (PDT) From: Bernard Aboba To: Stephane Beaulieu cc: "Scott G. Kelly" , Henry Spencer , ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > If a protocol is chosen without a good CLEAR majority, I suspect status quo > is what you'll get. If you can't get the vendors to agree (much less > commit) to something, then it aint gonna happen, (except maybe on paper). I'd also note that this would represent a new and potentially dangerous interpretation of the meaning of "rough consensus". If a WG can move forward on a proposal that not even a majority of the WG actually supports, then putting the IETF standards stamp on that protocol has no meaning. Ultimately, the "rough consensus and running code" philosophy is at the heart of what we do here. There are very few circumstances in which I'd consider sacrificing that in exchange for more rapid progress. From owner-ietf-ipsra@mail.vpnc.org Fri May 4 22:02:55 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24621 for ; Fri, 4 May 2001 22:02:54 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id SAA08614 for ietf-ipsra-bks; Fri, 4 May 2001 18:32:07 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA08608 for ; Fri, 4 May 2001 18:32:05 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 18:31:49 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8A885; Fri, 4 May 2001 18:31:46 -0700 From: "Scott G. Kelly" To: Bernard Aboba Cc: Thomas Narten , ietf-ipsra@vpnc.org, dhcp-v4@bucknell.edu, Marcus Leech Message-ID: <3AF35784.DF61B04D@redcreek.com> Date: Fri, 04 May 2001 18:29:40 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: draft-ietf-ipsec-dhcp-09.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here's the current text: ---------------------------- Since DHCP Relays are stateless, it is necessary for the security gateway to insert appropriate information in the DHCP Relay Agent Information Option [17] prior to forwarding the message to one or more DHCP servers. This enables the security gateway to route the corresponding DHCPOFFER message(s) back to the remote host on the correct IPSec tunnel, without having to keep state gleaned from the DISCOVER, such as a table of the xid, chaddr and tunnel. This is accomplished by identification of the virtual port number of the tunnel via the Agent Circuit ID Sub-option (sub-option code 1) of the DHCP Relay Agent Information Option, as described in [17]. ----------------------------- How about adding this: If attempting to interoperate with a legacy DHCP server which does not support the required options, stateless relay agent behavior will not be possible. In such cases, implementations may devise a mapping between the xid, chaddr, and tunnel in order to route the DHCP server response to the appropriate tunnel endpoint. --Scott Bernard Aboba wrote: > > Is there some text that someone would like to add to the > draft to address this issue? > > On Thu, 3 May 2001, Scott G. Kelly wrote: > > > Hi Thomas, > > > > Thomas Narten wrote: > > > > > > > The text in the latest rev (11) has been modified to suggest using the > > > > relay option, but I wonder if this doesn't raise backward compatibility > > > > issues. A large number of deployed dhcp servers do not support the relay > > > > agent option, and in these cases, per-client state must be maintained. I > > > > wonder if we shouldn't have some language to this effect. Does anyone > > > > disagree? > > > > > > I would spin the backwards compatability issue differently. In both > > > cases, it would seem that new code needs to be written, since neither > > > approach is presumably widely deployed today. Do we recommend that > > > implementors implement an existing standard that *is* being > > > implemented in deployed in some environments because it meets a need > > > (i.e., the reason the relay agent option was defined in the first > > > place) or do we recommend a different and non-standard way? The choice > > > seems obvious to me. > > > > I think I understand your position, and I agree from a philosophical > > standpoint. I have always thought the relay agent option was the best > > way to implement this. However, from a practical standpoint, we could > > not have deployed the units we have out there which use DHCP (in the > > thousands, I think) if we had relied upon the relay agent option. I am > > not advocating that we suggest an alternative method which may be used > > even if the relay option is available; I am suggesting adding text (an > > implementation note?) explaining that if the relay agent option is not > > supported, that state must be maintained in order for this to work. This > > might help to avoid implementer confusion. > > > > I don't feel strongly about this, but thought (based on years of > > implementing protocols based upon RFC's) that some clarifying language > > might be useful. > > > > Scott > > From owner-ietf-ipsra@mail.vpnc.org Sun May 6 12:54:01 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12140 for ; Sun, 6 May 2001 12:54:00 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA24965 for ietf-ipsra-bks; Sun, 6 May 2001 09:12:55 -0700 (PDT) Received: from dfmail.f-secure.com (dfmail.f-secure.com [194.252.6.39]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA24960 for ; Sun, 6 May 2001 09:12:52 -0700 (PDT) Received: (qmail 15286 invoked by uid 0); 6 May 2001 16:11:52 -0000 Received: from fsav4im2.f-secure.com (HELO fsav4im2) (194.197.29.47) by dfmail.f-secure.com with SMTP; 6 May 2001 16:11:52 -0000 Received: from dfintra.f-secure.com ([194.197.29.8]:1714) (HELO dfintra.f-secure.com) by fsav4im2 ([194.197.29.47]:25) (F-Secure Anti-Virus for Internet Mail 5.0.53 Release) with SMTP; Sun, 6 May 2001 16:19:01 -0000 Received: (qmail 16479 invoked from network); 6 May 2001 16:12:53 -0000 Received: from unknown (HELO F-Secure.com) (10.128.129.176) by dfintra.f-secure.com with SMTP; 6 May 2001 16:12:53 -0000 Message-ID: <3AF577DF.1558C249@F-Secure.com> Date: Sun, 06 May 2001 19:12:15 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: andrew.krywaniuk@alcatel.com CC: ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll References: <006a01c0d4e7$1ecf9b70$1e72788a@andrewk3.ca.newbridge.com> Content-Type: multipart/mixed; boundary="------------1103AFE24E6F0A09E1E9B57A" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------1103AFE24E6F0A09E1E9B57A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrew Krywaniuk wrote: > Yeah, but many of us have also implemented Hybrid. You're right that not > doing any more work would be my first choice, but you're wrong about what > that implies. My second choice would still be CRACK, which would involve > rewriting all our code just to get a less flexible but functionally > equivalent alternative to Hybrid. What does that imply? What are the many who have implemented Hybrid? I enclose the questionnaire results that Will Price collected in January, and you can see that only two of those said they do Hybrid. I voted for PIC because my understanding is that touching IKE is a no-no, ruling out all these protocols. If IKE can be changed (I want area directors to state this, please), I might vote differently. In particular I might vote for some combination of PIC and CRACK. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Integrated Solutions for Enterprise Security --------------1103AFE24E6F0A09E1E9B57A Content-Type: application/zip; name="XauthInterop.xls.zip" Content-Disposition: inline; filename="XauthInterop.xls.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIADdeLyp6DqkLtA4AAAA4AAAQABAAWGF1dGhJbnRlcm9wLnhscwUnDABaUElU WExTOFhDRUzsW31sFMcVn93b+9i9wxzGYAPGXsyXvzBnG4JDmmAC4UMN4GBCqEoEh72EK/ad fT7zITWJ2yYSrdrKUdKkalDDRxqlTZrQNmmDFJqDWCqJSANto9A2qkhRlbbKH6QhbSIRru/N zr69OdaRcR01bTKr2X3vzZuZ33szO/t25+70qxPOHfzJ1DdZQbqB+djlnM4CeTJFZJ6ijJUK /nIul3PEuc/S/1T6EPJUGDcfZA2yHzKOeRByCLIO2YAchhyBPA5yEeTx9hRgEyAXQ54IuQTy JMiTxZzAPCWP/ix98hJbX3jnX11SYcY4banAmyGVy7N28QpJ+d3P3fm3u7JKGRMTDtJtLMXS bCfbBtcUXK82FTNVwXlL9owIM8z1Gpv2s3bWz7rhiAOOvWw1S7LtHBNKMiwBdPIj2qqG/hVh zkj7x6QpTv/LoYcOjsGCnjJXiacF+pfGcwQJ7/GI6F8PReGG97O1laeC0QEgQf4meOiIdpz7 6c+QN7MeXANuS3R1mW3pRIdlfvzpRo4hriCG65UAPGdU8PF+OBexKRxZMT9P5Oenud7ztjaU 4Eq0fA2raOE2KmyT2sr1vsXPVXBWoB08/4LX+QOXN0K9CyDL3f28PYkrNbbK6trVCCvaM5I8 wFZaSWtX3C5RoWRQ8SrxDVuHedYpYSelEqd/lHvhQrx+WJdRrlwhn1Ugr9DKQQpP7apZVTPr Z86Mbam5bnO1w2yuqdBmwNpfLpV/cb3VebusVAUPh+muUkNMbgd41JoLj4+qQq2C1oTqIlbL mhjbgvJa0+lZsJurRceOoGpeFS9t3QJVG1gNHFA1v55cqaDGElbPFsud2djk/ji0vC6XLHGb uIbVwVxxO3XqX1G5oOY5Pi8Zey9XnXc3Zk2UK1xuMnZxZHL1KuXsUyhX2JV+9sPYcf33C+U1 w8jrh5HXesoxXrqIq3ABntAwcj/U8Gon4OAPFcobbXlkGPklWR4cpp3gsO2wK9q5X9VYdMCX w+uEwQC/Fg9q/DpxMMivJYM6v04aDPErG2T8OnnAn9uq4Ep7L6y4f8HwEfpo32FZmUaU/H1O nqQJJf+amydp/iZEpQocT8FT3scUrRQMcd5Bytg0NgPghhm9l4y7Ds9ok8GOK6B6HMsS8Uss q3YDuYDx0HZZqrsnntwLem3pVGd/R8ZcG++2oGCjle5LpJIAc1O8P7PDFDxEvO1WsrMP+GRn Kr16OUywW5OdUJiJ54sh+l2TSCa6+7tNqT7K43uulIOfNuztsWDStO9I9JjL4xkLAuv2/p6e VDrTZ67auy2d6KxgbH28J9HZnklb8W6z3eroTycye82lPT1diXiywwL711tdVrzPMpsbYhCJ fMHqA1tWQmu743thRVibAvaWRrMpFmuMoinQgmWiE/ozieQdYakDeNK3Jzqt3Qm0D4oWNjSa dWZbPNOxA1pZ2tUBzXYVUysb29aaoid0bH86bSUzYNDK2+Yv60oA7cP+d0PMsSzR15GC1rGG XRTBoCLZ3CTYSaIsBTYlM+l4JpU2m2MxtAjs8ipdCKUw8kvg7WP1unZzfao/Y6XN9tT2zO54 2oIp39jU0NTQ3LABHN2eSiWhpbbVm3xo1AJA2x7fbq21MuOJmo9V57V93s/NbohBCyvm2YaO c0m0uU5DleYYOraJOxYn08o2Gp4Sm11u9e3MpHpIDC0vaog1NBc7pteZa+IdwgFw893c32E7 ZmlHh9XXZ7alEtyFYEWONWkh9m4A57dx/i7o+SGm975l3+FsI2BNwfUEXP8I18kwBvNVo3IP XO9T9aH9GdBrMioPP476+qkLN+pDLxfrZ5Kn74aw0ah85LRR+f279KGXHsE7SD+zqwvyPv3M bk1/o9Wug3z2tSO8/NgLZ43zdxwAUsvl3jpgnF/XqvfeUqr3tu2HtgaNyoMPwPUI5CfF3amA rMyoPHAz1jfOrzitHxsYBDIn2teEzh7UsdtW70e50GNG5YtDiFfo5qeMuJ70wPd2LvdPvoTp vTeljfOJVdVMq0aMTrtcf+hom1H5p0aP+nNyuYtZwLQPbPst2mdj4fY96dgHfBTtywfltK/3 bnxJ791wydY5lIFrPWZmf0EJwZg8Cu/TW+BlKcG6wBYLov3lPNqPw3tRnPWBhI/Jzqw3vne2 4rKo9976DPZj4zuUcVZF6Ot94DfxK/odxhHrCnwuBn5FvcOPi7Z5P3l+Il3wQ9TpB9p9FP0h /JC1+zv80zxXBBzcoL/KbuPg2VzuzXPYFuQfOfPNHouTz3BbYe6JOjBehx/Th17HOXBC770j bPd16CRkLP+y/uPrn2P2ah/CvkDWgnNe3/HtHm5v5aHnnPahrSed8QG62pmPgCdrnF+9FeX6 mWfFOB+uxvaFP6VxJf7MrhbUy2vP9hHHa8vl6eq8/Np4ue4bczL6ma+X6UMPn+K2Ay/a3id8 1IUV9Fe6LyI253UP/HEUchbKWrA/KH8D2wf9J2xf4scb+yUvKr3khVV3suJD8wfwjLt9KmOv TsePPPjAjsC5EyYm0hN4YBmFWXbph+/8Zs22tiVbuLyWy+v4+atcMuBGGmw2BgKsTPkKlBzX nM9DX+Pa9/DzQXxHUJQyhT/kNXZMP/uCXffcEufaq98Kuga704lVihAT05DHWgcmIa/xchWO gVAZlfvgGAi45Roc2aBb3w/HAd0tD8AxYLjlQThaw255CI78+joc5/LqG3Dk1w/jPVhklw/y D2e4XIvwQ2dqEfnf/sQWUqOC7oImTj/bqgwOoEzhsgtwPsIGlNIsylQuOwdFf70BZFzPR3p+ 1GtFmebW/Q7IeB9+kp1+1qkb8OgjSDK3jxDJ2INOHzph4TLeh0F6UdILk14y5ehFSC/2oNPH OJL1fNfRKyLZVmpvPMlU1akb5Z8KUGZS3Qkki5GsmGRZkk0kmUL+KyEZY47eJA/ZZJLd854j KyVZ21EHXxnJzr7g9DGFZAfiTt2pJNM1RzaNZGWa0145yd7e5YzbdJK541ZBsscedvqtJNnW h7CPD/moMTaVn21OAU4hTuUYHM4HZT7iNOA04vzA+YkLABcgLghckLgQcCHidOAM4gzgdMEh ilK+hticAtxk4lTwLD6g7lKR83G6pNUu04AbT5p+wR2DOaAAKlvTPgeFTgikZVRDl+obwE0R nMoxTSUOMU0jDjFVCEyqwFTWapchpnGk6RfcMT4vA0LTPgeFDmIqpxr5mFSOKSo4n4TJxzFN Jy4fk0/C5JMw+SRMPoGJSZh8HFMR1cjH5JMwaRImjWOqJE4Ff5oCkyZh0jgmkzT9EheQuKDE 5SPTOLJxxOUj80vI/BzZDOIQWZVA5peQ+SVv+SVv+YW3QpK3/BImv+QtP8c0U3ABCVOAY5pF HGKaLTAFJEwBaaYHpJke8MQUkDAFJEwBCVOQY6ohDjHVEoeY6gSmoIQpKPkpKPkp6DmrgtLd F5QwBTmmesHhqlGOH+MEpwDXRBxiahaYQoCpnDCFAFM5tRkCTOWEKWR/BAU/ledhwid/OfkJ om2pvgGcsyLoHNM84hBTA3GIab7ApEuYdI5pHGnmY9IFpjIJk84xxaiGLtXPx2TwsSsmDscu TByuCBGByZDGzpDGzpDGzvBcpQxpPhnS2BnSfRfmmOYQh5jmEod+qhaYwhKmsIQpLGEKC0xR CVNYWjnDEqawtJpHOKYJxCGmicShn0oEpoiEKSJhikiYItITxsEUkfwUkTBFyE+KGuDReBmn iogaT1SUqAlEFRM1kagSoiYRNZmoUqLKiJpC1FSiphFVTtR0oiqIquTU6/Aa+2uYel3q99gD /HCu7mGM4MBIxaRIxY1YZ5DMjVirPCKfmSRzo+JZbl2Kimd79DHHo4+5Hn1UuxEhRac1soz3 UUsyNyquI5kbFde7EStFxfNI5kbFDW4ER+3NJ5kbFcc8ouJGj6i4ySMqbvaIihd4RMALPWTX eETFizyi4haPqPhaj6h4cUFUjLPNpHk3g6gqomYSNYuo2UTNIWouUdVE1RBVS1QdUfVEzSOq gaj5RMWIaiSqiahmohYQtZCoa4haRFQLUdcStVjccYtZrQ/fI0dyXxUeN6jF7Of8Fz+tzE3T YbVxPlgI0fFQLWQU4iKHi2iE6G+gAkaZKgRWNyf6Mo0nQs+zE6RtJ5cyeWDhvBPz1RWG196x HP3HtZNCT+ykstzdbNjkfEwJSPtFkB4sZVlTAezHCb8ifOBSpv1ZIn8jQTZi9PjH1gh3EFSm CiMcSgyC2JYQ+Cts/P+hEWOG/wTh94n56FKmPaGkzRUmjcLo8Y+tFS+SFZr4jO1SJo8HCraa ZDNGb8XYmvESmeHnL1D5lGnvv3ptkMnGjN6MsTXmZTImIH7w6FIm/97gva0nWzN6Yz4ua4L2 XZ1HOdZ4bUZ+Mq05StaExJdllzLt+wa3UGXwo7dmbMEPEXidvxbmUyYP9ws3e2XYowc/tnb8 kuywXyXzKdO2hzawvSwYjR1jacHwmyBRSf3Q3P/m5oeb3M2PdiZtfijO5oezdeAmHrxxqjVP 6hG8jdQZT1d/0pzB2j8WZ3yaE/oB3e/8/vsyv4vk33+jLCyun6X/r3Q5h7vFiue8OHfvI//4 YN2O6BP3hVjd3J/9Pgay34l5geWrxNxpE3MHd6wxAtwndPAXAfjJEX/dgTdsltn/Ezgl6kVh tcWNCPzMvWmpHYlgmGiuTmasdKrHxLdH1pFGHZx/7g+QGZdx1CAbrjzKMG7rSKf6Utsz5k17 OqwuezmITLnwq71ZxTcG989H+U997ZXX9jdMi97/EPiv/oOn0H+4O6+LcvQbxgCbmP3Lih3C jh6BfY/w1wCz/1OBfsXXnEHhz6MFfkTfr71pw1J8GKNtr+o6b4+Jdr2uFVH73sf73f5Vnks2 uWQzi0TtzsjZqfTOPizq4/VH60sFPIgPC5yLhf8dwHlRMH4mdctXo5YVq2/EpZ+XNXCkDS2j RPLpTApbxlKsG+bcOraNfemq6+On5vz1ZCR18Jm76ap7Gj5dbf9jnf6X+//3AFBLAQIUBxQA AAAIADdeLyp6DqkLtA4AAAA4AAAQABAAAAAAAAAAAAAAAAAAAABYYXV0aEludGVyb3AueGxz BScMAFpQSVRYTFM4WENFTFBLBQYAAAAAAQABAE4AAADyDgAAAAA= --------------1103AFE24E6F0A09E1E9B57A-- From owner-ietf-ipsra@mail.vpnc.org Mon May 7 11:06:24 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13893 for ; Mon, 7 May 2001 11:06:23 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA29686 for ietf-ipsra-bks; Mon, 7 May 2001 07:26:08 -0700 (PDT) Received: from relay2.nai.com (relay2.nai.com [161.69.3.67]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA29681 for ; Mon, 7 May 2001 07:26:07 -0700 (PDT) Received: from scwsout1.nai.com (webshield2.nai.com [161.69.3.73]) by relay2.nai.com (8.9.3/8.9.3) with SMTP id HAA12424 for ; Mon, 7 May 2001 07:25:38 -0700 (PDT) Received: FROM ca-ex-bridge2.nai.com BY scwsout1.nai.com ; Mon May 07 07:25:37 2001 -0700 Received: by dns-31.dhcp-5.nai.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 07:36:08 -0700 Message-ID: <8894CA1F87A5D411BD24009027EE78381280C7@md-exchange1.nai.com> From: "Mason, David" To: "'Ari Huttunen'" , andrew.krywaniuk@alcatel.com Cc: ietf-ipsra@vpnc.org Subject: RE: Results of protocol straw poll Date: Mon, 7 May 2001 07:25:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The purpose of IKE is to provide internet authentication and key exchange. I never understood why support for remote access requirements should be excluded from it. Fulfilling remote access requirements adds complexity. What's the logic behind dividing that support (and complexity) between four entities (IKE, legacy system, CA, and new protocol) being more secure than doing it between three entities (IKE, legacy system, and CA)? It's ironic that the first two paragraphs of section 2 of RFC 2409 (IKE) mention "hybrid protocol" and support for remote user access. -dave -----Original Message----- From: Ari Huttunen [mailto:Ari.Huttunen@f-secure.com] Sent: Sunday, May 06, 2001 12:12 PM To: andrew.krywaniuk@alcatel.com Cc: ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll Andrew Krywaniuk wrote: > Yeah, but many of us have also implemented Hybrid. You're right that not > doing any more work would be my first choice, but you're wrong about what > that implies. My second choice would still be CRACK, which would involve > rewriting all our code just to get a less flexible but functionally > equivalent alternative to Hybrid. What does that imply? What are the many who have implemented Hybrid? I enclose the questionnaire results that Will Price collected in January, and you can see that only two of those said they do Hybrid. I voted for PIC because my understanding is that touching IKE is a no-no, ruling out all these protocols. If IKE can be changed (I want area directors to state this, please), I might vote differently. In particular I might vote for some combination of PIC and CRACK. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Integrated Solutions for Enterprise Security From owner-ietf-ipsra@mail.vpnc.org Mon May 7 11:26:32 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14265 for ; Mon, 7 May 2001 11:26:31 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id HAA00934 for ietf-ipsra-bks; Mon, 7 May 2001 07:56:10 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA00928 for ; Mon, 7 May 2001 07:56:08 -0700 (PDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 52EF61F123; Mon, 7 May 2001 10:56:06 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id KAA05884; Mon, 7 May 2001 10:56:05 -0400 (EDT) Received: from berkshire.research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id AA2EE7B7B; Mon, 7 May 2001 10:56:02 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "Mason, David" Cc: "'Ari Huttunen'" , andrew.krywaniuk@alcatel.com, ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 May 2001 10:56:02 -0400 Message-Id: <20010507145602.AA2EE7B7B@berkshire.research.att.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In message <8894CA1F87A5D411BD24009027EE78381280C7@md-exchange1.nai.com>, "Maso n, David" writes: >The purpose of IKE is to provide internet authentication and key exchange. >I never understood why support for remote access requirements should be >excluded from it. Fulfilling remote access requirements adds complexity. >What's the logic behind dividing that support (and complexity) between four >entities (IKE, legacy system, CA, and new protocol) being more secure than >doing it between three entities (IKE, legacy system, and CA)? The rationale for ruling out changes to IKE is not abstract; rather, it's that IKE is too complex already, and adding more stuff to it will make it much worse. It's always an engineering tradeoff to decide when to add new modules; I'll assert that for the last 25 years, the bulk of computer science opinion has been that composing simple building blocks is a better idea than building monolithic, complex ones. --Steve Bellovin, http://www.research.att.com/~smb From owner-ietf-ipsra@mail.vpnc.org Mon May 7 12:14:49 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15599 for ; Mon, 7 May 2001 12:14:48 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA05887 for ietf-ipsra-bks; Mon, 7 May 2001 08:40:24 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA05860 for ; Mon, 7 May 2001 08:40:18 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f47FeJa07157; Mon, 7 May 2001 08:40:19 -0700 (PDT) Received: from sfanningwork (dhcp-171-69-39-135.cisco.com [171.69.39.135]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AAE05158; Mon, 7 May 2001 08:39:38 -0700 (PDT) Message-ID: <003901c0d70b$a217e160$872745ab@cisco.com> From: "Scott Fanning" To: "Steven M. Bellovin" , "Mason, David" Cc: "'Ari Huttunen'" , , References: <20010507145602.AA2EE7B7B@berkshire.research.att.com> Subject: Re: Results of protocol straw poll Date: Mon, 7 May 2001 08:37:32 -0700 Organization: Cisco Systems 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.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I thought IKE (ISAKMP) was a framework? From RFC 2408 "ISAKMP is designed to provide a flexible and extensible framework for establishing and managing Security Associations and cryptographic keys. The framework provided by ISAKMP consists of header and payload definitions, exchange types for guiding message and payload exchanges, and general processing guidelines. ISAKMP does not define the mechanisms that will be used to establish and manage Security Associations and cryptographic keys in an authenticated and confidential manner. The definition of mechanisms and their application is the purview of individual Domains of Interpretation (DOIs)." Notice the word "extensible". So, maybe remote access should be its own DOI? I agree with Steve that the reduction of complexity is an important goal, especially in the world of security. However, I would argue that if we got rid of the vague descriptions of rekeying, Phase 1 lifetime negotiation (or lack of it), and commit bit fun, I am sure there would be room for the complexity of a remote access mode. My two cents. Scott ----- Original Message ----- From: "Steven M. Bellovin" To: "Mason, David" Cc: "'Ari Huttunen'" ; ; Sent: Monday, May 07, 2001 7:56 AM Subject: Re: Results of protocol straw poll > In message <8894CA1F87A5D411BD24009027EE78381280C7@md-exchange1.nai.com>, "Maso > n, David" writes: > >The purpose of IKE is to provide internet authentication and key exchange. > >I never understood why support for remote access requirements should be > >excluded from it. Fulfilling remote access requirements adds complexity. > >What's the logic behind dividing that support (and complexity) between four > >entities (IKE, legacy system, CA, and new protocol) being more secure than > >doing it between three entities (IKE, legacy system, and CA)? > > The rationale for ruling out changes to IKE is not abstract; rather, > it's that IKE is too complex already, and adding more stuff to it will > make it much worse. > > It's always an engineering tradeoff to decide when to add new modules; > I'll assert that for the last 25 years, the bulk of computer science > opinion has been that composing simple building blocks is a better idea > than building monolithic, complex ones. > > > --Steve Bellovin, http://www.research.att.com/~smb > > From owner-ietf-ipsra@mail.vpnc.org Mon May 7 12:24:00 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15780 for ; Mon, 7 May 2001 12:23:57 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA07874 for ietf-ipsra-bks; Mon, 7 May 2001 08:48:42 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA07860 for ; Mon, 7 May 2001 08:48:40 -0700 (PDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id BD61B1EAF5; Mon, 7 May 2001 11:48:41 -0400 (EDT) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA07073; Mon, 7 May 2001 11:48:40 -0400 (EDT) Received: from berkshire.research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 1AA4F7B7B; Mon, 7 May 2001 11:48:36 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "Scott Fanning" Cc: "Mason, David" , "'Ari Huttunen'" , andrew.krywaniuk@alcatel.com, ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 May 2001 11:48:36 -0400 Message-Id: <20010507154836.1AA4F7B7B@berkshire.research.att.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In message <003901c0d70b$a217e160$872745ab@cisco.com>, "Scott Fanning" writes: >I thought IKE (ISAKMP) was a framework? > >>From RFC 2408 > > "ISAKMP is designed to provide a > flexible and extensible framework for establishing and managing > Security Associations and cryptographic keys. The framework provided > by ISAKMP consists of header and payload definitions, exchange types > for guiding message and payload exchanges, and general processing > guidelines. ISAKMP does not define the mechanisms that will be used > to establish and manage Security Associations and cryptographic keys > in an authenticated and confidential manner. The definition of > mechanisms and their application is the purview of individual Domains > of Interpretation (DOIs)." > >Notice the word "extensible". > Of course, even back in the days of the Photuris/SKIP/ISAKMP stand-off (and before Oakley) there were those who warned of the complexity of ISAKMP. I was one of them; I was hardly the only one. Should IKE/ISAKMP have become an RFC? That's water over the dam at this point; we have it. The question is what to do now. --Steve Bellovin, http://www.research.att.com/~smb From owner-ietf-ipsra@mail.vpnc.org Mon May 7 12:24:22 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15793 for ; Mon, 7 May 2001 12:24:22 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA06618 for ietf-ipsra-bks; Mon, 7 May 2001 08:43:49 -0700 (PDT) Received: from relay2.nai.com (relay2.nai.com [161.69.3.67]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA06605 for ; Mon, 7 May 2001 08:43:47 -0700 (PDT) Received: from scwsout1.nai.com (webshield2.nai.com [161.69.3.73]) by relay2.nai.com (8.9.3/8.9.3) with SMTP id IAA21401 for ; Mon, 7 May 2001 08:43:18 -0700 (PDT) Received: FROM ca-ex-bridge1.nai.com BY scwsout1.nai.com ; Mon May 07 08:43:15 2001 -0700 Received: by dns-23.dhcp-5.nai.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 08:43:17 -0700 Message-ID: <8894CA1F87A5D411BD24009027EE78381280C8@md-exchange1.nai.com> From: "Mason, David" To: "'Steven M. Bellovin'" , "Mason, David" Cc: "'Ari Huttunen'" , andrew.krywaniuk@alcatel.com, ietf-ipsra@vpnc.org Subject: RE: Results of protocol straw poll Date: Mon, 7 May 2001 08:42:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If IKE is too complex it should never have been advanced to RFC (which I agree with to a certain degree). I agree with modular building blocks but there is no reason that there can't be different building blocks within IKE. I would think that using a single transport protocol (ISAKMP/IKE) for these separate "modules" is less complex than using a different transport protocol for each module (authentication, key exchange, ID assignment, access request, etc). Each one of these modules is complex within itself. Since they are done together under one transport (IKE), people label IKE as too complex. Using a different transport for each step will not make the whole thing any less complex (it will actually do the reverse in my opinion). I found that the implementation of XAuth was extremely modular within IKE. Has anybody else found that it wasn't? -dave -----Original Message----- From: Steven M. Bellovin [mailto:smb@research.att.com] Sent: Monday, May 07, 2001 10:56 AM To: Mason, David Cc: 'Ari Huttunen'; andrew.krywaniuk@alcatel.com; ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll In message <8894CA1F87A5D411BD24009027EE78381280C7@md-exchange1.nai.com>, "Maso n, David" writes: >The purpose of IKE is to provide internet authentication and key exchange. >I never understood why support for remote access requirements should be >excluded from it. Fulfilling remote access requirements adds complexity. >What's the logic behind dividing that support (and complexity) between four >entities (IKE, legacy system, CA, and new protocol) being more secure than >doing it between three entities (IKE, legacy system, and CA)? The rationale for ruling out changes to IKE is not abstract; rather, it's that IKE is too complex already, and adding more stuff to it will make it much worse. It's always an engineering tradeoff to decide when to add new modules; I'll assert that for the last 25 years, the bulk of computer science opinion has been that composing simple building blocks is a better idea than building monolithic, complex ones. --Steve Bellovin, http://www.research.att.com/~smb From owner-ietf-ipsra@mail.vpnc.org Mon May 7 13:54:01 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18198 for ; Mon, 7 May 2001 13:54:00 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA15726 for ietf-ipsra-bks; Mon, 7 May 2001 10:16:06 -0700 (PDT) Received: from potassium.cips.nokia.com (Potassium.Network-Alchemy.COM [209.249.246.78]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA15721 for ; Mon, 7 May 2001 10:16:04 -0700 (PDT) Received: from potassium.cips.nokia.com (localhost [127.0.0.1]) by potassium.cips.nokia.com (8.11.1/8.11.1) with ESMTP id f47HFCA08654; Mon, 7 May 2001 10:15:12 -0700 (PDT) (envelope-from dharkins@potassium.cips.nokia.com) Message-Id: <200105071715.f47HFCA08654@potassium.cips.nokia.com> To: Ari Huttunen cc: andrew.krywaniuk@alcatel.com, ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll In-Reply-To: Your message of "Sun, 06 May 2001 19:12:15 +0300." <3AF577DF.1558C249@F-Secure.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8651.989255712.1@potassium.cips.nokia.com> Date: Mon, 07 May 2001 10:15:12 -0700 From: Dan Harkins Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Touching IKE seems to be allowed if you say, "I am not touching IKE" and then proceed to touch IKE. The Group DOI draft in the MSEC WG does exactly what XAUTH did (create another post-phase 1 exchange). That is permissible while XAUTH/Hybrid is not for some strange reason. Comparing PIC and CRACK is also interesting. Both use UDP/500. Both add and define payloads. One (which one?) looks like this: hdr, sa, ke, ni ----> <---- hdr, sa, ke, nr, id, sig, hash, hdr, hash, ----> <---- hdr, hash, repeat last two as needed while the other (which one?) looks like this: hdr, sa, ke, ni ----> <---- hdr, sa, ke, nr, id, sig hdr, ----> <---- hdr, repeat last two as needed One of these is a change to IKE while the other is not. The main difference between the two seems to be that with PIC you get an authenticated Diffie-Hellman and then throw it away and get another authenticated Diffie-Hellman before you start doing IPsec while with CRACK you get an authenticated Diffie-Hellman and then start doing IPsec. But PIC is very IKE-like. It uses the same payloads. It listens on the same port. Given these facts it seems a little disingenuous to keep saying that PIC is not changing IKE but CRACK is. Both would end up doing almost exactly the same thing. You'd touch almost exactly the same chunks of code to write each one and IKE would end up being changed in exactly the same way. Dan. On Sun, 06 May 2001 19:12:15 +0300 you wrote > > I voted for PIC because my understanding is that touching IKE is a no-no, rul >ing > out all these protocols. If IKE can be changed (I want area directors to stat >e > this, please), I might vote differently. In particular I might vote for some > combination of PIC and CRACK. From owner-ietf-ipsra@mail.vpnc.org Mon May 7 14:23:06 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18752 for ; Mon, 7 May 2001 14:23:05 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id KAA19605 for ietf-ipsra-bks; Mon, 7 May 2001 10:44:54 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA19598 for ; Mon, 7 May 2001 10:44:52 -0700 (PDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f47HiUQ19444; Mon, 7 May 2001 10:44:30 -0700 (PDT) Received: from sfanningwork (dhcp-171-69-39-135.cisco.com [171.69.39.135]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AAF02724; Mon, 7 May 2001 10:44:22 -0700 (PDT) Message-ID: <008e01c0d71d$0ee7a760$872745ab@cisco.com> From: "Scott Fanning" To: "Steven M. Bellovin" Cc: "Mason, David" , "'Ari Huttunen'" , , References: <20010507154836.1AA4F7B7B@berkshire.research.att.com> Subject: Re: Results of protocol straw poll Date: Mon, 7 May 2001 10:42:16 -0700 Organization: Cisco Systems 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.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Well, I would be interested in seeing the Son-of-IKE progress. I think there has been many lessons learned. If there is some forum we could all brainstorm some of the issues we have had with IKE (Maybe some sort of IETF IPSec WG sub-committee), and work together, then I think that would be the way to go. Scott ----- Original Message ----- From: "Steven M. Bellovin" To: "Scott Fanning" Cc: "Mason, David" ; "'Ari Huttunen'" ; ; Sent: Monday, May 07, 2001 8:48 AM Subject: Re: Results of protocol straw poll > In message <003901c0d70b$a217e160$872745ab@cisco.com>, "Scott Fanning" writes: > >I thought IKE (ISAKMP) was a framework? > > > >>From RFC 2408 > > > > "ISAKMP is designed to provide a > > flexible and extensible framework for establishing and managing > > Security Associations and cryptographic keys. The framework provided > > by ISAKMP consists of header and payload definitions, exchange types > > for guiding message and payload exchanges, and general processing > > guidelines. ISAKMP does not define the mechanisms that will be used > > to establish and manage Security Associations and cryptographic keys > > in an authenticated and confidential manner. The definition of > > mechanisms and their application is the purview of individual Domains > > of Interpretation (DOIs)." > > > >Notice the word "extensible". > > > Of course, even back in the days of the Photuris/SKIP/ISAKMP stand-off > (and before Oakley) there were those who warned of the complexity of > ISAKMP. I was one of them; I was hardly the only one. > > Should IKE/ISAKMP have become an RFC? That's water over the dam at > this point; we have it. The question is what to do now. > > --Steve Bellovin, http://www.research.att.com/~smb > > From owner-ietf-ipsra@mail.vpnc.org Mon May 7 15:47:41 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20659 for ; Mon, 7 May 2001 15:47:40 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id MAA25896 for ietf-ipsra-bks; Mon, 7 May 2001 12:13:56 -0700 (PDT) Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75]) by above.proper.com (8.9.3/8.9.3) with SMTP id MAA25892 for ; Mon, 7 May 2001 12:13:54 -0700 (PDT) Received: (qmail 14656 invoked from network); 7 May 2001 19:11:46 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 7 May 2001 19:11:46 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Mon, 7 May 2001 15:10:36 -0400 Received: from andrewk3 ([138.120.49.38]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAABFA; Mon, 7 May 2001 15:10:35 -0400 Reply-To: From: "Andrew Krywaniuk" To: "'Dan Harkins'" Cc: Subject: RE: Results of protocol straw poll Date: Mon, 7 May 2001 14:40:39 -0400 Message-Id: <000901c0d728$c4ab05a0$2631788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: <200105071715.f47HFCA08654@potassium.cips.nokia.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Touching IKE seems to be allowed if you say, "I am not > touching IKE" and > then proceed to touch IKE. The Group DOI draft in the MSEC WG > does exactly > what XAUTH did (create another post-phase 1 exchange). That > is permissible > while XAUTH/Hybrid is not for some strange reason. The other way to improve your chances of having your protocol advanced seems to be to explicitly name it "simple-". Maybe you should submit a draft for S-CRACK and see if that garners any more acceptance. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ietf-ipsra@mail.vpnc.org Tue May 8 11:52:43 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28832 for ; Tue, 8 May 2001 11:52:42 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id IAA02695 for ietf-ipsra-bks; Tue, 8 May 2001 08:08:32 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA02690 for ; Tue, 8 May 2001 08:08:30 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 May 2001 08:08:24 -0700 Received: from redcreek.com (SKELLYLAPTOP [209.125.38.151]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8BCZX; Tue, 8 May 2001 08:08:20 -0700 From: "Scott G. Kelly" To: Dan Harkins Cc: Ari Huttunen , andrew.krywaniuk@alcatel.com, ietf-ipsra@vpnc.org Message-ID: <3AF80BE2.BE275246@redcreek.com> Date: Tue, 08 May 2001 08:08:18 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Results of protocol straw poll References: <200105071715.f47HFCA08654@potassium.cips.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Dan, Comments below... Dan Harkins wrote: > > Comparing PIC and CRACK is also interesting. Both use UDP/500. Both add > and define payloads. One (which one?) looks like this: > > hdr, sa, ke, ni ----> > <---- hdr, sa, ke, nr, id, sig, hash, > hdr, hash, ----> > <---- hdr, hash, > > repeat last two as needed > > while the other (which one?) looks like this: > > hdr, sa, ke, ni ----> > <---- hdr, sa, ke, nr, id, sig > hdr, ----> > <---- hdr, > > repeat last two as needed > > One of these is a change to IKE while the other is not. > > The main difference between the two seems to be that with PIC you get an > authenticated Diffie-Hellman and then throw it away and get another > authenticated Diffie-Hellman before you start doing IPsec while with CRACK > you get an authenticated Diffie-Hellman and then start doing IPsec. > > But PIC is very IKE-like. It uses the same payloads. It listens on the same > port. Given these facts it seems a little disingenuous to keep saying that > PIC is not changing IKE but CRACK is. Both would end up doing almost exactly > the same thing. You'd touch almost exactly the same chunks of code to write > each one and IKE would end up being changed in exactly the same way. > > Dan. > One significant difference is that CRACK must run on the sgw, while PIC may not. This is not meant as an endorsement of PIC over CRACK, but simply a statement of a difference. I'm working on a (brief) draft comparing the various proposed alternatives which I should be able to get out to the list within the next few days. This should aid us in this discussion. Scott From owner-ietf-ipsra@mail.vpnc.org Tue May 8 14:23:24 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03937 for ; Tue, 8 May 2001 14:23:23 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA16248 for ietf-ipsra-bks; Tue, 8 May 2001 10:29:06 -0700 (PDT) Received: from perfero.tnc.virtela.cc ([12.41.66.116]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA16243 for ; Tue, 8 May 2001 10:29:04 -0700 (PDT) Received: from posthaus.virtela.cc ([172.16.97.7]) by perfero.tnc.virtela.cc (8.9.3/8.9.3) with ESMTP id KAA07937 for ; Tue, 8 May 2001 10:28:30 -0700 Received: by posthaus.virtela.cc with Internet Mail Service (5.5.2650.21) id ; Tue, 8 May 2001 11:28:30 -0600 Message-ID: From: "Horn, Mike" To: ietf-ipsra@vpnc.org Cc: "Horn, Mike" Subject: RE: Results of protocol straw poll Date: Tue, 8 May 2001 11:28:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Having watched this list for ~ 9 months it is frustrating as an IPSec technology deployer to see the constant quagmire the ipsra working group seems to be stuck in. Currently working in a multi-vendor IPSec environment is painful due to the lack of standards. For instance in order to support remote client applications there are three important issues: 1. Support for legacy user based authentication systems (primarily Radius) 2. Support for a "keepalive" mechanism 3. Support for dynamic client configuration Of these, all have been documented with one or more drafts, but none have been standardized (DHCP does seem to be getting close). It seems the development community has gone around the working group and has tried to meet the user community's needs by implementing expired drafts like XAUTH. This makes it very difficult to push multiple vendors to interoperability and leaves the question of on-going support for the draft implementations unanswered. I know that there is a mandate to not change IKE, but it doesn't even seem like this issue will be fixed with a "Son of IKE" standard. I would hope that the working group(s) (both ipsra and ipsec) recognize the need to change the way future solutions are developed so that as new technologies are designed the existing protocols are extensible to support new technologies. Since I'm not a developer I didn't think I should really vote in the PIC vs. GetCert straw poll, but my vote would be for PIC (if existing solutions like XAUTH, CRACK, etc. are excluded from the poll). Mike Horn -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Tuesday, May 08, 2001 9:08 AM To: Dan Harkins Cc: Ari Huttunen; andrew.krywaniuk@alcatel.com; ietf-ipsra@vpnc.org Subject: Re: Results of protocol straw poll Hi Dan, Comments below... Dan Harkins wrote: > > Comparing PIC and CRACK is also interesting. Both use UDP/500. Both add > and define payloads. One (which one?) looks like this: > > hdr, sa, ke, ni ----> > <---- hdr, sa, ke, nr, id, sig, hash, > hdr, hash, ----> > <---- hdr, hash, > > repeat last two as needed > > while the other (which one?) looks like this: > > hdr, sa, ke, ni ----> > <---- hdr, sa, ke, nr, id, sig > hdr, ----> > <---- hdr, > > repeat last two as needed > > One of these is a change to IKE while the other is not. > > The main difference between the two seems to be that with PIC you get an > authenticated Diffie-Hellman and then throw it away and get another > authenticated Diffie-Hellman before you start doing IPsec while with CRACK > you get an authenticated Diffie-Hellman and then start doing IPsec. > > But PIC is very IKE-like. It uses the same payloads. It listens on the same > port. Given these facts it seems a little disingenuous to keep saying that > PIC is not changing IKE but CRACK is. Both would end up doing almost exactly > the same thing. You'd touch almost exactly the same chunks of code to write > each one and IKE would end up being changed in exactly the same way. > > Dan. > One significant difference is that CRACK must run on the sgw, while PIC may not. This is not meant as an endorsement of PIC over CRACK, but simply a statement of a difference. I'm working on a (brief) draft comparing the various proposed alternatives which I should be able to get out to the list within the next few days. This should aid us in this discussion. Scott From owner-ietf-ipsra@mail.vpnc.org Wed May 9 18:23:48 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27527 for ; Wed, 9 May 2001 18:23:48 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA20852 for ietf-ipsra-bks; Wed, 9 May 2001 14:49:52 -0700 (PDT) Received: from pavilion (a24b31n80client230.hawaii.rr.com [24.31.80.230]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA20840 for ; Wed, 9 May 2001 14:49:50 -0700 (PDT) Message-ID: <97752001539214146150@pavilion> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "Mitchell" To: ietf-ipsra@vpnc.org Subject: Business/Employment Opportunity Date: Wed, 9 May 2001 11:41:46 -1000 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id OAA20844 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Dear Friend: "Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time" THANKS TO THE COMPUTER AGE AND THE INTERNET! =============================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say "Bull" , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely no laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost". DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: "Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in". Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------------------- Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program,I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything ." More testimonials later but first, ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ******* $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. **** Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****.IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY ! ========================================================= Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY ============================================ let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ------------------------------------------------------------------------------ REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 250 million people on the internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET =================================================== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _____________________ AVAILABLE REPORTS_____________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================== REPORT #1, "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #1 FROM: G. Donaldson P.O. Box 25884 Honolulu, Hawaii 96825-0884 don't forget to provide a permanent e-mail address in clear writing (better typed) to receive the reports. We had problems in delivery e-mails before!!! ============================================== REPORT #2 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #2 FROM: Vijay Paul C-291, Second Floor Defence Colony New Delhi - 110024 INDIA ============================================== REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: JD P.O.Box 1114 Des Plaines, IL 60017 USA ============================================== REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: J Santi 833 Walter Ave Des Plaines, IL 60016 USA ============================================== REPORT #5 "How to SEND 1,000,000 e-mails for FREE" ORDER REPORT #5 FROM: Elaine Rix 138 Dundas Street, West, #243 Toronto, Ontario Canada M5G 1C3 ============================================== There are currently more than 250,000,000 people online worldwide! $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ____________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ************** MORE TESTIMONIALS **************** "My name is Mitchell. My wife , Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $ 147,200.00 all cash! I was shocked. I have joined Jody in her ''hobby''." Mitchell Wolf, Chicago, Illinois ------------------------------------------------------------ "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ----------------------------------------------------------- "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks". Susan De Suza, New York, N.Y. ---------------------------------------------------- "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet". Fred Dellaca, Westport, New Zealand ------------------------------------------------------------ ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is one time e-mail transmission. No request for removal is necessary. ------------------------------------------------------------ This message is sent in compliance of the new email Bill HR 1910. Under Bill HR 1910 passed by the 106th US Congress on May 24, 1999, this message cannot be considered Spam as long as we include the way to be removed. Per Section HR 1910, Please type "REMOVE" in the subject line and reply to this email. All removal requests are handled personally an immediately once received. From owner-ietf-ipsra@mail.vpnc.org Wed May 9 19:35:09 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29205 for ; Wed, 9 May 2001 19:35:08 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA26817 for ietf-ipsra-bks; Wed, 9 May 2001 16:12:17 -0700 (PDT) Received: from mail.bicea.net.cn ([210.72.225.107]) by above.proper.com (8.9.3/8.9.3) with SMTP id QAA26704; Wed, 9 May 2001 16:11:11 -0700 (PDT) From: x-word@yahoo.com Received: from yahoo.com by mail.bicea.net.cn (SMI-8.6/SMI-SVR4) id HAA18673; Thu, 10 May 2001 07:01:55 +0800 Subject: Samples!!! Date: Wed, 9 May 2001 19:09:06 Message-Id: <837.341771.896898@yahoo.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id QAA26817 Content-Transfer-Encoding: quoted-printable WORD PUZZLE LOVERS=97 =20 =20 =20 =20 =20 =20 =20 =20 =20
=20

= ~ WORD=20 PUZZLE LOVERS ~

 
=20

Do you like double acrostics?

We=20 Want To Send You, a FREE Sample?
=20

 

  • Do you like them big with lots of meat= in them?=20

Our puzzles average well over 250 letters. Most= published=20 puzzles have around 200.

 

  • Do you like them really tough and chal= lenging?=20

We dig deep for our clues and once in a while = we stick=20 in a real off-the-wall doozer

 
=20
If you answer YES,= we have=20 the acrostics for you!
=20

 

 

* We offer a subscription service.<= /u> *
=20
=20

Our= Subscribers=20 receive five new mind-ben= ders every=20 month

and they are delivered right into their m= ailbox.

 
=20
Would You Like us to Send= You, a FREE=20 Sample?
=20
=20

Yes, I want=20 to learn more about your Puzzles= .

Please click below

=20
=20

I am not interested; take me off your lis= t.

Please click=20 below
=20 =20
  =20     =20  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
=20
=20

 

 

 

 =20

Our=20 puzzles, [word puzzles for the connoisseur] start out with a lite= rary=20 quote. We use all the letters in the quote and create clues. The = first=20 letters of the clues spell out the author=92s name and the title = of the=20 source of the quote. The letters of the clue words are numbered a= nd correspond=20 to squares in the accompanying grid. Filling in the grid reveals = the quotation.=20

Sound=20 complicated?

Well=20 maybe a little, but that's where the solving fun comes in.

 

 

  
=20
=20
=20

Yes,=20 I want to learn more about your Puzzles and=20 I want to receive a FREE = sample.

Please=20 click below

 =20
=20

 
=20
=20  
=20 =20
=20

Please=20 include your Name and US Mailing Address including Zip Code.

 
=20
=20

 

I=20 am not interested; take me off your list.

Please=20 click below

  
=20
=20  

 

 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0   =20

From owner-ietf-ipsra@mail.vpnc.org Fri May 11 19:07:00 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22552 for ; Fri, 11 May 2001 19:06:59 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id PAA19576 for ietf-ipsra-bks; Fri, 11 May 2001 15:10:39 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA19571 for ; Fri, 11 May 2001 15:10:33 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id PAA15802; Fri, 11 May 2001 15:02:15 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 11 May 2001 15:02:15 -0700 (PDT) From: Bernard Aboba To: ietf-ipsra@vpnc.org cc: aboba@internaut.com Subject: comments on draft-ietf-ipsra-reqmts-03.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1. Introduction This section includes a large discussion relating to L2TP that seems to interrupt the flow of the document. Since this a requirements document for IPSRA, I'd suggest that this discussion be translated into requirements, be moved to an evaluation document comparing alternatives against requirements, or be taken out of the document altogether. In particular, this discussion makes points relating to machine versus user authentication and the security of RADIUS that are actually quite general, and not really L2TP related. However, as it stands the points are not well integrated with the rest of the document. For example, if RADIUS is so insecure as to be an issue with L2TP, then presumably it should also not be used in IPSRA to authenticate a temporary cert enrollment, so there are requirements implications here. Furthermore the arguments for user versus machine auth would also presumably apply to any VPN protocol. Both of these points need to be further developed. Since RADIUS insecurity is referred to, I think a reference is needed here. This might be to RFC 2607 or 2869 security considerations sections, but it's hard to tell from the context. If this is really a serious issue I think that it needs to be documented in detail in the requirements, so that we can understand how to avoid the concerns in IPSRA. 2. pp.8. I disagree with the definition of user authentication. Using a user's identity is not sufficient to truly implement user authentication within IPSEC. You also need to be able to separate user contexts so that one user cannot use the IPSEC SA opened under another user context. This is tricky to say the least, and implies negotiation of specific non-overlapping selectors. There's a good reason why most IPSEC implementations don't work this way -- doing this is hard. So I think we need to be careful to define what is meant here and what we are recommending that implementations need to do. I'd argue that merely using a user identity for authentication in IKE doesn't really give you much of a security advantage over machine auth, particularly if the machine cert is stored on a smart card. 3. Section 3.3.5 (page 28). It would appear that this section mandates NAT traversal for IPSRA. Is this the intent? If so, I think it's a good idea -- this is a real customer requirement. Note however, that if one also mandates true user auth and therefore specific selectors, then IPSEC tunnel won't meet the requirements without changes. From phoffman@above.proper.com Sun May 13 01:23:43 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27977 for ; Sun, 13 May 2001 01:23:42 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id WAA15724; Sat, 12 May 2001 22:23:43 -0700 (PDT) Date: Sat, 12 May 2001 22:23:43 -0700 (PDT) Message-Id: <200105130523.WAA15724@above.proper.com> To: ipsra-archive@ietf.org From: subs-reminder@vpnc.org Subject: Subscription for ipsra-archive@lists.ietf.org to the ietf-ipsra mailing list Greetings. This message is a periodic reminder that you are subscribed to the ietf-ipsra mailing list, and you are subscribed as: ipsra-archive@lists.ietf.org There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-ipsra mailing list, you do not need to do anyting. If you want to unsubscribe from this list, you can respond to this message and I will unsubscribe you. This may take a few days because it will be done by hand by a human. If you want to unsubscribe automatically, send a plain-text message to: ietf-ipsra-request@vpnc.org with the single word unsubscribe in the body of the message. If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-ipsra@mail.vpnc.org Mon May 14 23:00:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01435 for ; Mon, 14 May 2001 23:00:09 -0400 (EDT) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA26357 for ietf-ipsra-bks; Mon, 14 May 2001 19:25:54 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA26351 for ; Mon, 14 May 2001 19:25:47 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 May 2001 19:25:44 -0700 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JHZ8BSBN; Mon, 14 May 2001 19:25:33 -0700 From: "Scott G. Kelly" To: Bernard Aboba Cc: ietf-ipsra@vpnc.org Message-ID: <3B009353.24C86907@redcreek.com> Date: Mon, 14 May 2001 19:24:19 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: comments on draft-ietf-ipsra-reqmts-03.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Bernard, Thanks for taking the time to review the draft in detail. Comments interspersed below... Bernard Aboba wrote: > > 1. Introduction > > This section includes a large discussion relating to L2TP that seems to > interrupt the flow of the document. Since this a requirements document for > IPSRA, I'd suggest that this discussion be translated into requirements, > be moved to an evaluation document comparing alternatives against > requirements, or be taken out of the document altogether. I agree. The original intent was to explain the motivation for looking at mechanisms other than l2tp, but I think you are right: this doesn't belong in the requirements document. It will be removed, unless someone else argues persuasively to the contrary. > In particular, this discussion makes points relating to machine versus > user authentication and the security of RADIUS that are actually quite > general, and not really L2TP related. However, as it stands the points are > not well integrated with the rest of the document. For example, if RADIUS > is so insecure as to be an issue with L2TP, then presumably it should also > not be used in IPSRA to authenticate a temporary cert enrollment, so there > are requirements implications here. Furthermore the > arguments for user versus machine auth would also presumably apply to any > VPN protocol. Both of these points need to be further developed. > > Since RADIUS insecurity is referred to, I think a reference is needed > here. This might be to RFC 2607 or 2869 security considerations sections, > but it's hard to tell from the context. If this is really a serious issue > I think that it needs to be documented in detail in the requirements, so > that we can understand how to avoid the concerns in IPSRA. Again, no argument. I think the appropriate thing to do is make some comment in the security considerations about radius. I think the user vs machine considerations are discussed elsewhere within the doc, and I'll check to see if we need to integrate anything from the l2tp discussion into that discussion. > 2. pp.8. I disagree with the definition of user authentication. Using a > user's identity is not sufficient to truly implement user authentication > within IPSEC. You also need to be able to separate user contexts so that > one user cannot use the IPSEC SA opened under another user context. This > is tricky to say the least, and implies negotiation of specific > non-overlapping selectors. There's a good reason why most IPSEC > implementations don't work this way -- doing this is hard. So I think we > need to be careful to define what is meant here and what we are > recommending that implementations need to do. I'd argue that merely using > a user identity for authentication in IKE doesn't really give you much of > a security advantage over machine auth, particularly if the machine cert > is stored on a smart card. I'm not sure I understand what you mean by "separate user contexts". Please explain what your concerns are in more detail. The system I work on is capable of negotiating non-overlapping selectors, and authenticating these on a per-user basis. I also know of at least one commercial multi-user OS which is also capable of isolating SAs to the appropriate users and selectors. Regarding user auth vs machine auth, the relative strength of each depend upon how securely the private key is stored, and on other factors which are discussed in the draft. Using a user identity in conjunction with a short-lived private key narrows the exposure significantly when compared to using a private key that sits on the hard drive of a relatively open commercial operating system for who knows how long. This is a point well worth mentioning. > 3. Section 3.3.5 (page 28). > > It would appear that this section mandates NAT traversal for IPSRA. Is > this the intent? If so, I think it's a good idea -- this is a real > customer requirement. I didn't intend to say it is a hard requirement for remote access. I think the doc says napt traversal is required *if* the implementation must operate in a napt environment. This is by no means always the case, though I agree that there are way more napt devices out there than there used to be. > Note however, that if one also mandates true user auth and therefore > specific selectors, then IPSEC tunnel won't meet the requirements without > changes. You lost me - please elaborate. Thanks, Scott From owner-ietf-ipsra@mail.vpnc.org Tue May 15 07:45:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22104 for ; Tue, 15 May 2001 07:45:16 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id EAA13091 for ietf-ipsra-bks; Tue, 15 May 2001 04:01:52 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA13084 for ; Tue, 15 May 2001 04:01:45 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20151; Tue, 15 May 2001 07:01:33 -0400 (EDT) Message-Id: <200105151101.HAA20151@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ipsra@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-dhcp-12.txt Date: Tue, 15 May 2001 07:01:33 -0400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Remote Access Working Group of the IETF. Title : DHCPv4 Configuration of IPSEC Tunnel Mode Author(s) : B. Patel, B. Aboba, S. Kelly, V. Gupta Filename : draft-ietf-ipsec-dhcp-12.txt Pages : 17 Date : 14-May-01 In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a 'virtual' address from the corporate network, and then tunneling traffic via IPSec from the host's ISP-assigned address to the corporate security gateway. In IPv4, Dynamic Host Configuration Protocol (DHCP) provides for such remote host configuration. This draft explores the requirements for host configuration in IPSec tunnel mode, and describes how DHCPv4 may be leveraged for configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-12.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-dhcp-12.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-dhcp-12.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: <20010514102820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010514102820.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ipsra@mail.vpnc.org Fri May 25 09:27:44 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17630 for ; Fri, 25 May 2001 09:27:42 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id FAA27586 for ietf-ipsra-bks; Fri, 25 May 2001 05:49:08 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA27582 for ; Fri, 25 May 2001 05:49:01 -0700 (PDT) Received: (qmail 10853 invoked by uid 0); 25 May 2001 12:48:29 -0000 Received: from c3600-1-19.bezeqnet135.netvision.net.il (HELO C3600-1-56.BezeqNet135.netvision.net.il) (62.0.186.21) by mail.gmx.net (mail01) with SMTP; 25 May 2001 12:48:29 -0000 Received: by C3600-1-56.BezeqNet135.netvision.net.il with Microsoft Mail id <01C0E532.2228D240@C3600-1-56.BezeqNet135.netvision.net.il>; Fri, 25 May 2001 15:48:25 +0200 Message-ID: <01C0E532.2228D240@C3600-1-56.BezeqNet135.netvision.net.il> From: Yaron Sheffer To: "'ietf-ipsra@vpnc.org'" Subject: PIC -02 inputs Date: Fri, 25 May 2001 15:48:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id FAA27583 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > Following the last straw poll, we are planning to release a -02 version of PIC within the next few weeks. Version -01 has already expired. We envision only minor changes at the moment, but your inputs are solicited. I am sure (no sarcasm intended) many of you did look at the drafts for the recent poll, so please let us know if any corrections/clarifications are needed. > > Thanks, > Yaron From owner-ietf-ipsra@mail.vpnc.org Mon May 28 09:37:57 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04508 for ; Mon, 28 May 2001 09:37:57 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id GAA18076 for ietf-ipsra-bks; Mon, 28 May 2001 06:06:36 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA18067 for ; Mon, 28 May 2001 06:06:29 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f4SD6SN12090 for ; Mon, 28 May 2001 15:06:29 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon May 28 15:06:14 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 28 May 2001 15:06:15 +0200 Message-ID: <0F5098A8968AD411A6EF00508BDF763501F2BB60@efijont100> From: "Vesa-matti Mantyla (LMF)" To: "'ietf-ipsra@vpnc.org'" Subject: Comments on protocol straw poll discussion Date: Mon, 28 May 2001 15:06:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As a friendly comment to the following kind of discussion: >Scott G. Kelly" >Date: Fri, 04 May 2001 09:01:35 -0700 >...I would not rule out other proposals (continued experimentation), but I >don't think that's what we'll get if we don't resolve this. Rather, I >think vendors have a strong incentive to keep using what they've been >using, resulting in a defacto standard which is less than desirable from >a security standpoint. ... Well, this might be true with some vendors... But - we at Ericsson want to point out, that our technological leadership has not been and will not be based on "whatsoever technological solutions". One of our main purposes is to offer secure solutions to our CUSTOMERS. These solutions are results of proper standardisation work. So, it is better to properly consider first, than just make things with the easiest way, to offer real secure solutions to our customers. The IPSRA WG is in an important role of getting the needed standardisation work done, what comes to the Secure Remote Access. What is told by respected experts, has to be taken into account in this process. We do not want us to be forced to use non-standard or even proprietary schemes, with the need to perhaps support multiple such schemes in products. Avoiding this situation we need to continue working and finding commonly accepted solutions. /Vesa-Matti