From owner-ietf-ipsra@mail.vpnc.org Sun Oct 8 23:53:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15841 for ; Sun, 8 Oct 2000 23:53:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA16728 for ietf-ipsra-bks; Sun, 8 Oct 2000 20:04:01 -0700 (PDT) Received: from mail1.mia.bellsouth.net (mail1.mia.bellsouth.net [205.152.144.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16721 for ; Sun, 8 Oct 2000 20:03:59 -0700 (PDT) From: bubblehead32@hotmail.com Received: from www.goldendeckcasino.com (adsl-61-143-206.mia.bellsouth.net [208.61.143.206]) by mail1.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id XAA22857; Sun, 8 Oct 2000 23:07:54 -0400 (EDT) Message-Id: <200010090307.XAA22857@mail1.mia.bellsouth.net> To: <> Subject: WOW!!! Highest Payouts Around!!!!!!!! Date: Sun, 08 Oct 2000 22:50:01 -0400 X-Sender: bubblehead32@hotmail.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Its just like being there. Go to www.goldendeckcasino.com/goldendeckcasino/links/2769.html. If you would like to be removed from these mailings in the future please mailto:bubblehead32@hotmail.com?subject=remove From owner-ietf-ipsra@mail.vpnc.org Wed Oct 11 08:14:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08011 for ; Wed, 11 Oct 2000 08:14:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA06258 for ietf-ipsra-bks; Wed, 11 Oct 2000 04:08:34 -0700 (PDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06250 for ; Wed, 11 Oct 2000 04:08:31 -0700 (PDT) From: henry.haverinen@nokia.com Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com [131.228.118.244]) by mgw-x3.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9BBCbB13315 for ; Wed, 11 Oct 2000 14:12:38 +0300 (EET DST) Received: by esebh03nok with Internet Mail Service (5.5.2652.78) id <4WBVPK6Y>; Wed, 11 Oct 2000 13:47:57 +0300 Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E622FE@treis03nok> To: ietf-ipsra@vpnc.org Subject: RE: REQMTS 2: Should we consider mobility? Date: Wed, 11 Oct 2000 13:47:54 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, > [...] A better example would be using a dhcp address which is changed at > renewal time. > > Should the ipsec sa pair and the ike sa be "handed off", > or dropped and > > re-negotiated? And, should this be decided in this wg? If the terminal sets up the IPsec tunnel from its Mobile IP home address to the VPN GW, and the home agent is in front of the VPN GW (that is, NOT inside the corporate network), then we can use Mobile IP to solve the mobility problem. Transparently to ipsec and ike. We don't need to hand off or drop any ipsec/ike sa's, since they are between the constant home address and the gateway. All the Mobile IP goodies are available, including for example intra-domain mobility. We don't need to specify anything new in any working group. The drawbacks are that we need the HA, and there will be some overhead due to the Mobile IP tunnelling/routing headers. Regards, Henry From owner-ietf-ipsra@mail.vpnc.org Wed Oct 11 11:42:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13493 for ; Wed, 11 Oct 2000 11:42:49 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17109 for ietf-ipsra-bks; Wed, 11 Oct 2000 07:54:58 -0700 (PDT) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA17099 for ; Wed, 11 Oct 2000 07:54:56 -0700 (PDT) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.vpnc.org [208.184.76.50]) with SMTP; 11 Oct 2000 14:58:00 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA09856; Wed, 11 Oct 2000 10:56:14 -0400 (EDT) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Oct 2000 10:59:28 -0400 Message-ID: From: "Linn, John" To: "'ipsec@lists.tislabs.com'" , "'ietf-ipsra@vpnc.org'" Subject: charter question re IKE changes Date: Wed, 11 Oct 2000 10:59:10 -0400 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: I'd like to ask a charter question which relates to both IPsec and IPSRA WGs. IPSRA, based on IESG inputs, has been operating under the premise that its work should not impact IKE's syntax or semantics if feasibly avoidable, with a strong preference to work instead alongside IKE as currently defined. This premise has constrained the design space for candidate IPSRA proposals. Recent discussion on IPsec has suggested significant changes to IKE, potentially removing or replacing authentication modes. Question: If IKE's definition is to be reopened within IPsec, should IPSRA's admissible design space continue to be constrained by RFC-2409? --jl From owner-ietf-ipsra@mail.vpnc.org Wed Oct 11 11:58:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13892 for ; Wed, 11 Oct 2000 11:58:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA18104 for ietf-ipsra-bks; Wed, 11 Oct 2000 08:03:43 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18096 for ; Wed, 11 Oct 2000 08:03:41 -0700 (PDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 9DDF44CE27; Wed, 11 Oct 2000 11:08:14 -0400 (EDT) Received: from smb.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 LAA05609; Wed, 11 Oct 2000 11:08:13 -0400 (EDT) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 9657C35DC2; Wed, 11 Oct 2000 11:08:12 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Linn, John" Cc: "'ipsec@lists.tislabs.com'" , "'ietf-ipsra@vpnc.org'" Subject: Re: charter question re IKE changes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Oct 2000 11:08:12 -0400 Message-Id: <20001011150812.9657C35DC2@smb.research.att.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In message , "Linn, John" writes: >I'd like to ask a charter question which relates to both IPsec and IPSRA >WGs. IPSRA, based on IESG inputs, has been operating under the premise that >its work should not impact IKE's syntax or semantics if feasibly avoidable, >with a strong preference to work instead alongside IKE as currently defined. >This premise has constrained the design space for candidate IPSRA proposals. >Recent discussion on IPsec has suggested significant changes to IKE, >potentially removing or replacing authentication modes. Question: If IKE's >definition is to be reopened within IPsec, should IPSRA's admissible design >space continue to be constrained by RFC-2409? Yes. Most of the talk here has been about removing things, not adding more. IPSRA would need to add more. --Steve Bellovin From owner-ietf-ipsra@mail.vpnc.org Wed Oct 11 12:43:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14786 for ; Wed, 11 Oct 2000 12:43:43 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA24569 for ietf-ipsra-bks; Wed, 11 Oct 2000 08:50:28 -0700 (PDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24564 for ; Wed, 11 Oct 2000 08:50:27 -0700 (PDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.31 2000/08/22 00:15:13 dmccart Exp $) with SMTP id PAA10764; Wed, 11 Oct 2000 15:55:51 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 11 Oct 2000 15:54:34 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id <4VCBN7TX>; Wed, 11 Oct 2000 08:54:32 -0700 Message-ID: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> From: "Walker, Jesse" To: "'Steven M. Bellovin'" , "Linn, John" Cc: "'ipsec@lists.tislabs.com'" , "'ietf-ipsra@vpnc.org'" Subject: RE: charter question re IKE changes Date: Wed, 11 Oct 2000 08:54:31 -0700 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: Steve: "Most" is the operative word, because there has also been very extensive discussion and repeated suggestions and pleas to replace Aggressive Mode with Base Mode. This certainly sounds like an "add" as well as a "remove" to me. Be that as it may, to ellaborate on what I take to be John's point, one of the spectres against which IPsec is fighting is, unlike the SSL community, the IPsec community decided that everyone needs mutual authentication all the time, 100% without exception, regardless of any and all other considerations. My belief, for what it is worth, is experience now shows that this was a genuinely bad decision, and the creation of IPSRA to solve the legacy authentication problem simply confirms this. Real deployments need strong one way authentication of an infrastructure or community to a newly enrolling participant in order to bootstrap; requiring strong two way authentication even during enrollment has created the deployment nightmare that IPSRA has been chartered to fix. Both of the IPSRA proposals on the table make use of this realization by essentially relying on one-way authentication to get around the chicken and egg problem that exists at deployment time. IPSRA words the problem much differently than I've charaterized it here, but it is the same problem. It seems to me that the PIC proposal in particular could easily be incorporated into the larger IKE framework, obviate the need for this IPSRA legacy authentication task, and result in a much more widely deployable and usable IPsec. Just my two cents. -- Jesse -----Original Message----- From: Steven M. Bellovin [mailto:smb@research.att.com] Sent: Wednesday, October 11, 2000 8:08 AM To: Linn, John Cc: 'ipsec@lists.tislabs.com'; 'ietf-ipsra@vpnc.org' Subject: Re: charter question re IKE changes In message , "Linn, John" writes: >I'd like to ask a charter question which relates to both IPsec and IPSRA >WGs. IPSRA, based on IESG inputs, has been operating under the premise that >its work should not impact IKE's syntax or semantics if feasibly avoidable, >with a strong preference to work instead alongside IKE as currently defined. >This premise has constrained the design space for candidate IPSRA proposals. >Recent discussion on IPsec has suggested significant changes to IKE, >potentially removing or replacing authentication modes. Question: If IKE's >definition is to be reopened within IPsec, should IPSRA's admissible design >space continue to be constrained by RFC-2409? Yes. Most of the talk here has been about removing things, not adding more. IPSRA would need to add more. --Steve Bellovin From owner-ietf-ipsra@mail.vpnc.org Wed Oct 11 23:53:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29405 for ; Wed, 11 Oct 2000 23:53:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA13518 for ietf-ipsra-bks; Wed, 11 Oct 2000 19:56:50 -0700 (PDT) Received: from cam-mailer1.bbn.com (cam-mailer1.bbn.com [171.78.68.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA13507 for ; Wed, 11 Oct 2000 19:56:48 -0700 (PDT) Received: from [128.33.238.45] (TC045.BBN.COM [128.33.238.45]) by cam-mailer1.bbn.com (8.8.8+Sun/8.8.8) with ESMTP id XAA22252; Wed, 11 Oct 2000 23:01:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> References: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> Date: Wed, 11 Oct 2000 21:31:14 -0400 To: "Walker, Jesse" From: Stephen Kent Subject: RE: charter question re IKE changes Cc: "'Steven M. Bellovin'" , "Linn, John" , "'ipsec@lists.tislabs.com'" , "'ietf-ipsra@vpnc.org'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jesse, SSL was designed to address a fundamentally different set of communication security requirements, for a client/server model so it is not unreasonable that they made a different decision. However, the result is that most users are burdened with the need to remember and provide passwords for each public web site they log into via SSL, and if these passwords are poorly chosen, the use of encryption does not make it harder for an attacker to guess them and masquerade. IPsec set higher standards for its peer-oriented authentication (not client server). the push back we see wrt PKI use in dialup environments is a result of many factors, some of which have been discussed recently on this list. certainly we know how to generate and distribte certs to users who already have entries in a Radius database. but, what products can we buy that allow us to do this? so, my view is that the IPsec insistence for high quality, 2-way authentication is appropriate, but that implementations have not yet provided good enough PKI support to make it easy for folks to "embrace" the technology. Steve From owner-ietf-ipsra@mail.vpnc.org Thu Oct 12 00:19:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29580 for ; Thu, 12 Oct 2000 00:19:06 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA14163 for ietf-ipsra-bks; Wed, 11 Oct 2000 20:24:17 -0700 (PDT) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA14159; Wed, 11 Oct 2000 20:24:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> Date: Wed, 11 Oct 2000 20:28:48 -0700 To: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: RE: charter question re IKE changes 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 9:31 PM -0400 10/11/00, Stephen Kent wrote: >certainly we know how to generate and distribte certs to users who >already have entries in a Radius database. Of course, if that was all we needed to do, our lives would be simpler and freer from suffering. However, it isn't. Implementations of PKI in the user environment have found that distributing the private keys associated with the public keys in the certs, and doing so in such a way that the user can use the certificate easily and flexibly, is the difficult problem. Note that "distributing" is even difficult when the private-public pair is generated on the user's own device because the private key has to be secured and yet be made available through applications that would need the user to sign things. We know the technology for doing this, but we have so far implemented it in very klunky fashions. Passwords that can be memorized by a user seem a lot more attractive to people who don't understand how utterly insecure they are (and even to some people who do). --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Fri Oct 13 11:10:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07337 for ; Fri, 13 Oct 2000 11:10:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA20149 for ietf-ipsra-bks; Fri, 13 Oct 2000 07:16:22 -0700 (PDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20143; Fri, 13 Oct 2000 07:16:21 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA17399; Fri, 13 Oct 2000 10:21:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> Date: Thu, 12 Oct 2000 12:51:45 -0400 To: Paul Hoffman / VPNC From: Stephen Kent Subject: RE: charter question re IKE changes Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul, >At 9:31 PM -0400 10/11/00, Stephen Kent wrote: >>certainly we know how to generate and distribte certs to users who >>already have entries in a Radius database. > >Of course, if that was all we needed to do, our lives would be >simpler and freer from suffering. However, it isn't. Implementations >of PKI in the user environment have found that distributing the >private keys associated with the public keys in the certs, and doing >so in such a way that the user can use the certificate easily and >flexibly, is the difficult problem. Note that "distributing" is even >difficult when the private-public pair is generated on the user's >own device because the private key has to be secured and yet be made >available through applications that would need the user to sign >things. We know the technology for doing this, but we have so far >implemented it in very klunky fashions. Passwords that can be >memorized by a user seem a lot more attractive to people who don't >understand how utterly insecure they are (and even to some people >who do). Your characterization of the problem does not match mine. We're working from different models: - yes, I would expect the user to generate a key pair on the machine in question, to avoid the problem of "distributing" a private key. smart cards would be better, and then we incur more costs, but folks who argue for use of SecurID cards must address the same sorts of costs of hardware acquisition and distribution. so, if we just compare passwords to key pairs, it seems quite reasonable to assume local generation of key pairs. - no, I would not make this key available to other applications, and thus would not have to address the second problem you cite. a key used to authenticate the user for IPsec need not be used for anything else. trying to impose a one-user one-key philosophy is asking fro trouble, from a security standpoint, and from an implementation perspective as well Given this perspective, remind me again why knowledgeable folks prefer passwords, IF we provide them with good software for the initial certificate issuance process, working from an existing password database :-) Steve From owner-ietf-ipsra@mail.vpnc.org Fri Oct 13 11:22:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07584 for ; Fri, 13 Oct 2000 11:22:49 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA20795 for ietf-ipsra-bks; Fri, 13 Oct 2000 07:33:08 -0700 (PDT) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20789; Fri, 13 Oct 2000 07:32:55 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> Date: Fri, 13 Oct 2000 07:35:20 -0700 To: Stephen Kent From: Paul Hoffman / VPNC Subject: RE: charter question re IKE changes Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org 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 12:51 PM -0400 10/12/00, Stephen Kent wrote: >Given this perspective, remind me again why knowledgeable folks >prefer passwords, IF we provide them with good software for the >initial certificate issuance process, working from an existing >password database :-) Because we don't. I agree with your perspectives about how it *could* work, but that's not what is being delivered. Today's users make choices based on what is available to them today. I also think the market disagrees with you about smart cards. Smart cards are only useful where there are smart card readers. They become an obstacle where there are no readers. Again, I fully support the use of certs and wish that more users agreed with me. But they don't, and designing a protocol around a wish that has had plenty of time to come true but hasn't is a good way to design yet another protocol that won't get implemented. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Fri Oct 13 12:06:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08471 for ; Fri, 13 Oct 2000 12:06:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA21969 for ietf-ipsra-bks; Fri, 13 Oct 2000 08:14:27 -0700 (PDT) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21952; Fri, 13 Oct 2000 08:14:25 -0700 (PDT) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id LAA22516; Fri, 13 Oct 2000 11:19:06 -0400 To: Paul Hoffman / VPNC Cc: Stephen Kent , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: charter question re IKE changes References: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> From: Derek Atkins Date: 13 Oct 2000 11:19:06 -0400 In-Reply-To: Paul Hoffman / VPNC's message of "Fri, 13 Oct 2000 07:35:20 -0700" Message-ID: Lines: 46 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FWIW, I have been working on a Web-based CA that allows a user to obtain a certificate based upon an existing username/password. It's currently setup for web-client certificates (netscape/msie/lynx) but it could be extended to others as well. As Steve said, it's not difficult to create such a beast. However Paul is right in that nobody has, as of yet, delivered one. FWIW, at MIT I've setup an IPSec-based tunnel server that uses HTTPS+Certificates for secure administration. A user generates their RSA key and then submits it via SSL for entry into the IPSec database. They have to use their certs obtained as above. There ya go! Automated "password" sharing of RSA keys based upon existing username/password entries :) -derek Paul Hoffman / VPNC writes: > At 12:51 PM -0400 10/12/00, Stephen Kent wrote: > >Given this perspective, remind me again why knowledgeable folks > >prefer passwords, IF we provide them with good software for the > >initial certificate issuance process, working from an existing > >password database :-) > > Because we don't. I agree with your perspectives about how it *could* > work, but that's not what is being delivered. Today's users make > choices based on what is available to them today. > > I also think the market disagrees with you about smart cards. Smart > cards are only useful where there are smart card readers. They become > an obstacle where there are no readers. > > Again, I fully support the use of certs and wish that more users > agreed with me. But they don't, and designing a protocol around a > wish that has had plenty of time to come true but hasn't is a good > way to design yet another protocol that won't get implemented. > > --Paul Hoffman, Director > --VPN Consortium -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available From owner-ietf-ipsra@mail.vpnc.org Fri Oct 13 12:38:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08966 for ; Fri, 13 Oct 2000 12:38:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA26878 for ietf-ipsra-bks; Fri, 13 Oct 2000 08:58:31 -0700 (PDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26872; Fri, 13 Oct 2000 08:58:29 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA03277; Fri, 13 Oct 2000 12:03:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: <10C8636AE359D4119118009027AE9987031A8EB0@FMSMSX34> Date: Fri, 13 Oct 2000 12:03:48 -0400 To: Paul Hoffman / VPNC From: Stephen Kent Subject: RE: charter question re IKE changes Cc: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul, I think there is confusion about the context in which I made the initial statement. I agree that what is provided today falls short of what could/should be done. I call your attention to the two sentences at the end of the message that I sent and which precipitated this discussion: >but, what products can we buy that allow us to do this? so, my view >is that the IPsec insistence for high quality, 2-way authentication >is appropriate, but that implementations have not yet provided good >enough PKI support to make it easy for folks to "embrace" the >technology. Steve From owner-ietf-ipsra@mail.vpnc.org Fri Oct 13 13:17:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09463 for ; Fri, 13 Oct 2000 13:17:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28939 for ietf-ipsra-bks; Fri, 13 Oct 2000 09:35:48 -0700 (PDT) Received: from potassium.network-alchemy.com (Potassium.Network-Alchemy.COM [199.46.17.146]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28931; Fri, 13 Oct 2000 09:35:46 -0700 (PDT) Received: from sodium.network-alchemy.com (localhost.Network-Alchemy.COM [127.0.0.1]) by potassium.network-alchemy.com (8.8.7/8.8.8) with ESMTP id JAA26753; Fri, 13 Oct 2000 09:35:30 -0700 (PDT) (envelope-from dharkins@network-alchemy.com) Message-Id: <200010131635.JAA26753@potassium.network-alchemy.com> To: Paul Hoffman / VPNC cc: Stephen Kent , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: charter question re IKE changes In-reply-to: Your message of "Fri, 13 Oct 2000 07:35:20 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26750.971454929.1@network-alchemy.com> Date: Fri, 13 Oct 2000 09:35:29 -0700 From: Dan Harkins Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The lack of people implementing good products should not be a motivating factor in developing standards. If we all agree on how it *could* work then let's promote that. I think the market will follow a good solution. I used to love teco until someone showed me vi and that love affair lasted until someone showed me emacs. Dan. On Fri, 13 Oct 2000 07:35:20 PDT you wrote > At 12:51 PM -0400 10/12/00, Stephen Kent wrote: > >Given this perspective, remind me again why knowledgeable folks > >prefer passwords, IF we provide them with good software for the > >initial certificate issuance process, working from an existing > >password database :-) > > Because we don't. I agree with your perspectives about how it *could* > work, but that's not what is being delivered. Today's users make > choices based on what is available to them today. > > I also think the market disagrees with you about smart cards. Smart > cards are only useful where there are smart card readers. They become > an obstacle where there are no readers. > > Again, I fully support the use of certs and wish that more users > agreed with me. But they don't, and designing a protocol around a > wish that has had plenty of time to come true but hasn't is a good > way to design yet another protocol that won't get implemented. > > --Paul Hoffman, Director > --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Fri Oct 13 15:16:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10928 for ; Fri, 13 Oct 2000 15:16:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA03237 for ietf-ipsra-bks; Fri, 13 Oct 2000 11:36:12 -0700 (PDT) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03220 for ; Fri, 13 Oct 2000 11:36:06 -0700 (PDT) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id OAA05810 for ; Fri, 13 Oct 2000 14:32:59 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdDAA0FPCaW; Fri Oct 13 14:32:50 2000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Fri, 13 Oct 2000 14:38:41 -0400 Received: from andrewk3 ([138.120.62.210]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA3F95 for ; Fri, 13 Oct 2000 14:38:41 -0400 Reply-To: From: "Andrew Krywaniuk" Cc: Subject: RE: charter question re IKE changes Date: Fri, 13 Oct 2000 14:31:51 -0400 Message-Id: <00ba01c03543$db7a4c00$d23e788a@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 In-Reply-To: <200010131635.JAA26753@potassium.network-alchemy.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hey guys, Do you think we could cut down on the cross-posting. I think everyone on ipsra is probably on ipsec as well. Thanks, Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ietf-ipsra@mail.vpnc.org > [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Dan Harkins > Sent: Friday, October 13, 2000 12:35 PM > To: Paul Hoffman / VPNC > Cc: Stephen Kent; ipsec@lists.tislabs.com; ietf-ipsra@vpnc.org > Subject: Re: charter question re IKE changes > > > The lack of people implementing good products should not be a > motivating factor in developing standards. If we all agree on > how it *could* work then let's promote that. > > I think the market will follow a good solution. I used to love > teco until someone showed me vi and that love affair lasted > until someone showed me emacs. > > Dan. > > On Fri, 13 Oct 2000 07:35:20 PDT you wrote > > At 12:51 PM -0400 10/12/00, Stephen Kent wrote: > > >Given this perspective, remind me again why knowledgeable folks > > >prefer passwords, IF we provide them with good software for the > > >initial certificate issuance process, working from an existing > > >password database :-) > > > > Because we don't. I agree with your perspectives about how > it *could* > > work, but that's not what is being delivered. Today's users make > > choices based on what is available to them today. > > > > I also think the market disagrees with you about smart cards. Smart > > cards are only useful where there are smart card readers. > They become > > an obstacle where there are no readers. > > > > Again, I fully support the use of certs and wish that more users > > agreed with me. But they don't, and designing a protocol around a > > wish that has had plenty of time to come true but hasn't is a good > > way to design yet another protocol that won't get implemented. > > > > --Paul Hoffman, Director > > --VPN Consortium > From owner-ietf-ipsra@mail.vpnc.org Fri Oct 13 17:22:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12106 for ; Fri, 13 Oct 2000 17:22:15 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA05789 for ietf-ipsra-bks; Fri, 13 Oct 2000 13:37:52 -0700 (PDT) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05782; Fri, 13 Oct 2000 13:37:51 -0700 (PDT) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA09594; Fri, 13 Oct 2000 16:42:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200010131635.JAA26753@potassium.network-alchemy.com> References: <200010131635.JAA26753@potassium.network-alchemy.com> Date: Fri, 13 Oct 2000 16:35:30 -0400 To: Dan Harkins From: Stephen Kent Subject: Re: charter question re IKE changes Cc: Paul Hoffman / VPNC , ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org 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 9:35 AM -0700 10/13/00, Dan Harkins wrote: > The lack of people implementing good products should not be a >motivating factor in developing standards. If we all agree on >how it *could* work then let's promote that. > > I think the market will follow a good solution. I used to love >teco until someone showed me vi and that love affair lasted >until someone showed me emacs. > > Dan. I am in complete agreement with Dan. Steve From owner-ietf-ipsra@mail.vpnc.org Fri Oct 13 20:22:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13547 for ; Fri, 13 Oct 2000 20:22:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA09042 for ietf-ipsra-bks; Fri, 13 Oct 2000 16:36:37 -0700 (PDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA09036; Fri, 13 Oct 2000 16:36:36 -0700 (PDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 13 Oct 2000 17:40:40 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 13 Oct 2000 17:40:29 -0600 From: "Hilarie Orman" To: , Cc: , , Subject: Re: charter question re IKE changes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA09037 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit How amazing. I use emacs, too. Hilarie >>> Stephen Kent 10/13/00 02:35PM >>> At 9:35 AM -0700 10/13/00, Dan Harkins wrote: > The lack of people implementing good products should not be a >motivating factor in developing standards. If we all agree on >how it *could* work then let's promote that. > > I think the market will follow a good solution. I used to love >teco until someone showed me vi and that love affair lasted >until someone showed me emacs. > > Dan. I am in complete agreement with Dan. Steve From owner-ietf-ipsra@mail.vpnc.org Sat Oct 14 02:37:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00711 for ; Sat, 14 Oct 2000 02:37:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA15216 for ietf-ipsra-bks; Fri, 13 Oct 2000 23:00:57 -0700 (PDT) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA15209; Fri, 13 Oct 2000 23:00:56 -0700 (PDT) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id XAA13650; Fri, 13 Oct 2000 23:05:38 -0700 (PDT) Received: from [64.38.134.109] by internaut.com (NX5.67e/NeXT-3.0) id AA01895; Fri, 13 Oct 00 22:20:43 -0800 From: "Bernard Aboba" To: "Derek Atkins" , "Paul Hoffman / VPNC" Cc: "Stephen Kent" , Subject: RE: charter question re IKE changes Date: Fri, 13 Oct 2000 22:38:54 -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) In-Reply-To: Importance: Normal 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 >As Steve said, it's not difficult to create such a beast. However >Paul is right in that nobody has, as of yet, delivered one. Actually, we shipped such a thing in Windows 2000. Check out http://servname/certsvr on a machine running certificate server. From owner-ietf-ipsra@mail.vpnc.org Sat Oct 14 02:37:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00724 for ; Sat, 14 Oct 2000 02:37:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA15204 for ietf-ipsra-bks; Fri, 13 Oct 2000 23:00:52 -0700 (PDT) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA15198; Fri, 13 Oct 2000 23:00:50 -0700 (PDT) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id XAA13729; Fri, 13 Oct 2000 23:05:37 -0700 (PDT) Received: from [64.38.134.109] by internaut.com (NX5.67e/NeXT-3.0) id AA01889; Fri, 13 Oct 00 22:20:27 -0800 From: "Bernard Aboba" To: "Paul Hoffman / VPNC" , "Stephen Kent" Cc: Subject: RE: charter question re IKE changes Date: Fri, 13 Oct 2000 22:38:38 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal 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 >Again, I fully support the use of certs and wish that more users >agreed with me. But they don't, and designing a protocol around a >wish that has had plenty of time to come true but hasn't is a good >way to design yet another protocol that won't get implemented. I think that's a bit hyperbolic. We actually have substantial deployment of *machine* certificates today. Where we are having trouble is in deployment of user certificates. A data point worth considering is that most customers I know of looking at deploying user certs are also looking at deploying public key smartcards. It's this linkage which is causing us the problem. What has generally kept them from actually rolling out the deployment is the state of the reader hardware which is still in its infancy. I think that 18 months ago I made the prediction that we'd have reliable PCMCIA readers for $100 by now. Boy do I have egg on my face for that one. The question is whether the linkage between user cert deployment and smartcards is just an artifact of the philosophy of the early adopters or whether this is something that will quickly give way as more mainstream institutions (universities?) deploy temporary certs. From owner-ietf-ipsra@mail.vpnc.org Thu Oct 19 10:07:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01754 for ; Thu, 19 Oct 2000 10:07:09 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA23132 for ietf-ipsra-bks; Thu, 19 Oct 2000 05:59:11 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23126; Thu, 19 Oct 2000 05:59:09 -0700 (PDT) Received: from toque.cisco.com (toque.cisco.com [161.44.208.153]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA25153; Thu, 19 Oct 2000 06:03:58 -0700 (PDT) Received: from stephanent (franklin-dhcp-246-76.cisco.com [161.44.246.76]) by toque.cisco.com (Mirapoint) with SMTP id AAE04114; Thu, 19 Oct 2000 09:03:50 -0400 (EDT) Message-ID: <006e01c039cd$404c1220$4cf62ca1@cisco.com> From: "Stephane Beaulieu" To: , Subject: IPsec and Remote Access related drafts Date: Thu, 19 Oct 2000 09:05:26 -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 Sorry for the cross postings. This may be of interest to people on both mailing lists. The Mode-Cfg draft and XAUTH draft have been resubmitted as personal submissions. New mailing lists have been set up, so that those interested can post constructive comments. You can subscribe to the lists by sending an email to: ietf-mode-cfg-request@vpnc.org (for mode-cfg) and ietf-xauth-request@vpnc.org (for XAUTH) and having the work "subscribe" in the body. The lists will not be accepting posts for the next couple of days to give a chance to people to sign up. The drafts can be found at: http://www.ietf.org/internet-drafts/draft-dukes-ike-mode-cfg-00.txt http://www.ietf.org/internet-drafts/draft-beaulieu-ike-xauth-00.txt Thanks, Stephane. ------ Stephane Beaulieu S/W Engineer VSEC Business Unit, Enterprise Line of Business Cisco Systems. email: stephane@cisco.com phone: (613) 271-3678 From owner-ietf-ipsra@mail.vpnc.org Thu Oct 19 11:02:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09523 for ; Thu, 19 Oct 2000 11:02:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA25076 for ietf-ipsra-bks; Thu, 19 Oct 2000 07:10:51 -0700 (PDT) Received: from post.indusriver.com (indus-bh.indusriver.com [63.81.64.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA25072 for ; Thu, 19 Oct 2000 07:10:50 -0700 (PDT) Received: from indusriver.com (172.16.4.254) by post.indusriver.com (Worldmail 1.3.167); 19 Oct 2000 10:14:22 -0400 Message-ID: <39EF01F0.1029F7A9@indusriver.com> Date: Thu, 19 Oct 2000 10:15:13 -0400 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephane Beaulieu CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org Subject: Re: IPsec and Remote Access related drafts References: <006e01c039cd$404c1220$4cf62ca1@cisco.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 Can we also include Hybrid-Auth as part of the agenda for the XAUTH mailing list? IMHO, Hybrid plus XAUTH is much better for legacy authentication than XAUTH by itself. Perhaps the hybrid auth authors (M. Litvin, R. Shamir, T. Zegman of Check Point) can also resubmit the Hybrid Auth draft as a personal submission. I assume it expires soon if it hasn't already. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ietf-ipsra@mail.vpnc.org Fri Oct 20 07:34:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22732 for ; Fri, 20 Oct 2000 07:34:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA09519 for ietf-ipsra-bks; Fri, 20 Oct 2000 03:46:05 -0700 (PDT) Received: from dfmail.f-secure.com (dfmail.f-secure.com [194.252.6.39]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA09515 for ; Fri, 20 Oct 2000 03:46:03 -0700 (PDT) Received: (qmail 11208 invoked by uid 0); 20 Oct 2000 10:51:20 -0000 Received: from fsinterface.f-secure.com (HELO fsfwfi01) (194.252.6.33) by dfmail.f-secure.com with SMTP; 20 Oct 2000 10:51:20 -0000 Received: (qmail 30224 invoked from network); 20 Oct 2000 10:50:52 -0000 Received: from fs129-159.f-secure.com (HELO F-Secure.com) (10.128.129.159) by dfintra.f-secure.com with SMTP; 20 Oct 2000 10:50:52 -0000 Message-ID: <39F02404.F6CDB104@F-Secure.com> Date: Fri, 20 Oct 2000 13:52:52 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben McCann CC: Stephane Beaulieu , ietf-ipsra@vpnc.org Subject: Re: IPsec and Remote Access related drafts References: <006e01c039cd$404c1220$4cf62ca1@cisco.com> <39EF01F0.1029F7A9@indusriver.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 I don't see any particular reason to discuss Hybrid. If the endpoints already have machine certs, X-Auth is appropriate. If the client does not yet have any kind of a cert, some method to-be-defined by IPSRA is appropriate. Is VPNC also going to host the mailing list archives for those new lists? Ari Ben McCann wrote: > > Can we also include Hybrid-Auth as part of the agenda for > the XAUTH mailing list? IMHO, Hybrid plus XAUTH is much better > for legacy authentication than XAUTH by itself. > > Perhaps the hybrid auth authors (M. Litvin, R. Shamir, T. Zegman > of Check Point) can also resubmit the Hybrid Auth draft as a > personal submission. I assume it expires soon if it hasn't already. > > -Ben McCann > > -- > Ben McCann Indus River Networks > 31 Nagog Park > Acton, MA, 01720 > email: bmccann@indusriver.com web: www.indusriver.com > phone: (978) 266-8140 fax: (978) 266-8111 -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ietf-ipsra@mail.vpnc.org Fri Oct 20 08:17:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28502 for ; Fri, 20 Oct 2000 08:17:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA10785 for ietf-ipsra-bks; Fri, 20 Oct 2000 04:37:39 -0700 (PDT) Received: from post.indusriver.com (indus-bh.indusriver.com [63.81.64.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10781 for ; Fri, 20 Oct 2000 04:37:38 -0700 (PDT) Received: from indusriver.com (172.16.4.254) by post.indusriver.com (Worldmail 1.3.167); 20 Oct 2000 07:41:15 -0400 Message-ID: <39F02F91.ED0CB236@indusriver.com> Date: Fri, 20 Oct 2000 07:42:09 -0400 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ari Huttunen CC: Stephane Beaulieu , ietf-ipsra@vpnc.org Subject: Re: IPsec and Remote Access related drafts References: <006e01c039cd$404c1220$4cf62ca1@cisco.com> <39EF01F0.1029F7A9@indusriver.com> <39F02404.F6CDB104@F-Secure.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 > I don't see any particular reason to discuss Hybrid. If the endpoints > already have machine certs, X-Auth is appropriate. If the client does > not yet have any kind of a cert, some method to-be-defined by IPSRA is > appropriate. Perhaps you're right. I can always use Hybrid Auth between endpoints when I control both peers. That provides me a solution that we can sell until IPSRA defines, and we implement, another solution for clients that don't yet have certificates. We will implement IPSRA's protocols for interoperability; we just can't wait until such time as those protocols are well defined. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ietf-ipsra@mail.vpnc.org Fri Oct 20 13:24:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16796 for ; Fri, 20 Oct 2000 13:24:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA20104 for ietf-ipsra-bks; Fri, 20 Oct 2000 09:17:22 -0700 (PDT) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20099; Fri, 20 Oct 2000 09:17:18 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <39F02404.F6CDB104@F-Secure.com> References: <006e01c039cd$404c1220$4cf62ca1@cisco.com> <39EF01F0.1029F7A9@indusriver.com> <39F02404.F6CDB104@F-Secure.com> Date: Fri, 20 Oct 2000 09:22:35 -0700 To: Ari Huttunen , Ben McCann From: Paul Hoffman / VPNC Subject: Re: IPsec and Remote Access related drafts Cc: Stephane Beaulieu , ietf-ipsra@vpnc.org 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 1:52 PM +0300 10/20/00, Ari Huttunen wrote: >I don't see any particular reason to discuss Hybrid. Actually, there is no need to discuss any of these on this mailing list. XAUTH and mode-cfg and Hybrid are *not* part of the IPSRA WG charter (or part of the IPsec WG charter). That's why the separate mailing lists were formed. Please move this discussion to the new mailing lists (which will start up on Monday, but you can subscribe now). --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Sat Oct 21 20:46:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18933 for ; Sat, 21 Oct 2000 20:46:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA05691 for ietf-ipsra-bks; Sat, 21 Oct 2000 17:04:30 -0700 (PDT) Received: from dfmail.f-secure.com (dfmail.f-secure.com [194.252.6.39]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA05683 for ; Sat, 21 Oct 2000 17:04:28 -0700 (PDT) Received: (qmail 23393 invoked by uid 0); 22 Oct 2000 00:09:52 -0000 Received: from fsinterface.f-secure.com (HELO fsfwfi01) (194.252.6.33) by dfmail.f-secure.com with SMTP; 22 Oct 2000 00:09:52 -0000 Received: (qmail 23827 invoked from network); 22 Oct 2000 00:09:24 -0000 Received: from info.f-secure.com (HELO F-Secure.com) (194.197.29.11) by dfintra.f-secure.com with SMTP; 22 Oct 2000 00:09:24 -0000 Message-ID: <39F230AF.69DB6AB7@F-Secure.com> Date: Sun, 22 Oct 2000 03:11:27 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / VPNC CC: Ben McCann , Stephane Beaulieu , ietf-ipsra@vpnc.org Subject: Re: IPsec and Remote Access related drafts References: <006e01c039cd$404c1220$4cf62ca1@cisco.com> <39EF01F0.1029F7A9@indusriver.com> <39F02404.F6CDB104@F-Secure.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 Paul Hoffman / VPNC wrote: > > At 1:52 PM +0300 10/20/00, Ari Huttunen wrote: > >I don't see any particular reason to discuss Hybrid. > > Actually, there is no need to discuss any of these on this mailing > list. XAUTH and mode-cfg and Hybrid are *not* part of the IPSRA WG > charter (or part of the IPsec WG charter). That's why the separate > mailing lists were formed. X-Auth will remain in our implementation at least until this WG succeeds in producing something to the following problem: - Client has a machine certificate - User authentication is done via a legacy method It is not sufficient to just leave the machine certificate be unused. Is it the intention of this WG to produce something for this or not? > > Please move this discussion to the new mailing lists (which will > start up on Monday, but you can subscribe now). Sure.. And if someone wants to discuss Hybrid, why don't you set up another list for it too.. ;) Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ietf-ipsra@mail.vpnc.org Fri Oct 27 13:36:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08858 for ; Fri, 27 Oct 2000 13:36:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA20581 for ietf-ipsra-bks; Fri, 27 Oct 2000 09:47:55 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20577 for ; Fri, 27 Oct 2000 09:47:53 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Oct 2000 09:53:18 -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.2650.21) id VGRCRFP4; Fri, 27 Oct 2000 09:53:12 -0700 From: Scott Kelly To: ipsra list Message-ID: <39F9B365.5EC0F5D9@redcreek.com> Date: Fri, 27 Oct 2000 09:55:01 -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: REQMTS 3: scenarios 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 All, This is the third in a series of posts aimed at resolving some issues prior to publication of a revision of the requirements draft. I am considering deleting 2 or the scenarios from the draft: o extranet users using their corporate desktop systems to access the remote company network of a business partner o extranet users using a business partner's system (on that partner's network) to access their home corporate network The rationale for deleting these is the same in both cases: this is standard ipsec, and not specific to remote access. Any opinions on this? Thanks, Scott From owner-ietf-ipsra@mail.vpnc.org Fri Oct 27 13:37:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09163 for ; Fri, 27 Oct 2000 13:37:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA21925 for ietf-ipsra-bks; Fri, 27 Oct 2000 09:57:27 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21918 for ; Fri, 27 Oct 2000 09:57:26 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Oct 2000 10:02:51 -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.2650.21) id VGRCRFQT; Fri, 27 Oct 2000 10:02:50 -0700 From: Scott Kelly To: ipsra list Message-ID: <39F9B5A8.B293ECD9@redcreek.com> Date: Fri, 27 Oct 2000 10:04: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: REQMTS 2: Should we consider mobility? References: <39DCE3D6.73DF8534@redcreek.com> <39DCE6C9.2531F6F5@redcreek.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 Another way to interpret this requirement is in terms of single sign-on: if a user has been authenticated while entering the corp net through one access point, and then must change to another point of access (gateway goes down, or some other topological change occurs which makes the original gateway unreachable or impractical to reach), the user should not (necessarily) have to re-authenticate. Any comments? Scott From owner-ietf-ipsra@mail.vpnc.org Fri Oct 27 14:06:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16484 for ; Fri, 27 Oct 2000 14:06:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA24470 for ietf-ipsra-bks; Fri, 27 Oct 2000 10:17:45 -0700 (PDT) Received: from cisco.com (uzura.cisco.com [161.44.3.77]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24466 for ; Fri, 27 Oct 2000 10:17:43 -0700 (PDT) Received: from ebooth-linux.cisco.com (ebooth@ebooth-linux.cisco.com [161.44.58.52]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA00368; Fri, 27 Oct 2000 13:22:44 -0400 (EDT) Date: Fri, 27 Oct 2000 13:23:02 -0400 (EDT) From: Skip Booth To: Scott Kelly cc: ipsra list Subject: Re: REQMTS 3: scenarios In-Reply-To: <39F9B365.5EC0F5D9@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 Fri, 27 Oct 2000, Scott Kelly wrote: > Hi All, > > This is the third in a series of posts aimed at resolving some issues > prior to publication of a revision of the requirements draft. > > I am considering deleting 2 or the scenarios from the draft: > > o extranet users using their corporate desktop systems to > access the remote company network of a business partner > > o extranet users using a business partner's system (on that > partner's network) to access their home corporate network > > The rationale for deleting these is the same in both cases: this is > standard ipsec, and not specific to remote access. > > Any opinions on this? To me, remote access is defined as any situation where you are not physically connected to the network and must use some other means of obtaining access to that network. In this case, that method is IPsec. So I am not sure why these two scenarios are not considered remote-access. In addition, it's not clear to me why these situations don't have exactly the same requirements as the other remote-access scenarios. You still need to be able to obtain an IP address and potentially authenticate with some user information such as a password or one-time token. In addition, these scenarios will also have additional requirements such as NAT and Firewall interactions. IMO, these scenarios should remain. I believe the IPsec WG will be the home of the IPsec NAT/FW issues so maybe just a reference to the problem is sufficient in the IPSRA requirements doc. -Skip > > Thanks, > > Scott > From owner-ietf-ipsra@mail.vpnc.org Fri Oct 27 15:10:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04663 for ; Fri, 27 Oct 2000 15:10:51 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA28122 for ietf-ipsra-bks; Fri, 27 Oct 2000 11:22:18 -0700 (PDT) Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28118 for ; Fri, 27 Oct 2000 11:22:14 -0700 (PDT) Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id OAA18891 for ; Fri, 27 Oct 2000 14:20:13 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdPAA06i48x; Fri Oct 27 14:20:08 2000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Fri, 27 Oct 2000 14:23:04 -0400 Received: from andrewk3 ([138.120.62.210]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA69F1; Fri, 27 Oct 2000 14:23:03 -0400 Reply-To: From: "Andrew Krywaniuk" To: "'Scott Kelly'" , "'ipsra list'" Subject: RE: REQMTS 3: scenarios Date: Fri, 27 Oct 2000 14:15:49 -0400 Message-Id: <00b301c04041$efac6b00$d23e788a@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 In-Reply-To: <39F9B365.5EC0F5D9@redcreek.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Has anyone here been following aaarch? It seems to me (from what little I was able to discern from my seat in the hallway at the first RG meeting), that these were some of the scenarios they were trying to address. I wonder whether they are treating these scenerios as remote access. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ietf-ipsra@mail.vpnc.org > [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Scott Kelly > Sent: Friday, October 27, 2000 12:55 PM > To: ipsra list > Subject: REQMTS 3: scenarios > > > Hi All, > > This is the third in a series of posts aimed at resolving some issues > prior to publication of a revision of the requirements draft. > > I am considering deleting 2 or the scenarios from the draft: > > o extranet users using their corporate desktop systems to > access the remote company network of a business partner > > o extranet users using a business partner's system (on that > partner's network) to access their home corporate network > > The rationale for deleting these is the same in both cases: this is > standard ipsec, and not specific to remote access. > > Any opinions on this? > > Thanks, > > Scott > From owner-ietf-ipsra@mail.vpnc.org Fri Oct 27 17:24:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05080 for ; Fri, 27 Oct 2000 17:24:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA04396 for ietf-ipsra-bks; Fri, 27 Oct 2000 13:33:37 -0700 (PDT) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA04387; Fri, 27 Oct 2000 13:33:36 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <39F9B365.5EC0F5D9@redcreek.com> References: <39F9B365.5EC0F5D9@redcreek.com> Date: Fri, 27 Oct 2000 13:39:32 -0700 To: Scott Kelly , ipsra list From: Paul Hoffman / VPNC Subject: Re: REQMTS 3: scenarios 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 9:55 AM -0700 10/27/00, Scott Kelly wrote: >I am considering deleting 2 or the scenarios from the draft: > >o extranet users using their corporate desktop systems to > access the remote company network of a business partner > >o extranet users using a business partner's system (on that > partner's network) to access their home corporate network To someone configuring the security gateway on the responder end of these scenarios, the setup is indistinguishable from the road warrior dialing in through the ISP du jour. That is, the fact that a business-to-business extranet has been set up in irrelevant, since the rules for that particular user will be unrelated to the rules for the rest of the business partner. Personally, I wouldn't mind throwing out all extranet scenarios because they have not been shown to be nearly as relevant as WAN and road warrior. >The rationale for deleting these is the same in both cases: this is >standard ipsec, and not specific to remote access. Well, it is "remote access", but it is no different than road warrior remote access. --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Fri Oct 27 18:06:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14661 for ; Fri, 27 Oct 2000 18:06:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA07609 for ietf-ipsra-bks; Fri, 27 Oct 2000 14:30:20 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07602; Fri, 27 Oct 2000 14:30:18 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Oct 2000 14:35: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.2650.21) id VGRCRGGA; Fri, 27 Oct 2000 14:35:40 -0700 From: Scott Kelly To: Paul Hoffman / VPNC Cc: ipsra list Message-ID: <39F9F59A.ACC078AF@redcreek.com> Date: Fri, 27 Oct 2000 14:37:30 -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: REQMTS 3: scenarios References: <39F9B365.5EC0F5D9@redcreek.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 Paul, Comments below... Paul Hoffman / VPNC wrote: > >The rationale for deleting these is the same in both cases: this is > >standard ipsec, and not specific to remote access. > > Well, it is "remote access", but it is no different than road warrior > remote access. > I don't think this is completely accurate: road warrior remote access entails someone dialing an isp, and then connecting to the local net - the system they use may or may not be "known". The first scenario above entails a connection from a "known" system within your local net to a remote net. The second scenario above entails a connection from an "unknown" system within an "unknown" network connecting into your local net. The vulnerabilities are different in each case. Scott From owner-ietf-ipsra@mail.vpnc.org Fri Oct 27 18:12:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15946 for ; Fri, 27 Oct 2000 18:12:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA07436 for ietf-ipsra-bks; Fri, 27 Oct 2000 14:23:57 -0700 (PDT) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA07432 for ; Fri, 27 Oct 2000 14:23:56 -0700 (PDT) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Oct 2000 14:29: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.2650.21) id VGRCRGF3; Fri, 27 Oct 2000 14:29:18 -0700 From: Scott Kelly To: Skip Booth Cc: ipsra list Message-ID: <39F9F41C.4ADB0140@redcreek.com> Date: Fri, 27 Oct 2000 14:31:08 -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: REQMTS 3: scenarios 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 Skip, Skip Booth wrote: > To me, remote access is defined as any situation where you are not physically > connected to the network and must use some other means of obtaining access to > that network. In this case, that method is IPsec. So I am not sure why these > two scenarios are not considered remote-access. I think I see what you mean. I also think this means we need to clarify what we mean by remote access. One starting definition might made be in terms of the access properties: we have typically used "remote access" in our ipsec discussions to refer to one remote system seeking access to a "local" network via dialup, or dsl/cable connections. If we connect a remote network (as opposed to a single user) to a local network via an ipsec connection, we typically refer to this as a vpn, i.e. the remote network *is* directly connected to the local network by virtue of the tunnel. This would seem to be different than what we typically refer to as remote access, although this is exactly what occurs if someone has a home network with a security gateway via which they access the company net. The distinguishing characteristic seems to be that in the remote access case, we have one-to-many or few-to-many access from the remote net to the local net, rather than having both nets wide open to one another. This way of looking at it tends to support your argument that these scenarios should remain. Scott From owner-ietf-ipsra@mail.vpnc.org Sun Oct 29 20:16:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15332 for ; Sun, 29 Oct 2000 20:16:19 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA04438 for ietf-ipsra-bks; Sun, 29 Oct 2000 16:16:25 -0800 (PST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA04432; Sun, 29 Oct 2000 16:16:22 -0800 (PST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id QAA15233; Sun, 29 Oct 2000 16:22:28 -0800 (PST) Received: from [64.38.134.109] by internaut.com (NX5.67e/NeXT-3.0) id AA07713; Sun, 29 Oct 00 17:01:14 -0800 From: "Bernard Aboba" To: "Paul Hoffman / VPNC" , "Scott Kelly" , "ipsra list" Subject: RE: REQMTS 3: scenarios Date: Sun, 29 Oct 2000 16:19:52 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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.50.4133.2400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >Well, it is "remote access", but it is no different than road warrior >remote access. Not necessarily. In the Extranet case, there is typically an implied need for access control. That is, Extranet partners should typically not be connected to each other, nor allowed access to resources outside of the Extranet. In practice, these kind of restrictions are typically enforced via per-user filters, either of the routing, SPD, or packet filtering variety. From owner-ietf-ipsra@mail.vpnc.org Sun Oct 29 23:26:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28465 for ; Sun, 29 Oct 2000 23:26:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA08330 for ietf-ipsra-bks; Sun, 29 Oct 2000 19:40:15 -0800 (PST) Received: from mail.nexsi.com (sdsl-208-185-176-210.dsl.sjc.megapath.net [208.185.176.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08326 for ; Sun, 29 Oct 2000 19:40:13 -0800 (PST) Received: from denali (dynam69.nexsi.com [172.16.212.69]) by mail.nexsi.com (8.9.3/8.9.3) with SMTP id TAA24427; Sun, 29 Oct 2000 19:50:34 -0800 From: "sankar ramamoorthi" To: "Scott Kelly" , "Skip Booth" Cc: "ipsra list" Subject: RE: REQMTS 3: scenarios Date: Sun, 29 Oct 2000 19:43:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <39F9F41C.4ADB0140@redcreek.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I was trying to understand from the charter to figure out what 'remote access' is defined as.. This line caught my attention. "There are some fundamental differences, that are relevant to IPSec usage, between these remote access scenarios and scenarios where both parties reside in fixed locations: " To me remote access is a scenario where both the parties do not reside in fixed locations (that is the policy describing ipsec proxy addresses of any one side is not known beforehand to the other side and needs to be found out in a dynamic fashion). -- sankar -- -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Scott Kelly Sent: Friday, October 27, 2000 2:31 PM To: Skip Booth Cc: ipsra list Subject: Re: REQMTS 3: scenarios Hi Skip, Skip Booth wrote: > To me, remote access is defined as any situation where you are not physically > connected to the network and must use some other means of obtaining access to > that network. In this case, that method is IPsec. So I am not sure why these > two scenarios are not considered remote-access. I think I see what you mean. I also think this means we need to clarify what we mean by remote access. One starting definition might made be in terms of the access properties: we have typically used "remote access" in our ipsec discussions to refer to one remote system seeking access to a "local" network via dialup, or dsl/cable connections. If we connect a remote network (as opposed to a single user) to a local network via an ipsec connection, we typically refer to this as a vpn, i.e. the remote network *is* directly connected to the local network by virtue of the tunnel. This would seem to be different than what we typically refer to as remote access, although this is exactly what occurs if someone has a home network with a security gateway via which they access the company net. The distinguishing characteristic seems to be that in the remote access case, we have one-to-many or few-to-many access from the remote net to the local net, rather than having both nets wide open to one another. This way of looking at it tends to support your argument that these scenarios should remain. Scott From owner-ietf-ipsra@mail.vpnc.org Mon Oct 30 21:56:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08868 for ; Mon, 30 Oct 2000 21:56:05 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA27501 for ietf-ipsra-bks; Mon, 30 Oct 2000 17:55:59 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27497 for ; Mon, 30 Oct 2000 17:55:58 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Oct 2000 18:01:40 -0800 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.2650.21) id VGRCRJ6J; Mon, 30 Oct 2000 18:01:36 -0800 From: Scott Kelly To: ipsra list Message-ID: <39FE2864.218F4367@redcreek.com> Date: Mon, 30 Oct 2000 18:03:16 -0800 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: REQMTS 4: definition of remote access 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 This is the fourth in a series of posts aimed at resolving some issues prior to publication of a revision of the requirements draft. I think, based upon recent discussion on this list, that we need to more clearly define what we mean by remote access. While a definition might seem obvious at first glance (I sure thought it was), it turns out not to be quite so straightforward. Skip suggested that any host which is not physically connected to the network and must use some other method of obtaining access to the network qualifies as a remote access host. My difficulty with this definition is that it includes almost every topology in which we might use ipsec, other than intranet. I think the implied scope is far larger than what some of us would expect for this working group. An alternative is to try to construct an operational definition based on what we've defined as remote access in the past. Not too long ago, remote access meant dialing into a modem at the corporate site. Not long after that, it came to include dialing into an ISP and tunneling the connection across the internet using pptp, l2tp or something like that. Now, we're attempting to extend the definition a bit by including ipsec in the cadre of tunneling mechanisms. I think it may be that one common thread in all the scenarios described is that the remote system is given an address from the local network. That is, although the system is remote in space, once access is granted, it appears to be on the same physical lan as the other hosts. If we use this as a filter, remote access would include access using any arbitrary connection technology, so long as the connection was tunneled, and the user was assigned a local lan address somehow. This squares well with the scenarios we've defined so far, but it excludes the 2 scenarios I was thinking about deleting, i.e. o extranet users using their corporate desktop systems to access the remote company network of a business partner o extranet users using a business partner's system (on that partner's network) to access their home corporate network unless the connections are tunnelled, and a home lan address is assigned from the accessed network. Does anyone have a better idea of how to define remote access (for our purposes)? Scott From owner-ietf-ipsra@mail.vpnc.org Tue Oct 31 00:27:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17271 for ; Tue, 31 Oct 2000 00:27:53 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA01352 for ietf-ipsra-bks; Mon, 30 Oct 2000 20:24:20 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA01347 for ; Mon, 30 Oct 2000 20:24:19 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id UAA06736; Mon, 30 Oct 2000 20:30:00 -0800 (PST) Date: Mon, 30 Oct 2000 20:28:38 -0800 (PST) From: Jan Vilhuber To: Scott Kelly cc: ipsra list Subject: Re: REQMTS 4: definition of remote access In-Reply-To: <39FE2864.218F4367@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: Two thoughts: a) the only difference I can think of quickly between what you define as 'remote access' and 'extranet' is the fact that one gets an ip-address, and the other gets an ip-address and a subnet. Is that right? If so, then the whole problem can be ignored as long as you have a generic mechanism defined that can pass subnet information to the client (if needed), and can influence routing at the gateway to include the subnet of the client (whether it was pushed to the client or preconfigured). As an example, I used to dial into the corporate network via ISDN, and I had a subnet at home. The AAA entry for my therefore included the subnet information, that was installed at the NAS (Network Access Server), so routing could to the 'right thing'. When I wasn't dialing in via ISDN, I might not get the subnet information (or I might) depending on whether I use the same AAA-username, or any other determination that the NAS could do (I don't remember how it was done back then, but I can imagine multiple scenarios). In any case, I think the difference between 'remote access' and 'extranet' is only one or two authorization parameters (in AAA-speak). In other words: They're pretty much the same thing. I suppose one further comment here is that you're 'filter' below doesn't work, since I claim to have been doing 'exrtranet' type stuff over simple dial-up or ISDN a few years ago. It's nothing new, and nothing different. b) why not ask the AAA WG for their definition of 'remote access'? I would quite frankly say that we need to complement or extend any general IETF definition of 'remote access' to ipsec, no matter how broad the IETF definition of 'remote access' is. In other words 'for our purposes' MUST be the same as the IETF purpose in general. We can't dumb it down, so to speak. I'm kind of going on the assumption that the AAA WG (or maybe the PPP WG?) is the 'authority' on what remote-access is, not us. So we should bow to whatever definition they have, and work with it. jan On Mon, 30 Oct 2000, Scott Kelly wrote: > This is the fourth in a series of posts aimed at resolving some issues > prior to publication of a revision of the requirements draft. > > I think, based upon recent discussion on this list, that we need to more > clearly define what we mean by remote access. While a definition might > seem obvious at first glance (I sure thought it was), it turns out not > to be quite so straightforward. Skip suggested that any host which is > not physically connected to the network and must use some other method > of obtaining access to the network qualifies as a remote access host. My > difficulty with this definition is that it includes almost every > topology in which we might use ipsec, other than intranet. I think the > implied scope is far larger than what some of us would expect for this > working group. > > An alternative is to try to construct an operational definition based on > what we've defined as remote access in the past. Not too long ago, > remote access meant dialing into a modem at the corporate site. Not long > after that, it came to include dialing into an ISP and tunneling the > connection across the internet using pptp, l2tp or something like that. > Now, we're attempting to extend the definition a bit by including ipsec > in the cadre of tunneling mechanisms. > > I think it may be that one common thread in all the scenarios described > is that the remote system is given an address from the local network. > That is, although the system is remote in space, once access is granted, > it appears to be on the same physical lan as the other hosts. > > If we use this as a filter, remote access would include access using any > arbitrary connection technology, so long as the connection was tunneled, > and the user was assigned a local lan address somehow. This squares well > with the scenarios we've defined so far, but it excludes the 2 scenarios > I was thinking about deleting, i.e. > > o extranet users using their corporate desktop systems to > access the remote company network of a business partner > > o extranet users using a business partner's system (on that > partner's network) to access their home corporate network > > unless the connections are tunnelled, and a home lan address is assigned > from the accessed network. > > Does anyone have a better idea of how to define remote access (for our > purposes)? > > Scott > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-ipsra@mail.vpnc.org Tue Oct 31 02:03:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04472 for ; Tue, 31 Oct 2000 02:03:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA03584 for ietf-ipsra-bks; Mon, 30 Oct 2000 22:12:18 -0800 (PST) Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA03580 for ; Mon, 30 Oct 2000 22:12:15 -0800 (PST) Received: by relay1.trustworks.com (8.8.5/1.11) id JAA11374; Tue, 31 Oct 2000 09:18:43 +0300 (MSK) Message-Id: <200010310618.JAA11374@relay1.trustworks.com> Received: from svan-pc(212.114.5.100) by zuka via smap (V2.0) id xma011348; Tue, 31 Oct 00 09:18:26 +0300 From: "Valery Smyslov" Organization: TWS To: ipsra list , Scott Kelly Date: Tue, 31 Oct 2000 09:18:01 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: REQMTS 4: definition of remote access In-reply-to: <39FE2864.218F4367@redcreek.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT On 30 Oct 00, at 18:03, Scott Kelly wrote: > This is the fourth in a series of posts aimed at resolving some issues > prior to publication of a revision of the requirements draft. > > I think, based upon recent discussion on this list, that we need to more > clearly define what we mean by remote access. While a definition might > seem obvious at first glance (I sure thought it was), it turns out not > to be quite so straightforward. Skip suggested that any host which is > not physically connected to the network and must use some other method > of obtaining access to the network qualifies as a remote access host. My > difficulty with this definition is that it includes almost every > topology in which we might use ipsec, other than intranet. I think the > implied scope is far larger than what some of us would expect for this > working group. > > An alternative is to try to construct an operational definition based on > what we've defined as remote access in the past. Not too long ago, > remote access meant dialing into a modem at the corporate site. Not long > after that, it came to include dialing into an ISP and tunneling the > connection across the internet using pptp, l2tp or something like that. > Now, we're attempting to extend the definition a bit by including ipsec > in the cadre of tunneling mechanisms. > > I think it may be that one common thread in all the scenarios described > is that the remote system is given an address from the local network. > That is, although the system is remote in space, once access is granted, > it appears to be on the same physical lan as the other hosts. I don't think this is always the case. LAN might have public addresses, so that remote system would have no need to get ad address from the local network. We used to have such type of remote access for years. Regards, Valery. From owner-ietf-ipsra@mail.vpnc.org Tue Oct 31 09:06:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14434 for ; Tue, 31 Oct 2000 09:06:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA17182 for ietf-ipsra-bks; Tue, 31 Oct 2000 05:09:17 -0800 (PST) Received: from post.indusriver.com (indus-bh.indusriver.com [63.81.64.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17176 for ; Tue, 31 Oct 2000 05:09:16 -0800 (PST) Received: from indusriver.com (172.16.4.254) by post.indusriver.com (Worldmail 1.3.167); 31 Oct 2000 08:13:51 -0500 Message-ID: <39FEC5B1.4C3ED45C@indusriver.com> Date: Tue, 31 Oct 2000 08:14:25 -0500 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Valery Smyslov CC: ietf-ipsra@vpnc.org Subject: Re: REQMTS 4: definition of remote access References: <200010310618.JAA11374@relay1.trustworks.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 Scott wrote: > > I think it may be that one common thread in all the scenarios described > > is that the remote system is given an address from the local network. > > That is, although the system is remote in space, once access is granted, > > it appears to be on the same physical lan as the other hosts. Valery replied: > I don't think this is always the case. LAN might have public > addresses, so that remote system would have no need to get ad address > from the local network. We used to have such type of remote access > for years. I agree with Scott. IP address assignment is a necessary precondition for remote access because we are designing protocols that provide the illusion of being connected securely and directly to your home network. (At least, that's my goal). IP address assignment is also necessary for several practical reasons: - IMHO, the protocol should not change behavior because the home network (to which the remote access client connects) has or does not have publicly routable addresses. We should assume the worst case (i.e. unroutable addresses) and design for that. - If you don't assign addresses then the remote access client's IP address, as seen by the other hosts on his home network, can be any address on the Internet. This implies the security gateway must also be the default route to the Internet for all of the hosts on the home network. This is impractical. The security gateway could also advertise (via the routing protocol of your choice) host routes for every connected client but that seems even worse, especially for large VPN's with 1000's of remote access clients. - Some of our customers, for better or worse, implement internal firewall policy based on the addresses of hosts within the intranet. The remote access client must be assigned an address that identifies that client to the various firewalls within the intranet. - Finally, I believe this WG needs to set constraints on the scope of the 'remote access' problem so we can define practical and efficient solutions. Scott's IP address assignment is one such constraint that lets the WG narrow the problem space to a managable size. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111