From owner-ipsec@lists.tislabs.com Mon May 1 11:04:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08870; Mon, 1 May 2000 11:04:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02998 Mon, 1 May 2000 12:30:20 -0400 (EDT) Reply-To: From: "Bernard Aboba" To: "'Tylor Allison'" , , Subject: RE: Mode-Config Questions Date: Mon, 1 May 2000 09:38:33 -0700 Message-ID: <002d01bfb38b$b1658630$428939cc@ntdev.microsoft.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A recent mail to the DHC list from Bernie Volz (Process Software). The bottom line appears to be that renewing the lease is problematic since under RFC 2131 the DHCP server will ignore the giaddr field if the VPN server filled it in, and send the DHCPACK directly to the client, which will not be expecting it. -----Original Message----- From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On Behalf Of Bernie Volz Sent: Monday, May 01, 2000 8:45 AM To: DHCPv4 discussion list Cc: DHCP-V4@bucknell.edu Subject: RE: Relayed lease extension Barr: >This set-up might be used in other instances where the end-client never >gets an address via DHCP itself (if I recall, PPP sends it in the inital >negotiation to the client and thus the client isn't running DHCP at >all). If the BigBox gets the lease on the address for a shorter time >than the client is connected, it will need to renew the lease and hence >the situation Wim is looking at. > >...Bernie, did you really mean to say that? It seems to me that in the case >you describe, BigBox (and NOT its downstream client) is the host known to a >DHCP server as the DHCP client. If you are suggesting a different >interpretation, such as BigBox acting as proxy for its client, then the >protocol may not adequately cover all implementation cases. For renewals, how are they handled? The renewal is sent by BigBox with the client's IP address. If the response is send back to the client's IP address, then either: a) BigBox must take steps to prevent it from going to the client and intercept it. b) The renewal will go directly to the client and in the case of PPP where the client isn't running DHCP, it will not have the desired effect. Since the original lease was done by BigBox on behalf of the client, the renewal must also be done by BigBox on behalf of the client. - Bernie -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Tylor Allison Sent: Friday, April 28, 2000 2:52 PM To: ietf-ipsra@vpnc.org; ipsec@lists.tislabs.com Subject: Mode-Config Questions For those of you who have implemented Mode-Config, I have a few questions... o First of all, Mode-Config allows a client to request the IP addresses of DHCP Servers from the edge device. Is it expected that once the client has obtained it's address via Mode-Config, that it will then use DHCP to manage that address (DHCP lease renewal)? Or is it expected that the client will contact the DHCP for network parameters not supplied via mode-config (via DHCP inform)? o Assuming that the client does not manage it's dynamically-assigned IP address via DHCP, how and when does lease expiration get handled? The mode-config draft mentions that the IP address is valid until the expiry time defined via the INTERNAL_ADDRESS_EXPIRY attribute, or until the ISAKMP SA expires. Is it the client's responsibility to recognize lease expiration, and to perform a new mode-config exchange? Can the edge-device force a new mode-config exchange via a SET/ACK protocol to extend the lease? o Finally, I'd be very interested in hearing anyone's thoughts on implementing mode-config for a gateway application. In particular, is the typical method to implement a thin DHCP client interface within the gateway's ISAKMP server to interact with a separate DHCP server behind the gateway? Or are people just implementing a private pool of addresses within ISAKMP? From my understanding of the DHCP standard, there are problems with having ISAKMP act as a DHCP client on behalf of the remote VPN client. This is especially true with the renewal of IP address leases, which requires the server to unicast replies back to the client address for which the lease is being renewed. Just wondering if anyone has tackled these issues already... or if there is documentation out there which discusses solutions. I've searched the archives, and really didn't find anything relating to these questions... but if this has been previously discussed, could someone point me to the thread. Thanks in advance. --- Tylor Allison tylor_allison@securecomputing.com Secure Computing Corporation From owner-ipsec@lists.tislabs.com Tue May 2 01:32:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA23738; Tue, 2 May 2000 01:32:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA04912 Tue, 2 May 2000 02:42:45 -0400 (EDT) Message-Id: <01BFB430.191FAF40.RuheenaR@future.futsoft.com> From: Ruheena Rashid Reply-To: "RuheenaR@future.futsoft.com" To: "ipsec@lists.tislabs.com" , "ietf-pkix@imc.org" Subject: Query : CA related Date: Tue, 2 May 2000 12:15:24 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello I have a query regarding the Certification Authority (CA) in IKE. RFC 2409 mentions about the inclusion of certificate payloads, which needs to be verified by the CA, but does not mention as to how the information is conveyed to the CA for verification. Is it that the Peer obtains the certificate and performs the verification ? (or) Does it send the complete payload to CA for verification ? I would like to know whether any draft or RFC exists, which mentions about how the CA performs the verification of the certificates? Also, whether any encryption needs to be performed to send the information to the CA (since security is a major issue) ? I would also like to know whether any implementation exists for the same. Regards Ruheena Rashid. Ruheena Rashid Software Engineer Future Software Pvt. Ltd. Nandanam Chennai From owner-ipsec@lists.tislabs.com Thu May 4 13:02:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15159; Thu, 4 May 2000 13:02:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15389 Thu, 4 May 2000 13:39:29 -0400 (EDT) Message-Id: <4.2.0.58.20000504100418.00b6acd0@mira-sjcd-1.cisco.com> X-Sender: nsoleima@mira-sjcd-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 04 May 2000 10:47:13 -0700 To: ipsec@lists.tislabs.com From: Niloo Soleimani Subject: IPsec or IPSec? Cc: smilley@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What is correct spelling of IPSEC? Is it with a lower s or an upper S? It is spelled both ways in many of the documents. For example the "IPsec Monitoring mib" and "IPsec Interactions with ECN" document spell it as IPsec while the "IPSec DOI Textual Conventions MIB" spells it as IPSec. The "Implemeting IPsec" book (Kaufman and Newman) spells it with lower case s and Building and Managing VPNs (Kosiur) spell it with upper case S. If would really help if Security working group in IETF clarified this Niloo From owner-ipsec@lists.tislabs.com Thu May 4 13:19:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15335; Thu, 4 May 2000 13:19:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15555 Thu, 4 May 2000 14:49:31 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B003694D4D@hdsmsx31.hd.intel.com> From: "Shriver, John" To: "'Niloo Soleimani'" , ipsec@lists.tislabs.com Cc: smilley@cisco.com Subject: RE: IPsec or IPSec? Date: Thu, 4 May 2000 11:56:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPsec, according to Stephen Kent. It will be fixed in the next release of the "IPSec DOI Textual Conventions MIB". From owner-ipsec@lists.tislabs.com Thu May 4 13:46:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15642; Thu, 4 May 2000 13:46:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15685 Thu, 4 May 2000 15:25:08 -0400 (EDT) Message-Id: <200005041929.MAA01170@potassium.network-alchemy.com> To: "Shriver, John" cc: "'Niloo Soleimani'" , ipsec@lists.tislabs.com, smilley@cisco.com Subject: Re: IPsec or IPSec? In-reply-to: Your message of "Thu, 04 May 2000 11:56:41 PDT." <392A357CE6FFD111AC3E00A0C99848B003694D4D@hdsmsx31.hd.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1167.957468556.1@network-alchemy.com> Date: Thu, 04 May 2000 12:29:16 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPSec or IPsec? This must, surely, mean that the working group is over. Dan. On Thu, 04 May 2000 11:56:41 PDT you wrote > IPsec, according to Stephen Kent. It will be fixed in the next release of > the "IPSec DOI Textual Conventions MIB". > From owner-ipsec@lists.tislabs.com Thu May 4 13:54:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15739; Thu, 4 May 2000 13:54:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15497 Thu, 4 May 2000 14:33:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.2.0.58.20000504100418.00b6acd0@mira-sjcd-1.cisco.com> References: <4.2.0.58.20000504100418.00b6acd0@mira-sjcd-1.cisco.com> Date: Thu, 4 May 2000 14:34:21 -0400 To: Niloo Soleimani From: Stephen Kent Subject: Re: IPsec or IPSec? Cc: ipsec@lists.tislabs.com, smilley@cisco.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Niloo, The correct spelling is "IPsec" as per RFC 2401 (the IPsec architecture), 2402 (AH), and most if not all of the the other documents that have become standards track RFCs. Steve From owner-ipsec@lists.tislabs.com Fri May 5 08:01:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11106; Fri, 5 May 2000 08:01:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18686 Fri, 5 May 2000 09:58:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 5 May 2000 09:58:59 -0400 To: "Kavsan, Bronislav" From: Stephen Kent Subject: RE: IPsec or IPSec? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:41 AM -0400 5/5/00, Kavsan, Bronislav wrote: >How come then - Dan Harkins, who co-authored some major RFCs named his book >"IPSec The New Security Standard...." and uses this spelling throghout the >book? > >(Just a little subliminal commercial for Dan :) > Typos happen :-) Steve From owner-ipsec@lists.tislabs.com Fri May 5 08:01:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11121; Fri, 5 May 2000 08:01:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18592 Fri, 5 May 2000 09:34:12 -0400 (EDT) Message-ID: From: "Kavsan, Bronislav" To: "'Stephen Kent'" , Niloo Soleimani Cc: ipsec@lists.tislabs.com, smilley@cisco.com Subject: RE: IPsec or IPSec? Date: Fri, 5 May 2000 09:41:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How come then - Dan Harkins, who co-authored some major RFCs named his book "IPSec The New Security Standard...." and uses this spelling throghout the book? (Just a little subliminal commercial for Dan :) > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Thursday, May 04, 2000 2:34 PM > To: Niloo Soleimani > Cc: ipsec@lists.tislabs.com; smilley@cisco.com > Subject: Re: IPsec or IPSec? > > > Niloo, > > The correct spelling is "IPsec" as per RFC 2401 (the IPsec > architecture), 2402 (AH), and most if not all of the the other > documents that have become standards track RFCs. > > Steve > From owner-ipsec@lists.tislabs.com Fri May 5 11:04:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13805; Fri, 5 May 2000 11:04:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19262 Fri, 5 May 2000 12:51:05 -0400 (EDT) Message-ID: <310508EDF557D31188FA0050DA0A37522CC1A8@CAT01S2> From: Tim Jenkins To: ipsec@lists.tislabs.com Subject: Rekeying Document: Final? Date: Fri, 5 May 2000 12:58:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFB6B3.1E685D30" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFB6B3.1E685D30 Content-Type: text/plain; charset="iso-8859-1" All, A (hopefully) final version of the re-keying document is available at . If there are no serious objections, I'm going to request this be submitted as an informational RFC. Tim ------_=_NextPart_000_01BFB6B3.1E685D30 Content-Type: application/octet-stream; name="Tim Jenkins (E-mail).vcf" Content-Disposition: attachment; filename="Tim Jenkins (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Jenkins;Tim FN:Tim Jenkins (E-mail) ORG:Catena Neworks Inc. TEL;WORK;VOICE:(613) 599-6430 x494 TEL;WORK;FAX:(613) 599-6433 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;Suite 300=0D=0A320 March Road;Kanata;ON;K2K 2E3;Canada LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Suite 300=0D=0A320 March Road=0D=0AKanata, ON K2K 2E3=0D=0ACanada EMAIL;PREF;INTERNET:TJenkins@CatenaNet.com REV:20000317T151855Z END:VCARD ------_=_NextPart_000_01BFB6B3.1E685D30-- From owner-ipsec@lists.tislabs.com Fri May 5 12:26:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14663; Fri, 5 May 2000 12:26:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19655 Fri, 5 May 2000 14:13:14 -0400 (EDT) Message-ID: <001101bfb6be$534474e0$fa811818@we.mediaone.net> From: "Mark" To: References: Subject: Re: IPsec or IPSec? Date: Fri, 5 May 2000 11:18:33 -0700 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.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think this battle may already be lost. It would appear that most commercial products and industry references use the spelling 'IPSec' - the other variant seems to be rare... ----- Original Message ----- From: "Stephen Kent" To: "Kavsan, Bronislav" Cc: Sent: Friday, May 05, 2000 6:58 AM Subject: RE: IPsec or IPSec? > At 9:41 AM -0400 5/5/00, Kavsan, Bronislav wrote: > >How come then - Dan Harkins, who co-authored some major RFCs named his book > >"IPSec The New Security Standard...." and uses this spelling throghout the > >book? > > > >(Just a little subliminal commercial for Dan :) > > > > Typos happen :-) > > Steve > From owner-ipsec@lists.tislabs.com Fri May 5 12:26:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14662; Fri, 5 May 2000 12:26:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19617 Fri, 5 May 2000 14:02:13 -0400 (EDT) Message-Id: <4.2.0.58.20000505110631.00ba9c60@mira-sjcd-1.cisco.com> X-Sender: nsoleima@mira-sjcd-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 05 May 2000 11:09:51 -0700 To: Stephen Kent From: Niloo Soleimani Subject: RE: IPsec or IPSec? Cc: "Kavsan, Bronislav" , ipsec@lists.tislabs.com In-Reply-To: References: < Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Will anybody be cleaning up the the IETF web site to ensure there are no typos!! and that proper spelling is used at least on that site? Niloo At 09:58 AM 5/5/00 -0400, Stephen Kent wrote: >At 9:41 AM -0400 5/5/00, Kavsan, Bronislav wrote: >>How come then - Dan Harkins, who co-authored some major RFCs named his book >>"IPSec The New Security Standard...." and uses this spelling throghout the >>book? >> >>(Just a little subliminal commercial for Dan :) > >Typos happen :-) > >Steve > From owner-ipsec@lists.tislabs.com Fri May 5 12:43:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14822; Fri, 5 May 2000 12:43:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19755 Fri, 5 May 2000 14:38:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <001101bfb6be$534474e0$fa811818@we.mediaone.net> References: <001101bfb6be$534474e0$fa811818@we.mediaone.net> Date: Fri, 5 May 2000 14:39:33 -0400 To: "Mark" From: Stephen Kent Subject: Re: IPsec or IPSec? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, most trade publications and many vendors get it wrong, but if the RFCs are consistent, we can always remind them what the "right" spelling is :-) I don't support codification of the marketing-driven misspelling by changing the RFCs. Steve From owner-ipsec@lists.tislabs.com Fri May 5 12:44:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14837; Fri, 5 May 2000 12:44:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19773 Fri, 5 May 2000 14:42:45 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 5 May 2000 11:48:57 -0700 (PDT) From: Jan Vilhuber To: ipsec@lists.tislabs.com Subject: Re: IPsec or IPSec? In-Reply-To: <001101bfb6be$534474e0$fa811818@we.mediaone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Will someone PLEASE ask me whether I care how IPSEC is written? jan On Fri, 5 May 2000, Mark wrote: > I think this battle may already be lost. It would appear that most > commercial products and industry references use the spelling 'IPSec' - the > other variant seems to be rare... > > ----- Original Message ----- > From: "Stephen Kent" > To: "Kavsan, Bronislav" > Cc: > Sent: Friday, May 05, 2000 6:58 AM > Subject: RE: IPsec or IPSec? > > > > At 9:41 AM -0400 5/5/00, Kavsan, Bronislav wrote: > > >How come then - Dan Harkins, who co-authored some major RFCs named his > book > > >"IPSec The New Security Standard...." and uses this spelling throghout > the > > >book? > > > > > >(Just a little subliminal commercial for Dan :) > > > > > > > Typos happen :-) > > > > Steve > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Fri May 5 12:51:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14904; Fri, 5 May 2000 12:51:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19784 Fri, 5 May 2000 14:46:15 -0400 (EDT) Date: Fri, 5 May 2000 11:53:11 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Dan Harkins cc: "Shriver, John" , "'Niloo Soleimani'" , ipsec@lists.tislabs.com, smilley@cisco.com Subject: Re: IPsec or IPSec? In-Reply-To: <200005041929.MAA01170@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The tech people feel that everything is done. Marketing has taken over! -chinna On Thu, 4 May 2000, Dan Harkins wrote: > IPSec or IPsec? This must, surely, mean that the working group is over. > > Dan. > > On Thu, 04 May 2000 11:56:41 PDT you wrote > > IPsec, according to Stephen Kent. It will be fixed in the next release of > > the "IPSec DOI Textual Conventions MIB". > > > chinna narasimha reddy pellacuru s/w engineer "I have no love of technology for technology's sake, Only solutions for customers." John Chambers From owner-ipsec@lists.tislabs.com Fri May 5 12:54:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA15066; Fri, 5 May 2000 12:54:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19814 Fri, 5 May 2000 14:51:42 -0400 (EDT) Message-Id: <200005051858.e45Iwdb29745@adk.gr> X-Mailer: exmh version 2.0.2 2/24/98 To: Jan Vilhuber Cc: ipsec@lists.tislabs.com Subject: Re: IPsec or IPSec? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 May 2000 14:58:39 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: >Will someone PLEASE ask me whether I care how IPSEC is written? > >jan Nobody cares to ask. -Angelos From owner-ipsec@lists.tislabs.com Fri May 5 13:03:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15419; Fri, 5 May 2000 13:03:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19841 Fri, 5 May 2000 14:57:09 -0400 (EDT) Message-Id: <4.2.0.58.20000505150709.00a3ae20@pop3.indusriver.com> Date: Fri, 05 May 2000 15:12:07 -0400 To: "Mark" From: David Chen Subject: Re: IPsec or IPSec? Cc: ipsec@lists.tislabs.com In-Reply-To: <001101bfb6be$534474e0$fa811818@we.mediaone.net> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_14534349==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_14534349==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Mark, I vote for IPSec. It's simple. IPSec stands for Internetworking Protocol Security. IPsec stands for Internetworking Psec? Naming is very important for historian. :o) --- David At 11:18 AM 5/5/00 -0700, you wrote: >I think this battle may already be lost. It would appear that most >commercial products and industry references use the spelling 'IPSec' - the >other variant seems to be rare... > >----- Original Message ----- >From: "Stephen Kent" >To: "Kavsan, Bronislav" >Cc: >Sent: Friday, May 05, 2000 6:58 AM >Subject: RE: IPsec or IPSec? > > > > At 9:41 AM -0400 5/5/00, Kavsan, Bronislav wrote: > > >How come then - Dan Harkins, who co-authored some major RFCs named his >book > > >"IPSec The New Security Standard...." and uses this spelling throghout >the > > >book? > > > > > >(Just a little subliminal commercial for Dan :) > > > > > > > Typos happen :-) > > > > Steve > > --=====================_14534349==_.ALT Content-Type: text/html; charset="us-ascii" Mark,
I vote for IPSec.  It's simple.
IPSec stands for Internetworking Protocol Security.
IPsec stands for Internetworking Psec?

Naming is very important for historian.  :o)

--- David

At 11:18 AM 5/5/00 -0700, you wrote:
I think this battle may already be lost.  It would appear that most
commercial products and industry references use the spelling 'IPSec' - the
other variant seems to be rare...

----- Original Message -----
From: "Stephen Kent" <kent@bbn.com>
To: "Kavsan, Bronislav" <bkavsan@rsasecurity.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Friday, May 05, 2000 6:58 AM
Subject: RE: IPsec or IPSec?


> At 9:41 AM -0400 5/5/00, Kavsan, Bronislav wrote:
> >How come then - Dan Harkins, who co-authored some major RFCs named his
book
> >"IPSec The New Security Standard...." and uses this spelling throghout
the
> >book?
> >
> >(Just a little subliminal commercial for Dan :)
> >
>
> Typos happen :-)
>
> Steve
>
--=====================_14534349==_.ALT-- From owner-ipsec@lists.tislabs.com Fri May 5 13:26:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15607; Fri, 5 May 2000 13:26:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19925 Fri, 5 May 2000 15:17:25 -0400 (EDT) Message-Id: <4.3.1.2.20000505151829.00e2a7f0@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 05 May 2000 15:20:50 -0400 To: "Shriver, John" , "'Niloo Soleimani'" , ipsec@lists.tislabs.com From: Robert Moskowitz Subject: RE: IPsec or IPSec? Cc: smilley@cisco.com In-Reply-To: <392A357CE6FFD111AC3E00A0C99848B003694D4D@hdsmsx31.hd.intel .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:56 AM 5/4/2000 -0700, Shriver, John wrote: >IPsec, according to Stephen Kent. It will be fixed in the next release of >the "IPSec DOI Textual Conventions MIB". somewhere back in the early grey dawn of this protocol. IPsec was chosen. To wax a little poetic: IP grandstands. It gladly shows off to all how it moves the data around. security quietly goes about its business. :) Back to my PKIX - CMP testing. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Fri May 5 16:22:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17362; Fri, 5 May 2000 16:22:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20564 Fri, 5 May 2000 17:57:08 -0400 (EDT) Reply-To: From: "Jim Stephenson-Dunn" To: "'Robert Moskowitz'" , "'Shriver, John'" , "'Niloo Soleimani'" , Cc: Subject: RE: IPsec or IPSec? Date: Fri, 5 May 2000 15:04:30 -0700 Message-ID: <01C88F753E97D311A7180090278D1D40689B89@teamsf.yipes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <01C88F753E97D311A7180090278D1D40769467@teamsf.yipes.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For what it is worth, I believe that the correct use of English language would dictate that the spelling should be IPsec unless a space was invoked in which case the spelling would be IP Sec And just to further complicate things, there is an absense of periods. I believe the gramatically correct form would be I.P. Sec. where the period denotes an incomplete word. But just out of curiosity, Jan how would you like to spell it ? Jim Jim Dunn Senior Network Engineer San Francisco NOC -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Robert Moskowitz Sent: Friday, May 05, 2000 12:21 PM To: Shriver, John; 'Niloo Soleimani'; ipsec@lists.tislabs.com Cc: smilley@cisco.com Subject: RE: IPsec or IPSec? At 11:56 AM 5/4/2000 -0700, Shriver, John wrote: >IPsec, according to Stephen Kent. It will be fixed in the next release of >the "IPSec DOI Textual Conventions MIB". somewhere back in the early grey dawn of this protocol. IPsec was chosen. To wax a little poetic: IP grandstands. It gladly shows off to all how it moves the data around. security quietly goes about its business. :) Back to my PKIX - CMP testing. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Sat May 6 06:03:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08099; Sat, 6 May 2000 06:03:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA22206 Sat, 6 May 2000 07:50:25 -0400 (EDT) Message-ID: <002201bfb752$278d34b0$843dc082@vpn.csp.it> From: "Andrea Schiavoni" To: Subject: Windows 2000 and Cicsco router interoperability Date: Sat, 6 May 2000 13:56:46 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01BFB762.EAC091B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.5600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.5600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001F_01BFB762.EAC091B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Has anybody tried ISAKMP between W2000 and Cisco routers? I have tried with pre-shared secret authentication method: des-sha1 and des-md5 in main mode des-esp , des-sha1 , des-md5 and ah in quick mode They successfully worked in main mode, but they couldn't setup the = IPsec SA in quick mode. Thanks Andrea Schiavoni ------=_NextPart_000_001F_01BFB762.EAC091B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Has anybody tried ISAKMP between = W2000 and=20 Cisco routers?
I have tried with pre-shared secret = authentication=20 method:
des-sha1 and des-md5 in main = mode
des-esp , des-sha1 , des-md5 and ah in = quick=20 mode
 
They successfully worked in main mode,=20 but they couldn't setup the IPsec SA in quick = mode.
Thanks
Andrea = Schiavoni
------=_NextPart_000_001F_01BFB762.EAC091B0-- From owner-ipsec@lists.tislabs.com Mon May 8 07:54:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17197; Mon, 8 May 2000 07:54:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA27821 Mon, 8 May 2000 08:51:46 -0400 (EDT) Date: Fri, 5 May 2000 09:46:56 -0400 (EDT) From: "David M. Balenson" Message-Id: <200005051346.JAA28945@clipper.gw.tislabs.com> To: ipsec@lists.tislabs.com Subject: CFP: ISOC Netw & Distr Sys Security Symp (NDSS'01) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk C A L L F O R P A P E R S The Internet Society 2001 Network and Distributed System Security Symposium (NDSS'01) February 7-9, 2001 Catamaran Resort, San Diego, California IMPORTANT DATES Paper Submission due: August 2, 2000 Author Notification: September 27, 2000 Camera-ready final papers due: October 31, 2000 GOAL: This symposium will foster information exchange among researchers and practioners of network and distributed system security services. The intended audience includes those who are interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. A major goal of the symposium is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings of the symposium will be published by the Internet Society. Submissions are solicited for, but are not limited to, the following topics: * Secure Electronic Commerce: e.g., payment, barter, EDI, notarization/timestamping, endorsement and licensing. * Intellectual Property Protection: protocols, schemas, implementations, metering, watermarking, other forms of rights management. * Implementation, deployment and management of network security policies. * Integrating Security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web. * Attack-resistant protocols and services. * Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost. * Security for collaborative applications and services: tele- and video-conferencing, groupwork, etc. * Fundamental services: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification, revocation, audit trails and accountability. * Public Key Infrastructure. * Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, database management, boot services, mobile computing. * Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems. * Intrusion Avoidance, Detection, and Response: systems, experiences and architectures. * Network Perimeter Controls: firewalls, packet filters, application gateways. * Virtual Private Networks. BEST PAPER AWARD: There will be a best paper award again this year. The award will be presented at the symposium to the authors of the best overall paper as selected by the Program Committee. SUBMISSIONS: The Program Committee invites both technical papers and panel proposals. Technical papers should be at most 20 pages long. Panel proposals should be at most two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may - at the discretion of the panel chair - include written position statements from the panelists. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, e-mail addresses, and must specify the contact author in case of multi-author submissions. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by August 2, 2000, and must be made via electronically in either PostScript or ASCII format. If the Committee is unable to print a PostScript submission, a hardcopy will be requested. Therefore, PostScript submissions must arrive well before the deadline. Submission information can be found at http://www.isoc.org/ndss01/cfp. Dates, final call for papers, advance program, and registration information will be available soon at http://www.isoc.org/ndss01. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program Co-chairs as indicated below. Authors and panelists will be notified of acceptance by September 27, 2000. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by October 31, 2000. GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CO-CHAIRS: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies TUTORIAL CHAIR: Eric Harder, National Security Agency LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Mahesh Tripunitara, Purdue University PUBLICITY CHAIR: David Balenson, NAI Labs, Network Associates LOGISTICS CHAIR: Carla Rosenfeld, Internet Society PROGRAM COMMITTEE: Bennet Yee, University of California San Diego Bill Cheswick, Bell Labs Dave Kormann, AT&T Labs - Research David Aucksmith, Intel Corportation David P. Maher, Intertrust David Wagner, UC Berkeley Edward W. Felten, Princeton University Fabian Monrose, Bell Labs Gary McGraw, Reliable Software Technologies James Ellis, Sun Microsystems Kevin McCurley, IBM Almaden Research Center Matt Bishop, UC Davis Mudge, L0pht Heavy Industries, Inc. Peter Gutmann, University of Auckland, New Zealand Radia Perlman, Sun Microsystems Sandra Murphy, Network Associates Tom Berson, Anagram Laboratories Virgil D. Gligor, University of Maryland From owner-ipsec@lists.tislabs.com Mon May 8 08:18:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17526; Mon, 8 May 2000 08:18:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28148 Mon, 8 May 2000 09:53:01 -0400 (EDT) Message-ID: <403626CA58D4D3119B92005004A51488012504@DOMINUS> From: Patrick Ethier To: "'Andrea Schiavoni'" , ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Mon, 8 May 2000 10:06:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB8F6.B0543940" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFB8F6.B0543940 Content-Type: text/plain; charset="iso-8859-1" It was brought to my attention about a month ago that W2K does not support tunneling mode. I can't confirm whether that is true or not because I haven't bothered to verify it. Try changing from tunnel to transport in your quick mode and see if it works. Let me know, I'm curious to find out if this is the case. Regards, ________________ Patrick Ethier Product Development SecureOps Inc. patrick@secureops.com (514) 982-0678 x 106 (514) 982-0362 - fax -----Original Message----- From: Andrea Schiavoni [mailto:s81331@cclinf.polito.it] Sent: Saturday, May 06, 2000 7:57 AM To: ipsec@lists.tislabs.com Subject: Windows 2000 and Cicsco router interoperability Has anybody tried ISAKMP between W2000 and Cisco routers? I have tried with pre-shared secret authentication method: des-sha1 and des-md5 in main mode des-esp , des-sha1 , des-md5 and ah in quick mode They successfully worked in main mode, but they couldn't setup the IPsec SA in quick mode. Thanks Andrea Schiavoni ------_=_NextPart_001_01BFB8F6.B0543940 Content-Type: text/html; charset="iso-8859-1"
It was brought to my attention about a month ago that W2K does not support tunneling mode. I can't confirm whether that is true or not because I haven't bothered to verify it. Try changing from tunnel to transport in your quick mode and see if it works. Let me know, I'm curious to find out if this is the case.
 
 
Regards,
 

________________
Patrick Ethier
Product Development
SecureOps Inc.
patrick@secureops.com
(514) 982-0678 x 106
(514) 982-0362 - fax

-----Original Message-----
From: Andrea Schiavoni [mailto:s81331@cclinf.polito.it]
Sent: Saturday, May 06, 2000 7:57 AM
To: ipsec@lists.tislabs.com
Subject: Windows 2000 and Cicsco router interoperability

Has anybody tried ISAKMP between W2000 and Cisco routers?
I have tried with pre-shared secret authentication method:
des-sha1 and des-md5 in main mode
des-esp , des-sha1 , des-md5 and ah in quick mode
 
They successfully worked in main mode, but they couldn't setup the IPsec SA in quick mode.
Thanks
Andrea Schiavoni
------_=_NextPart_001_01BFB8F6.B0543940-- From owner-ipsec@lists.tislabs.com Mon May 8 09:37:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18669; Mon, 8 May 2000 09:37:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28371 Mon, 8 May 2000 10:40:01 -0400 (EDT) Message-Id: <200005081449.JAA16886@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Patrick Ethier cc: "'Andrea Schiavoni'" , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: Windows 2000 and Cicsco router interoperability In-reply-to: Your message of "Mon, 08 May 2000 10:06:57 EDT." <403626CA58D4D3119B92005004A51488012504@DOMINUS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 May 2000 09:49:59 -0500 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > It was brought to my attention about a month ago that W2K does not support > tunneling mode. I can't confirm whether that is true or not because I > haven't bothered to verify it. Try changing from tunnel to transport in your > quick mode and see if it works. Let me know, I'm curious to find out if this > is the case. I believe it is the case that Windows 2000 Professional only support L2TP as the tunneling protocol (which may be over a IPSEC transport session). The Server and Advanced Server editions can support IPSEC tunnels when acting as a gateway device. See White Paper for the Windows 2000 Server operating system entitled Microsoft Privacy Protected Network Access: Virtual Private Networking and Intranet Security I have a paper copy and I'm not sure if it came off web site or the MSDN subscription. Regards, Michael Carney > > > Regards, > > ________________ > Patrick Ethier > Product Development > SecureOps Inc. > patrick@secureops.com > (514) 982-0678 x 106 > (514) 982-0362 - fax > > -----Original Message----- > From: Andrea Schiavoni [mailto:s81331@cclinf.polito.it] > Sent: Saturday, May 06, 2000 7:57 AM > To: ipsec@lists.tislabs.com > Subject: Windows 2000 and Cicsco router interoperability > > > Has anybody tried ISAKMP between W2000 and Cisco routers? > I have tried with pre-shared secret authentication method: > des-sha1 and des-md5 in main mode > des-esp , des-sha1 , des-md5 and ah in quick mode > > They successfully worked in main mode, but they couldn't setup the IPsec SA > in quick mode. > Thanks > Andrea Schiavoni > > > ------_=_NextPart_001_01BFB8F6.B0543940 > Content-Type: text/html; > charset="iso-8859-1" > > > > > > > > > > >
It was > brought to my attention about a month ago that W2K does not support tunneling > mode. I can't confirm whether that is true or not because I haven't bothered to > verify it. Try changing from tunnel to transport in your quick mode and see if > it works. Let me know, I'm curious to find out if this is the > case.
>
class=799300014-08052000> 
>
class=799300014-08052000> 
>
class=799300014-08052000>Regards,
>
class=799300014-08052000> 
>
>

________________
size=2>Patrick Ethier
Product > Development
SecureOps Inc.
face=Arial size=2>patrick@secureops.com
(514) > 982-0678 x 106
(514) 982-0362 - fax >

>
>
size=2>-----Original Message-----
From: Andrea Schiavoni > [mailto:s81331@cclinf.polito.it]
Sent: Saturday, May 06, 2000 7:57 > AM
To: ipsec@lists.tislabs.com
Subject: Windows 2000 and > Cicsco router interoperability

>
Has anybody tried ISAKMP between W2000 and > Cisco routers?
>
I have tried with pre-shared secret > authentication method:
>
des-sha1 and des-md5 in main mode
>
des-esp , des-sha1 , des-md5 and ah in quick > mode
>
 
>
They successfully worked in main mode, > but they couldn't setup the IPsec SA in quick mode.
>
Thanks
>
Andrea > Schiavoni
> > ------_=_NextPart_001_01BFB8F6.B0543940-- From owner-ipsec@lists.tislabs.com Mon May 8 09:37:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18683; Mon, 8 May 2000 09:37:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28623 Mon, 8 May 2000 11:26:49 -0400 (EDT) Message-ID: From: Khurram Salman-ASK004 To: "'Patrick Ethier'" , "'Andrea Schiavoni'" , ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Mon, 8 May 2000 10:34:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Windows 2000 IPSec client only works in transport mode and uses certificates (although it will let you configure pre-shared secret but client will ignore pre-shared and look for cert. when you will try to fire up the client) in client-to-gateway scenario. Tunnel mode is only supported when win 2000 is configured to work as a gateway and not as a client. Rgds, Salman -----Original Message----- From: Patrick Ethier [mailto:pat@secureops.com] Sent: Monday, May 08, 2000 9:07 AM To: 'Andrea Schiavoni'; ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability It was brought to my attention about a month ago that W2K does not support tunneling mode. I can't confirm whether that is true or not because I haven't bothered to verify it. Try changing from tunnel to transport in your quick mode and see if it works. Let me know, I'm curious to find out if this is the case. Regards, ________________ Patrick Ethier Product Development SecureOps Inc. patrick@secureops.com (514) 982-0678 x 106 (514) 982-0362 - fax -----Original Message----- From: Andrea Schiavoni [mailto:s81331@cclinf.polito.it] Sent: Saturday, May 06, 2000 7:57 AM To: ipsec@lists.tislabs.com Subject: Windows 2000 and Cicsco router interoperability Has anybody tried ISAKMP between W2000 and Cisco routers? I have tried with pre-shared secret authentication method: des-sha1 and des-md5 in main mode des-esp , des-sha1 , des-md5 and ah in quick mode They successfully worked in main mode, but they couldn't setup the IPsec SA in quick mode. Thanks Andrea Schiavoni From owner-ipsec@lists.tislabs.com Tue May 9 06:39:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18790; Tue, 9 May 2000 06:39:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07802 Tue, 9 May 2000 08:05:02 -0400 (EDT) Message-Id: <200005081911.PAA15942@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , iana@iana.org Cc: Internet Architecture Board Cc: ipsec@lists.tislabs.com From: The IESG Subject: Protocol Action: The Use of HMAC-RIPEMD-160-96 within ESP and AH to Proposed Standard Date: Mon, 08 May 2000 15:11:55 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has approved the Internet-Draft 'The Use of HMAC-RIPEMD-160-96 within ESP and AH' as a Proposed Standard. This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Technical Summary This document describes an HMAC mode for the RIPEMD secure hash algorithm for use within ESP and AH in IPSEC. The European community prefers RIPEMD over both SHA-1 and MD5, so an HMAC mode is necessary that describes the use of RIPEMD. Working Group Summary There was working group concensus on this document, although not a lot of commentary. The document describes the "obvious" solution. Protocol Quality This document has been reviewed for the IESG by Marcus Leech. Note to RFC Editor: The IESG requests the RFC Editor to modify the text in the reference of RFC2104 as follows: OLD: [RFC-2104] discusses requirements for key material, which includes a discussion on requirements for strong randomness. A strong pseudo- random function MUST be used to generate the required 160-bit key. NEW: [RFC-2104] discusses requirements for key material, which includes a discussion on requirements for strong randomness. A strong pseudo- random function MUST be used to generate the required 160-bit key. Implementors should refer to RFC-1750 for guidance on the requirements for such functions. Also, please change the RIPEMD-160 Reference to: 3.ISO/IEC 10118-3:1998, ``Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions,'' International Organization for Standardization, Geneva, Switzerland, 1998. From owner-ipsec@lists.tislabs.com Tue May 9 08:40:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21142; Tue, 9 May 2000 08:40:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08531 Tue, 9 May 2000 10:03:51 -0400 (EDT) Reply-To: From: "Vinod Porwal" To: Subject: Windows 2000 IPSec Implementation queries Date: Tue, 9 May 2000 19:47:49 +0530 Message-ID: <000801bfb9c1$5b444250$4c01a8c0@vinod> 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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I want to use a windows 2000 host to establish a IPSEC tunnel mode to a IPSEC VPN Server .What all configuration is supported on W2K. Is ISAKMP/OAKLEY (IKE) and X509v3 certificates supported in Windows 2000 ? What Edition of Windows 2000 do I need to get the complete IPSEC implementation ? Regards, Vinod From owner-ipsec@lists.tislabs.com Tue May 9 09:00:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21494; Tue, 9 May 2000 09:00:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08809 Tue, 9 May 2000 10:46:55 -0400 (EDT) X-Lotus-FromDomain: 3COM From: "Philippe Piemont" To: Mike Carney cc: ipsec@lists.tislabs.com Message-ID: <802568DA.00537107.00@notesmta.eur.3com.com> Date: Tue, 9 May 2000 16:52:45 +0200 Subject: Re: Windows 2000 and Cicsco router interoperability Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Mike To be able to sell the 3Com 3CR990 NIC Card (card allowing to offload encryption to a dedicated ASIC (VLSI)) I had to demonstrate to the French NSA (SCSSI) the following config: PCA (windows 95 no encryption) ---- PC1 (Windows 2K Professionnal IPSEC in tunnel mode) ====== PC2 (Windows 2K Professionnal IPSEC in tunnel mode) ---- PC2 (windows 95 no encryption) the test was a ping from PC1 to PC2 with an analyser on the tunnel No doubt it works fine Best regards Philippe From owner-ipsec@lists.tislabs.com Tue May 9 12:21:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26126; Tue, 9 May 2000 12:21:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09700 Tue, 9 May 2000 13:56:12 -0400 (EDT) Message-ID: <3918530F.73934DD0@broadpac.com> Date: Tue, 09 May 2000 11:03:59 -0700 From: "N. Muralidhar" X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IPsec mailing list Subject: ISAKMP doubt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I'm having two devices (X & Y) using IKE with main mode with a pre shared key as Phase 1 and Quick mode as Phase 2. One of them (X) comes up little earlier than the other (Y) and both of them find out that a Phase 1 has to be established with the other device. Both (X & Y) are receiving and sending on port 500. Since X came up little earlier, the packet containing was not received by Y. Later Y sends a packet containing with Y as the initiator. X drops this packet from Y considering it as the response to it's first packet. Later Y drops the retransmitted packet sent by X in a similar fashion. In this way X & Y are not converging and are not able to establish Phase 1. Is there a way to solve this problem or Is it that I'm missing something which is very basic? Regards, Narasimha Murali From owner-ipsec@lists.tislabs.com Tue May 9 14:50:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28307; Tue, 9 May 2000 14:50:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10275 Tue, 9 May 2000 16:46:07 -0400 (EDT) From: "JACK MASON" To: "N. Muralidhar" , "IPsec mailing list" Subject: Re: ISAKMP doubt Date: Tue, 9 May 2000 16:53:03 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20000509205335.DDYI931.dorsey@jack> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Message 1 should have only the INITIATOR Cookie while Message 2 (response) should have both INITIATOR and RESPONDER Cookies. You shouldn't reject the 'response' if it only has one cookie, it's not a response but an initial phase 1 message. While it isn't standard practice, if we detect a corresponding initiation between our own devices we drop the one with the higher IP address, although establishing two SAs shouldn't hurt, especially if they're short term. Jack ---------- > From: N. Muralidhar > To: IPsec mailing list > Subject: ISAKMP doubt > Date: Tuesday, May 09, 2000 2:03 PM > > Hi all, > I'm having two devices (X & Y) using IKE with main mode with a pre > shared key as Phase 1 and Quick mode as Phase 2. One of them (X) comes > up little earlier than the other (Y) and both of them find out that a > Phase 1 has to be established with the other device. Both (X & Y) are > receiving and sending on port 500. Since X came up little earlier, the > packet containing was not received by Y. Later Y sends a packet > containing with Y as the initiator. X drops this packet from Y > considering it as the response to it's first packet. Later Y drops the > retransmitted packet sent by X in a similar fashion. In this way X & Y > are not converging and are not able to establish Phase 1. Is there a way > to solve this problem or Is it that I'm missing something which is very > basic? > > Regards, > Narasimha Murali From owner-ipsec@lists.tislabs.com Wed May 10 02:54:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17651; Wed, 10 May 2000 02:54:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA12006 Wed, 10 May 2000 04:29:45 -0400 (EDT) Message-ID: <39191FBE.AE2FDBA5@surfnet.nl> Date: Wed, 10 May 2000 10:37:18 +0200 From: Jac Kloots Organization: SURFnet bv X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,nl MIME-Version: 1.0 To: ipsec@lists.tislabs.com CC: Mike Carney Subject: Re: Windows 2000 and Cicsco router interoperability References: <200005081449.JAA16886@jumpsrv.stp.securecomputing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Anybody tried using Windows 2000 as a client and a Cisco router as gateway? | W2k client --- The Internet --- Cisco Gateway -| Internal Lan | Does this work? which W2k version do I need to make this setup work? Jac Mike Carney wrote: > > > > > It was brought to my attention about a month ago that W2K does not support > > tunneling mode. I can't confirm whether that is true or not because I > > haven't bothered to verify it. Try changing from tunnel to transport in your > > quick mode and see if it works. Let me know, I'm curious to find out if this > > is the case. > > I believe it is the case that Windows 2000 Professional only support > L2TP as the tunneling protocol (which may be over a IPSEC transport > session). > > The Server and Advanced Server editions can support IPSEC tunnels when > acting as a gateway device. > > See White Paper for the Windows 2000 Server operating system entitled > Microsoft Privacy Protected Network Access: > Virtual Private Networking and Intranet Security > > I have a paper copy and I'm not sure if it came off web site or the > MSDN subscription. > Regards, > Michael Carney > -- Jac Kloots SURFnet bv The Netherlands From owner-ipsec@lists.tislabs.com Wed May 10 02:54:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17666; Wed, 10 May 2000 02:54:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA11985 Wed, 10 May 2000 04:26:50 -0400 (EDT) From: "Fabio Zamparelli" To: "Philippe Piemont" Cc: Subject: R: Windows 2000 and Cicsco router interoperability Date: Wed, 10 May 2000 10:34:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <802568DA.00537107.00@notesmta.eur.3com.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, in two months from now I'll be setting up a similar test bed for my university final thesis for IPSEC perfomance testing purpose. I'll use 3com 3CR990-TX-95 (but I was wondering if as an Academic I was able to have the TX-97 version), 2 Win2k in tunnel-mode authenticated by a Cert Server (in first istance a Win2k Server, but in a second time, for interoperability testing I think there will be a Linux Box) 4 or 5 standard router in the meddle and 2 win9x client on the two end sides. Are you sure in your test the win2k box were Professional and not Server? I thought I would need the Server version. As my second would be a transport test host to host (authenticated by certificates) with 2 Win2k Professional I'd be happy to know the workstastions could be the same as in the first test bed. Thanks, Fabio (Zed) Zamparelli Università di Napoli Federico II GRID (Gruppo di Ricerca sull'Informatica Distribuita-Research Group on Distributed Systems) http://www.grid.unina.it/ > -----Messaggio originale----- > Da: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]Per conto di Philippe Piemont > Inviato: martedì 9 maggio 2000 16.53 > A: Mike Carney > Cc: ipsec@lists.tislabs.com > Oggetto: Re: Windows 2000 and Cicsco router interoperability > > > > > Hi Mike > To be able to sell the 3Com 3CR990 NIC Card (card allowing to > offload encryption > to a dedicated ASIC (VLSI)) > I had to demonstrate to the French NSA (SCSSI) the following config: > PCA (windows 95 no encryption) ---- PC1 (Windows 2K Professionnal IPSEC in > tunnel mode) ====== PC2 (Windows 2K Professionnal IPSEC in tunnel > mode) ---- PC2 > (windows 95 no encryption) > the test was a ping from PC1 to PC2 > with an analyser on the tunnel > No doubt it works fine > Best regards > Philippe From owner-ipsec@lists.tislabs.com Wed May 10 04:23:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA23328; Wed, 10 May 2000 04:23:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12526 Wed, 10 May 2000 06:13:18 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A310@baltimore.com> From: Chris Trobridge To: Mike Carney Cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Wed, 10 May 2000 11:20:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What does this mean for secure remote access? The 'standard' IPSEC approach is to use an ESP tunnel to connect the client to a security GW on the edge of the corporate network. If tunnel mode isn't supported in the client then this isn't possible, as transport mode will only get you to the GW. Unless... Windows is relying on a transport mode ESP with L2TP tunneling to provide the secure pipe(?). Wouldn't this cause interoperability issues between Win2k professional and third party IPSEC security gateways? Chris > -----Original Message----- > From: Mike Carney [mailto:carney@securecomputing.com] > Sent: 08 May 2000 15:50 > To: Patrick Ethier > Cc: 'Andrea Schiavoni'; ipsec@lists.tislabs.com; > carney@jumpsrv.stp.securecomputing.com > Subject: Re: Windows 2000 and Cicsco router interoperability > > > > > > > It was brought to my attention about a month ago that W2K > does not support > > tunneling mode. I can't confirm whether that is true or not > because I > > haven't bothered to verify it. Try changing from tunnel to > transport in your > > quick mode and see if it works. Let me know, I'm curious to > find out if this > > is the case. > > I believe it is the case that Windows 2000 Professional only support > L2TP as the tunneling protocol (which may be over a IPSEC transport > session). > > The Server and Advanced Server editions can support IPSEC tunnels when > acting as a gateway device. > > See White Paper for the Windows 2000 Server operating system entitled > Microsoft Privacy Protected Network Access: > Virtual Private Networking and Intranet Security > > I have a paper copy and I'm not sure if it came off web site or the > MSDN subscription. > Regards, > Michael Carney > > > > > > > Regards, > > > > ________________ > > Patrick Ethier > > Product Development > > SecureOps Inc. > > patrick@secureops.com > > (514) 982-0678 x 106 > > (514) 982-0362 - fax > > > > -----Original Message----- > > From: Andrea Schiavoni [mailto:s81331@cclinf.polito.it] > > Sent: Saturday, May 06, 2000 7:57 AM > > To: ipsec@lists.tislabs.com > > Subject: Windows 2000 and Cicsco router interoperability > > > > > > Has anybody tried ISAKMP between W2000 and Cisco routers? > > I have tried with pre-shared secret authentication method: > > des-sha1 and des-md5 in main mode > > des-esp , des-sha1 , des-md5 and ah in quick mode > > > > They successfully worked in main mode, but they couldn't > setup the IPsec SA > > in quick mode. > > Thanks > > Andrea Schiavoni From owner-ipsec@lists.tislabs.com Wed May 10 06:21:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26132; Wed, 10 May 2000 06:21:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13071 Wed, 10 May 2000 08:20:30 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: TAHI IPv6 and IPsec conformance test suites and reports From: contact@tahi.org X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000510163533A.Hiroshi_Hoshino@yokogawa.co.jp> Date: Wed, 10 May 2000 16:35:33 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 30 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi there, TAHI Project has opened the IPv6 and IPsec conformance test suites (Release 1.0) and test reports about KAME IPv6 network code (http://www.kame.net/) at the following web site: the test suites: http://www.tahi.org/release/ the test reports: http://www.tahi.org/report/ Changes from the previous release of the conformance test suites: Add new test: - IPSec AH and ESP for IPv4 (RFC2401,RFC2402,RFC2406, ...etc) Although it's under development, we believe it's useful Some bug fixes: - use proper aggregatable global unicast address The following test reports were opened (by the test suites Release 1.0): - kame-20000425-freebsd228-stable - kame-20000425-freebsd34-stable Thanks! --- TAHI Project www.tahi.org contact@tahi.org From owner-ipsec@lists.tislabs.com Wed May 10 06:26:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26227; Wed, 10 May 2000 06:26:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13065 Wed, 10 May 2000 08:19:29 -0400 (EDT) Message-Id: <200005091834.LAA10082@nasnfs.eng.sun.com> Date: Tue, 9 May 2000 11:34:40 -0700 (PDT) From: Vipul Gupta Reply-To: Vipul Gupta Subject: Re: ISAKMP doubt To: nmdhara@broadpac.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IfLDI/yp/d6zMBHLGfCkgQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Date: Tue, 09 May 2000 11:03:59 -0700 > From: "N. Muralidhar" > X-Accept-Language: en > MIME-Version: 1.0 > To: IPsec mailing list > Subject: ISAKMP doubt > Content-Transfer-Encoding: 7bit > > Hi all, > I'm having two devices (X & Y) using IKE with main mode with a pre > shared key as Phase 1 and Quick mode as Phase 2. One of them (X) comes > up little earlier than the other (Y) and both of them find out that a > Phase 1 has to be established with the other device. Both (X & Y) are > receiving and sending on port 500. Since X came up little earlier, the > packet containing was not received by Y. Later Y sends a packet > containing with Y as the initiator. X drops this packet from Y > considering it as the response to it's first packet. X should not do this. When Y sends its first packet, the responder cookie field in the ISAKMP header is empty indicating it is the start of a new Phase I negotiation rather than a reply. The implementation on X seems broken. vipul > Later Y drops the > retransmitted packet sent by X in a similar fashion. In this way X & Y > are not converging and are not able to establish Phase 1. Is there a way > to solve this problem or Is it that I'm missing something which is very > basic? > > Regards, > Narasimha Murali > From owner-ipsec@lists.tislabs.com Wed May 10 06:40:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26486; Wed, 10 May 2000 06:40:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13274 Wed, 10 May 2000 08:39:05 -0400 (EDT) Message-ID: <39198215.A22D1E68@netseal.com> Date: Wed, 10 May 2000 18:36:53 +0300 From: Sami Vaarala Organization: NetSeal Technologies X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com, sami.vaarala@netseal.com Subject: Win2000 IKE and 3des Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Upon playing with Win2000 IPsec/IKE, I configured an IKE phase 2 policy that required one of the following ESP transforms: 3des + hmac-sha-1 auth, kb lifetime 100001, sec lifetime 900 3des + hmac-md5 auth, kb lifetime 100002, sec lifetime 900 [the lifetimes are set this way to identify the transforms at the other end] All is well and good, but the remote IKE end receives this offer *with 3des transforms changed into des*! Is this Windows' way of achieving exportability (by silently manipulating configuration)? Or is there something I missed? >From an administrator perspective, it is hard to imagine how a security hole could be worse: Windows lets you think all is OK but in reality something else happens on the wire. I'd appreciate it if anyone could verify this behavior; I suspect I've gotten something wrong. Win2000 version in 5.00.2195, and it should be the exportable version. -- For info, dump of the QM1 packet: RAW PACKET (decrypted QM1): dc 45 66 3d 26 35 41 af 28 1c a8 bd 8f e3 56 a9 08 10 20 01 4c 2f 52 23 00 00 00 cc 01 00 00 14 ba 41 8a c4 2a da bd 9c 9d 0d 29 f9 a7 17 f4 d1 0a 00 00 68 00 00 00 01 00 00 00 01 00 00 00 5c 01 03 04 02 f3 8c e3 e7 03 00 00 28 01 02 00 00 80 01 00 01 00 02 00 04 00 00 03 84 80 01 00 02 00 02 00 04 00 01 86 a1 80 04 00 02 80 05 00 02 00 00 00 28 02 02 00 00 80 01 00 01 00 02 00 04 00 00 03 84 80 01 00 02 00 02 00 04 00 01 86 a2 80 04 00 02 80 05 00 01 05 00 00 18 70 e3 bf 52 26 38 2a bb a3 5c b0 1f 25 0a 97 8e c7 28 7b 24 05 00 00 0c 01 00 00 00 c0 a8 02 c6 00 00 00 0c 01 00 00 00 c0 a8 02 c7 00 00 00 00 INTERPRETATION: --------------- *HDR* dc 45 66 3d 26 35 41 af 28 1c a8 bd 8f e3 56 a9 08 10 20 01 4c 2f 52 23 00 00 00 cc *HASH* 01 00 00 14 ba 41 8a c4 2a da bd 9c 9d 0d 29 f9 a7 17 f4 d1 *SA* 0a 00 00 68 00 00 00 01 00 00 00 01 doi=ipsec, sit=identity only 00 00 00 5c 01 03 04 02 prop #1, len 0x5c, proto=3 (esp), spi_size=4, #tran=2 f3 8c e3 e7 spi 0xf38ce3e7 03 00 00 28 01 02 00 00 tran #1, len 0x28, tran-id=2 (des) 80 01 00 01 00 02 00 04 00 00 03 84 80 01 00 02 00 02 00 04 00 01 86 a1 80 04 00 02 80 05 00 02 attribs: 0001=0001 sa life type: seconds 0002=00000384 sa life dur.: 900 (dec) 0001=0002 sa life type: kilobytes 0002=000186a1 sa life dur.: 100001 (dec) 0004=0002 encaps. mode: transport 0005=0002 auth. alg : hmac-sha 00 00 00 28 02 02 00 00 tran #2, len 0x28, tran-id=2 (des) 80 01 00 01 00 02 00 04 00 00 03 84 80 01 00 02 00 02 00 04 00 01 86 a2 80 04 00 02 80 05 00 01 attribs: 0001=0001 sa life type: seconds 0002=00000384 sa life dur.: 900 (dec) 0001=0002 sa life type: kilobytes 0002=000186a2 sa life dur.: 100002 (dec) 0004=0002 encaps. mode: transport 0005=0001 auth. alg : hmac-md5 *NONCE* 05 00 00 18 70 e3 bf 52 26 38 2a bb a3 5c b0 1f 25 0a 97 8e c7 28 7b 24 *ID* 05 00 00 0c 01 00 00 00 c0 a8 02 c6 *ID* 00 00 00 0c 01 00 00 00 c0 a8 02 c7 *PADDING* 00 00 00 00 -- Sami Vaarala (sami.vaarala@netseal.com) NetSeal Technologies http://www.netseal.com/ From owner-ipsec@lists.tislabs.com Wed May 10 08:08:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28040; Wed, 10 May 2000 08:08:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13718 Wed, 10 May 2000 09:35:22 -0400 (EDT) Message-Id: <200005101346.IAA19177@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Chris Trobridge cc: Mike Carney , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: Windows 2000 and Cicsco router interoperability In-reply-to: Your message of "Wed, 10 May 2000 11:20:43 BST." <1FD60AE4DB6CD2118C420008C74C27B854A310@baltimore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 May 2000 08:46:06 -0500 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > What does this mean for secure remote access? > > The 'standard' IPSEC approach is to use an ESP tunnel to connect the client > to a security GW on the edge of the corporate network. > > If tunnel mode isn't supported in the client then this isn't possible, as > transport mode will only get you to the GW. > > Unless... Windows is relying on a transport mode ESP with L2TP tunneling to > provide the secure pipe(?). It is. > Wouldn't this cause interoperability issues > between Win2k professional and third party IPSEC security gateways? > It does. Regards, Michael Carney > Chris > > > -----Original Message----- > > From: Mike Carney [mailto:carney@securecomputing.com] > > Sent: 08 May 2000 15:50 > > To: Patrick Ethier > > Cc: 'Andrea Schiavoni'; ipsec@lists.tislabs.com; > > carney@jumpsrv.stp.securecomputing.com > > Subject: Re: Windows 2000 and Cicsco router interoperability > > > > > > > > > > > > It was brought to my attention about a month ago that W2K > > does not support > > > tunneling mode. I can't confirm whether that is true or not > > because I > > > haven't bothered to verify it. Try changing from tunnel to > > transport in your > > > quick mode and see if it works. Let me know, I'm curious to > > find out if this > > > is the case. > > > > I believe it is the case that Windows 2000 Professional only support > > L2TP as the tunneling protocol (which may be over a IPSEC transport > > session). > > > > The Server and Advanced Server editions can support IPSEC tunnels when > > acting as a gateway device. > > > > See White Paper for the Windows 2000 Server operating system entitled > > Microsoft Privacy Protected Network Access: > > Virtual Private Networking and Intranet Security > > > > I have a paper copy and I'm not sure if it came off web site or the > > MSDN subscription. > > Regards, > > Michael Carney > > > > > > > > > > > Regards, > > > > > > ________________ > > > Patrick Ethier > > > Product Development > > > SecureOps Inc. > > > patrick@secureops.com > > > (514) 982-0678 x 106 > > > (514) 982-0362 - fax > > > > > > -----Original Message----- > > > From: Andrea Schiavoni [mailto:s81331@cclinf.polito.it] > > > Sent: Saturday, May 06, 2000 7:57 AM > > > To: ipsec@lists.tislabs.com > > > Subject: Windows 2000 and Cicsco router interoperability > > > > > > > > > Has anybody tried ISAKMP between W2000 and Cisco routers? > > > I have tried with pre-shared secret authentication method: > > > des-sha1 and des-md5 in main mode > > > des-esp , des-sha1 , des-md5 and ah in quick mode > > > > > > They successfully worked in main mode, but they couldn't > > setup the IPsec SA > > > in quick mode. > > > Thanks > > > Andrea Schiavoni From owner-ipsec@lists.tislabs.com Wed May 10 08:08:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28042; Wed, 10 May 2000 08:08:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13748 Wed, 10 May 2000 09:39:59 -0400 (EDT) Message-ID: <39195FCB.B04B7F88@indusriver.com> Date: Wed, 10 May 2000 09:10:35 -0400 From: Ben McCann MIME-Version: 1.0 To: Chris Trobridge CC: Mike Carney , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: <1FD60AE4DB6CD2118C420008C74C27B854A310@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chris Tolbridge wrote: > The 'standard' IPSEC approach is to use an ESP tunnel to connect the client > to a security GW on the edge of the corporate network. > > If tunnel mode isn't supported in the client then this isn't possible, as > transport mode will only get you to the GW. > > Unless... Windows is relying on a transport mode ESP with L2TP tunneling to > provide the secure pipe(?). Wouldn't this cause interoperability issues > between Win2k professional and third party IPSEC security gateways? Win2K does implement L2TP over IPSEC in transport mode. It uses PPP to transfer configuration information, such as a virtual IP address to the remote client. IMHO, an assigned virtual IP address is mandatory for remote access applications and Win2K does not, to my knowledge, implement Mode Config (or XAUTH). So, Win2K is not really appropriate for remote access application using native IPSEC tunnels. It relies upon L2TP for the same functionality. -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-ipsec@lists.tislabs.com Wed May 10 08:12:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28242; Wed, 10 May 2000 08:12:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13894 Wed, 10 May 2000 09:59:36 -0400 (EDT) Message-ID: <391994F3.320731FD@netseal.com> Date: Wed, 10 May 2000 19:57:23 +0300 From: Sami Vaarala Organization: NetSeal Technologies X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Win2000 IKE and 3des - resolved Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk After reading a few Win help files, I found a passage that documents this behavior; indeed, the 3des transforms are turned silently into des transforms. So it was an RTFM bug after all. (However I think the user interface is insane for not warning about the potential security problem in using des instead of 3des...) Beware .. :) -- Sami Vaarala (sami.vaarala@netseal.com) NetSeal Technologies http://www.netseal.com/ From owner-ipsec@lists.tislabs.com Wed May 10 11:27:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11619; Wed, 10 May 2000 11:27:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14383 Wed, 10 May 2000 12:18:03 -0400 (EDT) Message-Id: <200005101622.JAA19115@potassium.network-alchemy.com> To: Ben McCann cc: Chris Trobridge , Mike Carney , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability In-reply-to: Your message of "Wed, 10 May 2000 09:10:35 EDT." <39195FCB.B04B7F88@indusriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19112.957975730.1@network-alchemy.com> Date: Wed, 10 May 2000 09:22:10 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since when is implementation of Mode Config (or XAUTH) necessary to be appropriate for remote access? Actually, Win2K seems to be using _standard protocols_ (IPSec-- err, IPsec, L2TP, PPP) to solve the problem. Imagine that. Dan. On Wed, 10 May 2000 09:10:35 EDT you wrote > Win2K does implement L2TP over IPSEC in transport mode. It uses PPP > to transfer configuration information, such as a virtual IP address > to the remote client. IMHO, an assigned virtual IP address is mandatory > for remote access applications and Win2K does not, to my knowledge, > implement Mode Config (or XAUTH). So, Win2K is not really appropriate > for remote access application using native IPSEC tunnels. It relies > upon L2TP for the same functionality. > > -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-ipsec@lists.tislabs.com Wed May 10 11:27:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11632; Wed, 10 May 2000 11:27:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14549 Wed, 10 May 2000 13:07:31 -0400 (EDT) Message-ID: <3919983C.4DDC22B1@indusriver.com> Date: Wed, 10 May 2000 13:11:24 -0400 From: Ben McCann MIME-Version: 1.0 To: Dan Harkins CC: ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: <200005101622.JAA19115@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > > Since when is implementation of Mode Config (or XAUTH) necessary > to be appropriate for remote access? Actually, Win2K seems to be > using _standard protocols_ (IPSec-- err, IPsec, L2TP, PPP) to > solve the problem. Imagine that. > > Dan. I said "IMHO, an assigned virtual IP address is mandatory for remote access applications". Given that opinion, Mode Config is currently the most commonly implemented mechanism _within_ IPSEC that passes an IP address to a remote access client. (I know IPSRA is working on _new_ mechanisms but few, if any, of those mechanisms are implemented). L2TP over IPSEC also provides this functionality. I personally consider L2TP+PPP overkill just to pass down an IP address to a remote client so I have favored IPSEC with Mode Config instead of L2TP/PPP over IPSEC. Mode Config is dead in the IETF but many vendors, including your former employer, are shipping Mode Config to provide remote access over IPSEC without the overhead of L2TP. Hopefully, IPSRA will define a new mechanism (DHCP?) that also transmits client configuration without the overhead of a full L2TP and PPP stack. -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-ipsec@lists.tislabs.com Wed May 10 13:46:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14915; Wed, 10 May 2000 13:46:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15104 Wed, 10 May 2000 15:17:10 -0400 (EDT) Message-ID: From: Michel de Koning To: "'Sami Vaarala'" , ipsec@lists.tislabs.com Subject: RE: Win2000 IKE and 3des Date: Wed, 10 May 2000 21:23:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Sami, I noticed the same. Agree it is sloppy but to solve this I read somewhere that you have to install the high encryption pack and in the Netherlands you have to fill in some form. I haven't done that so far since I feel that DES is safe enough if you are changing the key more often. However this does have impact on performance of course. thx Michel -----Oorspronkelijk bericht----- Van: Sami Vaarala [mailto:sami.vaarala@netseal.com] Verzonden: Wednesday, May 10, 2000 5:37 PM Aan: ipsec@lists.tislabs.com; sami.vaarala@netseal.com Onderwerp: Win2000 IKE and 3des Hi, Upon playing with Win2000 IPsec/IKE, I configured an IKE phase 2 policy that required one of the following ESP transforms: 3des + hmac-sha-1 auth, kb lifetime 100001, sec lifetime 900 3des + hmac-md5 auth, kb lifetime 100002, sec lifetime 900 [the lifetimes are set this way to identify the transforms at the other end] All is well and good, but the remote IKE end receives this offer *with 3des transforms changed into des*! Is this Windows' way of achieving exportability (by silently manipulating configuration)? Or is there something I missed? >From an administrator perspective, it is hard to imagine how a security hole could be worse: Windows lets you think all is OK but in reality something else happens on the wire. I'd appreciate it if anyone could verify this behavior; I suspect I've gotten something wrong. Win2000 version in 5.00.2195, and it should be the exportable version. -- For info, dump of the QM1 packet: RAW PACKET (decrypted QM1): dc 45 66 3d 26 35 41 af 28 1c a8 bd 8f e3 56 a9 08 10 20 01 4c 2f 52 23 00 00 00 cc 01 00 00 14 ba 41 8a c4 2a da bd 9c 9d 0d 29 f9 a7 17 f4 d1 0a 00 00 68 00 00 00 01 00 00 00 01 00 00 00 5c 01 03 04 02 f3 8c e3 e7 03 00 00 28 01 02 00 00 80 01 00 01 00 02 00 04 00 00 03 84 80 01 00 02 00 02 00 04 00 01 86 a1 80 04 00 02 80 05 00 02 00 00 00 28 02 02 00 00 80 01 00 01 00 02 00 04 00 00 03 84 80 01 00 02 00 02 00 04 00 01 86 a2 80 04 00 02 80 05 00 01 05 00 00 18 70 e3 bf 52 26 38 2a bb a3 5c b0 1f 25 0a 97 8e c7 28 7b 24 05 00 00 0c 01 00 00 00 c0 a8 02 c6 00 00 00 0c 01 00 00 00 c0 a8 02 c7 00 00 00 00 INTERPRETATION: --------------- *HDR* dc 45 66 3d 26 35 41 af 28 1c a8 bd 8f e3 56 a9 08 10 20 01 4c 2f 52 23 00 00 00 cc *HASH* 01 00 00 14 ba 41 8a c4 2a da bd 9c 9d 0d 29 f9 a7 17 f4 d1 *SA* 0a 00 00 68 00 00 00 01 00 00 00 01 doi=ipsec, sit=identity only 00 00 00 5c 01 03 04 02 prop #1, len 0x5c, proto=3 (esp), spi_size=4, #tran=2 f3 8c e3 e7 spi 0xf38ce3e7 03 00 00 28 01 02 00 00 tran #1, len 0x28, tran-id=2 (des) 80 01 00 01 00 02 00 04 00 00 03 84 80 01 00 02 00 02 00 04 00 01 86 a1 80 04 00 02 80 05 00 02 attribs: 0001=0001 sa life type: seconds 0002=00000384 sa life dur.: 900 (dec) 0001=0002 sa life type: kilobytes 0002=000186a1 sa life dur.: 100001 (dec) 0004=0002 encaps. mode: transport 0005=0002 auth. alg : hmac-sha 00 00 00 28 02 02 00 00 tran #2, len 0x28, tran-id=2 (des) 80 01 00 01 00 02 00 04 00 00 03 84 80 01 00 02 00 02 00 04 00 01 86 a2 80 04 00 02 80 05 00 01 attribs: 0001=0001 sa life type: seconds 0002=00000384 sa life dur.: 900 (dec) 0001=0002 sa life type: kilobytes 0002=000186a2 sa life dur.: 100002 (dec) 0004=0002 encaps. mode: transport 0005=0001 auth. alg : hmac-md5 *NONCE* 05 00 00 18 70 e3 bf 52 26 38 2a bb a3 5c b0 1f 25 0a 97 8e c7 28 7b 24 *ID* 05 00 00 0c 01 00 00 00 c0 a8 02 c6 *ID* 00 00 00 0c 01 00 00 00 c0 a8 02 c7 *PADDING* 00 00 00 00 -- Sami Vaarala (sami.vaarala@netseal.com) NetSeal Technologies http://www.netseal.com/ From owner-ipsec@lists.tislabs.com Wed May 10 15:19:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16273; Wed, 10 May 2000 15:19:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15538 Wed, 10 May 2000 17:01:50 -0400 (EDT) Reply-To: From: "Glen Zorn" To: "Ben McCann" , "Dan Harkins" Cc: Subject: RE: Windows 2000 and Cicsco router interoperability Date: Wed, 10 May 2000 13:53:45 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3919983C.4DDC22B1@indusriver.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ben McCann {mailto://bmccann@indusriver.com] writes: > Dan Harkins wrote: > > > > Since when is implementation of Mode Config (or XAUTH) necessary > > to be appropriate for remote access? Actually, Win2K seems to be > > using _standard protocols_ (IPSec-- err, IPsec, L2TP, PPP) to > > solve the problem. Imagine that. > > > > Dan. > > I said "IMHO, an assigned virtual IP address is mandatory for remote > access applications". Given that opinion, Mode Config is currently > the most commonly implemented mechanism _within_ IPSEC that passes an > IP address to a remote access client. (I know IPSRA is working on > _new_ mechanisms but few, if any, of those mechanisms are implemented). > > L2TP over IPSEC also provides this functionality. I personally consider > L2TP+PPP overkill just to pass down an IP address to a remote client > so I have favored IPSEC with Mode Config instead of L2TP/PPP over IPSEC. L2TP does far more than 'just pass down an IP address to a remote client'. > Mode Config is dead in the IETF but many vendors, including your > former employer, Dan's former employer is my current employer. > are shipping Mode Config I consider Mode Config to be rather misbegotten. > to provide remote access > over IPSEC without the overhead of L2TP. What overhead are you talking about? Network overhead or processing? > Hopefully, IPSRA will define > a new mechanism (DHCP?) that also transmits client configuration without > the overhead of a full L2TP and PPP stack. > > -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-ipsec@lists.tislabs.com Wed May 10 15:37:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16555; Wed, 10 May 2000 15:37:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15296 Wed, 10 May 2000 16:12:51 -0400 (EDT) From: "Michael Reilly MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14617.50249.452288.197521@cowboy-mr.cisco.com> Date: Wed, 10 May 2000 13:19:21 -0700 (PDT) To: Michel de Koning Cc: "'Sami Vaarala'" , ipsec@lists.tislabs.com Subject: RE: Win2000 IKE and 3des In-Reply-To: Michel de Koning's message of 10 May 2000 21:23:13 +0200 References: X-Mailer: VM 6.75 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: michaelr@cisco.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Are both of you saying that if you set your policy for 3-DES ONLY (not 3-DES prefered but 3-DES only) that Windows 2000 will negotiate DES anyway? Or are you saying that Windows 2000 will fall back from 3-DES to DES if your configured policy lets it do so and the peer doesn't support 3-DES? The former is a bug which I've not seen in Windows 2000. The latter is expected behavior since you configured it to do so. michael From owner-ipsec@lists.tislabs.com Wed May 10 15:49:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16707; Wed, 10 May 2000 15:49:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15667 Wed, 10 May 2000 17:47:37 -0400 (EDT) Date: Wed, 10 May 2000 14:54:36 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Ben McCann cc: Dan Harkins , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability In-Reply-To: <3919983C.4DDC22B1@indusriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I can't speak for the whole of Cisco, but the way I look at it is: Modeconfig/Xauth are being supported as quick hack to get something to work, and get something to customers, until there is a client that can do IPSec and L2TP. I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I beleive that Cisco's long term goal is to follow whatever is standardized in the IPSRA WG, because that's what IPSRA WG is chartered to solve. chinna On Wed, 10 May 2000, Ben McCann wrote: > Dan Harkins wrote: > > > > Since when is implementation of Mode Config (or XAUTH) necessary > > to be appropriate for remote access? Actually, Win2K seems to be > > using _standard protocols_ (IPSec-- err, IPsec, L2TP, PPP) to > > solve the problem. Imagine that. > > > > Dan. > > I said "IMHO, an assigned virtual IP address is mandatory for remote > access applications". Given that opinion, Mode Config is currently > the most commonly implemented mechanism _within_ IPSEC that passes an > IP address to a remote access client. (I know IPSRA is working on > _new_ mechanisms but few, if any, of those mechanisms are implemented). > > L2TP over IPSEC also provides this functionality. I personally consider > L2TP+PPP overkill just to pass down an IP address to a remote client > so I have favored IPSEC with Mode Config instead of L2TP/PPP over IPSEC. > Mode Config is dead in the IETF but many vendors, including your > former employer, are shipping Mode Config to provide remote access > over IPSEC without the overhead of L2TP. Hopefully, IPSRA will define > a new mechanism (DHCP?) that also transmits client configuration without > the overhead of a full L2TP and PPP stack. > > -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 > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed May 10 16:10:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16970; Wed, 10 May 2000 16:10:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15716 Wed, 10 May 2000 17:59:08 -0400 (EDT) Message-ID: <3919DC36.290D3A48@indusriver.com> Date: Wed, 10 May 2000 18:01:26 -0400 From: Ben McCann MIME-Version: 1.0 To: gwz@cisco.com CC: ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Glenn Zorn wrote: > > L2TP over IPSEC also provides this functionality. I personally consider > > L2TP+PPP overkill just to pass down an IP address to a remote client > > so I have favored IPSEC with Mode Config instead of L2TP/PPP over IPSEC. > > L2TP does far more than 'just pass down an IP address to a remote client'. I agree. It provides many capabilities between a LAC and LNS that are well suited to "compulsory tunneling". However, I think placing a LAC on every remote access client's laptop just to provide a tunneling protocol over IPSEC is overkill. Hence _my_ preference for remote access solely via IPSEC. > > > Mode Config is dead in the IETF but many vendors, including your > > former employer, > > Dan's former employer is my current employer. OK. > > > are shipping Mode Config > > I consider Mode Config to be rather misbegotten. Why? > > > to provide remote access > > over IPSEC without the overhead of L2TP. > > What overhead are you talking about? Network overhead or processing? Code size, complexity, and network overhead. Again, my opinion is that L2TP is fine to aggregate multiple tunnels between LAC and LNS over a variety of media including frame, ATM, and IP. I just think it is heavy- weight solution to tunnel between a single remote station and a server when IPSEC already provides a much simpler tunneling solution (albeit with the omission of a basic configuration management protocol). BTW, our product supports both IPSEC with Mode Config _and_ L2TP because both are required by different sets of customers. -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-ipsec@lists.tislabs.com Wed May 10 20:58:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA15503; Wed, 10 May 2000 20:58:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA16520 Wed, 10 May 2000 22:48:49 -0400 (EDT) Date: Wed, 10 May 2000 22:56:19 -0400 Message-Id: <200005110256.WAA21542@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: CC: jis@mit.edu, Black_David@emc.com cc: scoya@CNRI.Reston.VA.US, ipsec@lists.tislabs.com In-reply-to: Black_David@emc.com's message of Wed, 10 May 2000 19:31:57 -0400, <0F31E5C394DAD311B60C00E029101A070148F899@CORPMX9> Subject: Re: FW: WG Last call: draft-ietf-ipsec-ecn-02.txt Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi David, I'm very sorry for not getting back to you. I've been travelling on business recently and I'm still trying to dig myself out of a huge pile of back e-mail. > So, I think this last call is over with no comments. > Could you forward this draft to the IESG for publication > as an RFC please? Agreed, the last call is over with no comments. I've cc'ed Steve Coya on this think I think he's supposed to put this into some tracking database. (Apologies if there's a magic e-mail address I'm supposed to use instead of just his e-mail address; if there is, I'm sure he'll tell me. :-) Could we please put draft-ietf-ipsec-ecn-02.txt on the IESG's queue for consideration as a proposed standard? Thanks!! - Ted From owner-ipsec@lists.tislabs.com Wed May 10 23:18:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23947; Wed, 10 May 2000 23:18:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA16926 Thu, 11 May 2000 01:04:16 -0400 (EDT) Message-ID: <391A68FA.326666F2@netseal.com> Date: Thu, 11 May 2000 11:02:02 +0300 From: Sami Vaarala Organization: NetSeal Technologies X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: michaelr@cisco.com CC: mdkoning@vanenburg.com, ipsec@lists.tislabs.com Subject: RE: Win2000 IKE and 3des Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, >Are both of you saying that if you set your policy for 3-DES ONLY (not >3-DES prefered but 3-DES only) that Windows 2000 will negotiate DES >anyway? Yes, that seems to be the case. I have only checked that if I configure 3des, it will send des as an initiator, and a phase 1 SA with des will be formed (if the remote end accepts des). Haven't checked if it works this way as a responder; probably will. >Or are you saying that Windows 2000 will fall back from 3-DES to DES if >your configured policy lets it do so and the peer doesn't support >3-DES? No. This would be the correct way to function, and there would not be an issue if this were the case. >The former is a bug which I've not seen in Windows 2000. The latter is >expected behavior since you configured it to do so. My point exactly. The latter behavior would be the one I would prefer to see, of course. -- Sami Vaarala (sami.vaarala@netseal.com) NetSeal Technologies http://www.netseal.com/ From owner-ipsec@lists.tislabs.com Thu May 11 04:20:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA12940; Thu, 11 May 2000 04:20:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA17897 Thu, 11 May 2000 06:02:58 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D28093@new-exc1.ctron.com> From: "Waters, Stephen" To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Thu, 11 May 2000 11:09:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The point in the text was that W2K does not support remote access when using IPSEC Tunnels on their own, which is very true: 1) no address assignment 2) no 'legacy' or 'user' authentication 3) no compression 4) no DUN integration (like that available for L2TP/PPTP) IPSEC Tunnels in W2K is only suitable for desk-top or LAN-LAN protection. It CAN be used for remote access, but your are on your own with configuring it. The IPSEC protection of L2TP happens automatically. Steve. -----Original Message----- From: Dan Harkins [mailto:dharkins@network-alchemy.com] Sent: Wednesday, May 10, 2000 5:22 PM To: Ben McCann Cc: Chris Trobridge; Mike Carney; ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability Since when is implementation of Mode Config (or XAUTH) necessary to be appropriate for remote access? Actually, Win2K seems to be using _standard protocols_ (IPSec-- err, IPsec, L2TP, PPP) to solve the problem. Imagine that. Dan. On Wed, 10 May 2000 09:10:35 EDT you wrote > Win2K does implement L2TP over IPSEC in transport mode. It uses PPP > to transfer configuration information, such as a virtual IP address > to the remote client. IMHO, an assigned virtual IP address is mandatory > for remote access applications and Win2K does not, to my knowledge, > implement Mode Config (or XAUTH). So, Win2K is not really appropriate > for remote access application using native IPSEC tunnels. It relies > upon L2TP for the same functionality. > > -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-ipsec@lists.tislabs.com Thu May 11 05:59:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA15330; Thu, 11 May 2000 05:59:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA18271 Thu, 11 May 2000 07:49:35 -0400 (EDT) From: Franck.Le@nokia.com Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B0124D303@daeis07nok> To: ipsec@lists.tislabs.com Subject: IKE Date: Wed, 10 May 2000 14:00:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have some questions on IKE. Actually I was wondering if in the Main Mode, protection against man in the middle attacks is provided. Since the first messages are sent in clear mode and without any authentication, can't a Bad Guy modify for example the SA payload ? That can bring to a denial of service. So if it the case, is there a way to protect against man in the middle attacks ? Thanking you in advance for your help. Franck LE From owner-ipsec@lists.tislabs.com Thu May 11 06:57:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16352; Thu, 11 May 2000 06:57:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18631 Thu, 11 May 2000 08:43:24 -0400 (EDT) Message-ID: From: Michel de Koning To: "'Waters, Stephen'" , Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Thu, 11 May 2000 14:48:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk True, I use a PPTP connection after setting up IPsec tunnel between W2k client/NT4 client with cisco client and w2k VPN server. This allows NT4 machines that are not L2TP compatible to connect as well. When everyone in our organization has migrated to W2k only L2TP should be sufficient. IPsec using mode-config for W2k will probably be available in some service pack to come? not? thanks Michel -----Original Message----- From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com] Sent: Thursday, May 11, 2000 12:10 PM To: Dan Harkins Cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability The point in the text was that W2K does not support remote access when using IPSEC Tunnels on their own, which is very true: 1) no address assignment 2) no 'legacy' or 'user' authentication 3) no compression 4) no DUN integration (like that available for L2TP/PPTP) IPSEC Tunnels in W2K is only suitable for desk-top or LAN-LAN protection. It CAN be used for remote access, but your are on your own with configuring it. The IPSEC protection of L2TP happens automatically. Steve. -----Original Message----- From: Dan Harkins [mailto:dharkins@network-alchemy.com] Sent: Wednesday, May 10, 2000 5:22 PM To: Ben McCann Cc: Chris Trobridge; Mike Carney; ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability Since when is implementation of Mode Config (or XAUTH) necessary to be appropriate for remote access? Actually, Win2K seems to be using _standard protocols_ (IPSec-- err, IPsec, L2TP, PPP) to solve the problem. Imagine that. Dan. On Wed, 10 May 2000 09:10:35 EDT you wrote > Win2K does implement L2TP over IPSEC in transport mode. It uses PPP > to transfer configuration information, such as a virtual IP address > to the remote client. IMHO, an assigned virtual IP address is mandatory > for remote access applications and Win2K does not, to my knowledge, > implement Mode Config (or XAUTH). So, Win2K is not really appropriate > for remote access application using native IPSEC tunnels. It relies > upon L2TP for the same functionality. > > -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-ipsec@lists.tislabs.com Thu May 11 07:01:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA16412; Thu, 11 May 2000 07:01:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18767 Thu, 11 May 2000 08:56:39 -0400 (EDT) Message-ID: From: "Gallagher, Mick" To: ipsec@lists.tislabs.com Subject: IRAC connectivity via NAT: L2TP the best solution? Date: Thu, 11 May 2000 14:03:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All, A quick question for the IP(S)sec savvy... For a remote client allocated a private stub domain IP address, is L2TP the only _practical_ means (at this time) to run IPsec between the client and SG via NAT? Thanks in advance, Mick Gallagher From owner-ipsec@lists.tislabs.com Thu May 11 08:18:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17905; Thu, 11 May 2000 08:18:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19023 Thu, 11 May 2000 09:57:35 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14618.48661.240385.297046@xedia.com> Date: Thu, 11 May 2000 10:05:09 -0400 (EDT) To: Stephen.Waters@cabletron.com Cc: dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability References: <29752A74B6C5D211A4920090273CA3DC01D28093@new-exc1.ctron.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Waters," == Waters, Stephen writes: Waters,> The point in the text was that W2K does not support remote Waters,> access when using IPSEC Tunnels on their own, which is very Waters,> true: Waters,> 1) no address assignment Except for mode config, of course. Waters,> 2) no 'legacy' or 'user' authentication Huh? What about FQDN and similar identities? Waters,> 3) no compression Sure there is. IPCOMP does just fine. Better in fact, because it is stateless. Waters,> 4) no DUN integration (like that available for L2TP/PPTP) What's a DUN? paul From owner-ipsec@lists.tislabs.com Thu May 11 08:21:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17939; Thu, 11 May 2000 08:21:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19042 Thu, 11 May 2000 10:01:03 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14618.48869.608160.148975@xedia.com> Date: Thu, 11 May 2000 10:08:37 -0400 (EDT) To: Franck.Le@nokia.com Cc: ipsec@lists.tislabs.com Subject: Re: IKE References: <7B5C0390ACE7D211BC9C0008C7EABA2B0124D303@daeis07nok> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Franck" == Franck Le writes: Franck> Hi, I have some questions on IKE. Actually I was wondering Franck> if in the Main Mode, protection against man in the middle Franck> attacks is provided. Since the first messages are sent in Franck> clear mode and without any authentication, can't a Bad Guy Franck> modify for example the SA payload ? That can bring to a Franck> denial of service. So if it the case, is there a way to Franck> protect against man in the middle attacks ? The "man in the middle" that IKE protects against is a man in the middle who wants to listen to your traffic, or modify it without being detected. It is impossible to define any protocol that prevents an active attacker from deleting your traffic (or modifying it and forcing you to discard it because the HMAC fails). The only solution in that case is to route around the attacker, if you can. See Radia Perlman's PhD thesis for more. paul From owner-ipsec@lists.tislabs.com Thu May 11 08:22:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17987; Thu, 11 May 2000 08:22:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19092 Thu, 11 May 2000 10:12:03 -0400 (EDT) Message-Id: <4.2.0.58.20000511101527.00a39960@pop3.indusriver.com> Date: Thu, 11 May 2000 10:27:58 -0400 To: Franck.Le@nokia.com From: David Chen Subject: Re: IKE Cc: ipsec@lists.tislabs.com In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B0124D303@daeis07nok> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1594002==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_1594002==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:00 PM 5/10/00 -0500, you wrote: >Hi, > >I have some questions on IKE. >Actually I was wondering if in the Main Mode, protection against man in the >middle attacks is provided. The countermeasure of MIM attack is authenticate the peer. (and off course mutually) The third pair of message will take care of this. >Since the first messages are sent in clear mode and without any >authentication, can't a Bad Guy modify for example the SA payload ? That can >bring to a denial of service. The countermeasure of DOS is demanding the equal or larger amount of resources that attacker has to consume than the attacked. The DH key exchange in IKE requires the peers equally (if the implementation is correct) consumes resources. >So if it the case, is there a way to protect against man in the middle >attacks ? It is the issues of "talk first" or "authentication first". The main mode's first and second pair of messages is "talk first" - to establish secured comm. channel between two peers. The the pair messages is for authentication. We may ask why it is done this way???? :-) >Thanking you in advance for your help. > >Franck LE --- David --=====================_1594002==_.ALT Content-Type: text/html; charset="us-ascii" At 02:00 PM 5/10/00 -0500, you wrote:
Hi,

I have some questions on IKE.
Actually I was wondering if in the Main Mode, protection against man in the
middle attacks is provided.

The countermeasure of MIM attack is authenticate the peer. (and off course mutually)
The third pair of message will take care of this.


Since the first messages are sent in clear mode and without any
authentication, can't a Bad Guy modify for example the SA payload ? That can
bring to a denial of service.

The countermeasure of DOS is demanding the equal or larger amount of resources
that attacker has to consume than the attacked.
The DH key exchange in IKE requires the peers equally (if the implementation is correct)
consumes resources.

So if it the case, is there a way to protect against man in the middle
attacks ?

It is the issues of "talk first" or "authentication first".
The main mode's first and second pair of messages is "talk first" - to establish
secured comm. channel between two peers.
The the pair messages is for authentication.

We may ask why it is done this way???? :-)

Thanking you in advance for your help.

Franck LE

--- David
--=====================_1594002==_.ALT-- From owner-ipsec@lists.tislabs.com Thu May 11 08:43:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18335; Thu, 11 May 2000 08:43:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19177 Thu, 11 May 2000 10:31:31 -0400 (EDT) Date: Thu, 11 May 2000 10:38:28 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: IKE In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B0124D303@daeis07nok> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 10 May 2000 Franck.Le@nokia.com wrote: > Since the first messages are sent in clear mode and without any > authentication, can't a Bad Guy modify for example the SA payload ? That can > bring to a denial of service. There is ultimately no way to protect against denial-of-service attacks by a man in the middle -- he can just change all your packets to random garbage, thus preventing communications completely. The most you can do is to prevent him from impersonating a legitimate party to the communications, which is why IKE has assorted authentication methods (preshared key, public-key signatures, etc etc.). Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu May 11 10:09:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19837; Thu, 11 May 2000 10:09:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19343 Thu, 11 May 2000 11:27:53 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D280A4@new-exc1.ctron.com> From: "Waters, Stephen" To: Paul Koning Cc: dharkins@network-alchemy.com, ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Thu, 11 May 2000 16:34:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul, my comments were specific to the Remote Access VPN support that ships in W2K Professional; and I believe all my comments are true. W2K has no support for IKE-CFG, IKE-AUTH, IPCOMP, and requires PKI/Cert when protecting L2TP (which is mandatory to create any 'useful' W2K VPN tunnel). DUN = Dail-up-networking. Steve. -----Original Message----- From: Paul Koning [mailto:pkoning@xedia.com] Sent: Thursday, May 11, 2000 3:05 PM To: Stephen.Waters@cabletron.com Cc: dharkins@network-alchemy.com; ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability >>>>> "Waters," == Waters, Stephen writes: Waters,> The point in the text was that W2K does not support remote Waters,> access when using IPSEC Tunnels on their own, which is very Waters,> true: Waters,> 1) no address assignment Except for mode config, of course. Waters,> 2) no 'legacy' or 'user' authentication Huh? What about FQDN and similar identities? Waters,> 3) no compression Sure there is. IPCOMP does just fine. Better in fact, because it is stateless. Waters,> 4) no DUN integration (like that available for L2TP/PPTP) What's a DUN? paul From owner-ipsec@lists.tislabs.com Thu May 11 12:57:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22750; Thu, 11 May 2000 12:57:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19955 Thu, 11 May 2000 14:33:03 -0400 (EDT) Message-ID: <20000511152755.7317.qmail@web4405.mail.yahoo.com> Date: Thu, 11 May 2000 17:27:55 +0200 (CEST) From: =?iso-8859-1?q?beldi=20olivier?= Subject: about compliance To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk a lot of products are suppose to implement IPSec functionnality,but when you want too buy one,what are the question you must ask yourself. please help me to find some. ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr From owner-ipsec@lists.tislabs.com Thu May 11 14:35:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24041; Thu, 11 May 2000 14:35:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20374 Thu, 11 May 2000 16:21:04 -0400 (EDT) Message-ID: <95A2AF8E4643D211941A00805FE6BE4802865C9C@exchny18.sbi.com> From: "Mintz, Erik [IT]" To: ipsec@lists.tislabs.com, "'beldi olivier'" Subject: RE: about compliance Date: Thu, 11 May 2000 16:22:32 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Do I feel lucky? We'll do you, punk?" Erik Mintz Mobile computing group Salomon Smith Barney 212-816-3138 > ---------- > From: beldi olivier[SMTP:beldi_o@yahoo.fr] > Sent: Thursday, May 11, 2000 11:27 AM > To: ipsec@lists.tislabs.com > Subject: about compliance > > a lot of products are suppose to implement IPSec > functionnality,but when you want too buy one,what are > the question you must ask yourself. > please help me to find some. > > ___________________________________________________________ > Do You Yahoo!? > Achetez, vendez! A votre prix! Sur http://encheres.yahoo.fr > From owner-ipsec@lists.tislabs.com Thu May 11 15:17:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24553; Thu, 11 May 2000 15:17:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20545 Thu, 11 May 2000 17:08:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 11 May 2000 17:14:44 -0400 To: "CHINNA N.R. PELLACURU" From: Stephen Kent Subject: Re: Windows 2000 and Cicsco router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: >I can't speak for the whole of Cisco, but the way I look at it is: > >Modeconfig/Xauth are being supported as quick hack to get something to >work, and get something to customers, until there is a client that can do >IPSec and L2TP. > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I >beleive that Cisco's long term goal is to follow whatever is standardized >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > That's one view. Another perspective is that L2TP over IPsec represents an effort by Microsoft & Cisco to preserve a joint development investment in L2TP, irrespective of its technical merit in this context :-). If I am sending non-IP packets, L2TP is appropriate, but if I am sending IP, then the extra headers introduced by L2TP are not only wasteful of bandwidth on a continuing basis, but they also interfere with the access controls that are an essential part of IPsec. One needs some means of dealing with bind time connection parameters, but use of L2TP on a continuing basis is an expensive means of achieving this goal. Steve From owner-ipsec@lists.tislabs.com Thu May 11 16:49:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25325; Thu, 11 May 2000 16:49:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20773 Thu, 11 May 2000 18:42:32 -0400 (EDT) From: "Rob Beneson" To: "beldi olivier" , Subject: RE: about compliance Date: Thu, 11 May 2000 15:53:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20000511152755.7317.qmail@web4405.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you could give more details as to what you want specifically, maybe we can help more. Win2k does most of what people want when its client to server related, but what exactly do you want to implement IPsec on? and for what? Rob -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of beldi olivier Sent: Thursday, May 11, 2000 8:28 AM To: ipsec@lists.tislabs.com Subject: about compliance a lot of products are suppose to implement IPSec functionnality,but when you want too buy one,what are the question you must ask yourself. please help me to find some. ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr From owner-ipsec@lists.tislabs.com Thu May 11 16:52:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25357; Thu, 11 May 2000 16:52:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20792 Thu, 11 May 2000 18:51:24 -0400 (EDT) Date: Thu, 11 May 2000 15:58:29 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk And one more benefit of using L2TP/IPSec is, it can support securing IP multicast traffic, atleast over the vpn link. But if you are using native IPSec with Mode-config/Xauth, you can't secure multicast traffic, and you will need to have atleast GRE to do this. I wonder how much benefit we can get out of "L2TP Header Compression". Regarding access control, some customers raised concerns that, if a client has a VPN link connected to the corporate intranet, and is also directly connected to the Internet, then they can't enforce the corporate firewall policy on that client, like they can if the client was actually in the intranet. There were also concerns raised that if the client is directly connected to the Internet, it could be hacked, and won't be able to have the same protection that the corporate firewall provides. There are atleast two ways of dealing with this: 1. put an equalent of the corporate firewall on the client so that it can defend itself, and also enforce the corporate firewall policy. 2. have a very simple policy on the client that says all traffic will go via the VPN link to the corporate network, and the client will accept/send nothing else. This would be the true emulation of the Dial-in remote access, and this can be acheived naturally using L2TP. chinna On Thu, 11 May 2000, Stephen Kent wrote: > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > >I can't speak for the whole of Cisco, but the way I look at it is: > > > >Modeconfig/Xauth are being supported as quick hack to get something to > >work, and get something to customers, until there is a client that can do > >IPSec and L2TP. > > > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I > >beleive that Cisco's long term goal is to follow whatever is standardized > >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > > > > That's one view. > > Another perspective is that L2TP over IPsec represents an effort by > Microsoft & Cisco to preserve a joint development investment in L2TP, > irrespective of its technical merit in this context :-). If I am > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > then the extra headers introduced by L2TP are not only wasteful of > bandwidth on a continuing basis, but they also interfere with the > access controls that are an essential part of IPsec. One needs some > means of dealing with bind time connection parameters, but use of > L2TP on a continuing basis is an expensive means of achieving this > goal. > > Steve > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu May 11 17:20:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA25668; Thu, 11 May 2000 17:20:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22208 Thu, 11 May 2000 19:17:37 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D280B5@new-exc1.ctron.com> From: "Waters, Stephen" To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Fri, 12 May 2000 00:24:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPSEC/IKE is said to be too complex. What chance have we got if we need to run L2TP as well! There is nothing really bad about Modeconfig. Xauth has its problems, but there have been drafts to suggest alternatives - e.g. CRACK by Dan H. Steve. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, May 11, 2000 10:15 PM To: CHINNA N.R. PELLACURU Cc: ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: >I can't speak for the whole of Cisco, but the way I look at it is: > >Modeconfig/Xauth are being supported as quick hack to get something to >work, and get something to customers, until there is a client that can do >IPSec and L2TP. > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I >beleive that Cisco's long term goal is to follow whatever is standardized >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > That's one view. Another perspective is that L2TP over IPsec represents an effort by Microsoft & Cisco to preserve a joint development investment in L2TP, irrespective of its technical merit in this context :-). If I am sending non-IP packets, L2TP is appropriate, but if I am sending IP, then the extra headers introduced by L2TP are not only wasteful of bandwidth on a continuing basis, but they also interfere with the access controls that are an essential part of IPsec. One needs some means of dealing with bind time connection parameters, but use of L2TP on a continuing basis is an expensive means of achieving this goal. Steve From owner-ipsec@lists.tislabs.com Thu May 11 18:11:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA00210; Thu, 11 May 2000 18:11:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA22350 Thu, 11 May 2000 20:04:33 -0400 (EDT) Message-ID: <391B4C40.C64DBD37@cyphers.net> Date: Thu, 11 May 2000 17:11:44 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Sami Vaarala CC: ipsec@lists.tislabs.com Subject: Re: Win2000 IKE and 3des References: <391A68FA.326666F2@netseal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This sounds fairly serious to me. Perhaps this should be posted to BugTraq. This needs confirmation. I thought I saw something like this when I was doing my tests against Win2K, but it's been quite some time since then. Sami Vaarala wrote: > >Are both of you saying that if you set your policy for 3-DES ONLY (not >3-DES prefered but 3-DES only) that Windows 2000 will negotiate DES >anyway? > > Yes, that seems to be the case. I have only checked that if I configure > 3des, it will send des as an initiator, and a phase 1 SA with des will > be formed (if the remote end accepts des). Haven't checked if it works > this way as a responder; probably will. > > >Or are you saying that Windows 2000 will fall back from 3-DES to DES if >your configured policy lets it do so and the peer doesn't support >3-DES? > > No. This would be the correct way to function, and there would not be > an issue if this were the case. > > >The former is a bug which I've not seen in Windows 2000. The latter is > >expected behavior since you configured it to do so. > > My point exactly. The latter behavior would be the one I would prefer > to see, of course. -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Thu May 11 18:13:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA00592; Thu, 11 May 2000 18:13:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA22400 Thu, 11 May 2000 20:07:23 -0400 (EDT) Date: Thu, 11 May 2000 17:14:29 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I guess, security doesn't come cheap, and every customer understands that. If we want to massively hack the protocol, in the name of efficiency, (to provide all the features that PPP already provides), then I guess there will always be people who will come along and blame us saying "overly complex systems are inherently insecure". And, I don't think any company, cisco, micr*s*ft or any other company would push a technology, because the company developed it. To me, that just seems so wrong. :-) But then, I am just a software engineer working in the trenches, and I see the world differently. :-) chinna On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > And one more benefit of using L2TP/IPSec is, it can support securing IP > multicast traffic, atleast over the vpn link. But if you are using native > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and you > will need to have atleast GRE to do this. > > I wonder how much benefit we can get out of "L2TP Header Compression". > > Regarding access control, some customers raised concerns that, if a client > has a VPN link connected to the corporate intranet, and is also directly > connected to the Internet, then they can't enforce the corporate firewall > policy on that client, like they can if the client was actually in the > intranet. There were also concerns raised that if the client is > directly connected to the Internet, it could be hacked, and won't be able > to have the same protection that the corporate firewall provides. > > There are atleast two ways of dealing with this: > > 1. put an equalent of the corporate firewall on the client so that it can > defend itself, and also enforce the corporate firewall policy. > > 2. have a very simple policy on the client that says all traffic will go > via the VPN link to the corporate network, and the client will accept/send > nothing else. This would be the true emulation of the Dial-in remote > access, and this can be acheived naturally using L2TP. > > chinna > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > >Modeconfig/Xauth are being supported as quick hack to get something to > > >work, and get something to customers, until there is a client that can do > > >IPSec and L2TP. > > > > > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I > > >beleive that Cisco's long term goal is to follow whatever is standardized > > >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > > > > > > > That's one view. > > > > Another perspective is that L2TP over IPsec represents an effort by > > Microsoft & Cisco to preserve a joint development investment in L2TP, > > irrespective of its technical merit in this context :-). If I am > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > then the extra headers introduced by L2TP are not only wasteful of > > bandwidth on a continuing basis, but they also interfere with the > > access controls that are an essential part of IPsec. One needs some > > means of dealing with bind time connection parameters, but use of > > L2TP on a continuing basis is an expensive means of achieving this > > goal. > > > > Steve > > > > > > chinna narasimha reddy pellacuru > s/w engineer > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu May 11 18:14:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA00734; Thu, 11 May 2000 18:14:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA22325 Thu, 11 May 2000 20:01:02 -0400 (EDT) Message-ID: <391B4B7D.8A9C460F@cyphers.net> Date: Thu, 11 May 2000 17:08:29 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "CHINNA N.R. PELLACURU" CC: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, but the issue to get back to Stephen's point is that there is a lot of overhead involved in doing that when the same thing can be accomplished much more simply (and I hope we all learned that simplicity is job #1 here after reading Bruce's paper) by just using IPsec correctly mixed the appropriate client side personal firewall and routing as you point out. The latest version of our VPN client PGP 7.0 announced this week implements both of those solutions (centrally managed client side firewalling and the ability to direct all traffic to the secure gateway) along with mode-config to accomplish these goals without any of the overhead involved in trying to merge a complex protocol (L2TP) with another complex protocol (IKE/IPsec). I can only imagine (and cringe at) the logistics involved in doing a security code review of both of those together. "CHINNA N.R. PELLACURU" wrote: > > And one more benefit of using L2TP/IPSec is, it can support securing IP > multicast traffic, atleast over the vpn link. But if you are using native > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and you > will need to have atleast GRE to do this. > > I wonder how much benefit we can get out of "L2TP Header Compression". > > Regarding access control, some customers raised concerns that, if a client > has a VPN link connected to the corporate intranet, and is also directly > connected to the Internet, then they can't enforce the corporate firewall > policy on that client, like they can if the client was actually in the > intranet. There were also concerns raised that if the client is > directly connected to the Internet, it could be hacked, and won't be able > to have the same protection that the corporate firewall provides. > > There are atleast two ways of dealing with this: > > 1. put an equalent of the corporate firewall on the client so that it can > defend itself, and also enforce the corporate firewall policy. > > 2. have a very simple policy on the client that says all traffic will go > via the VPN link to the corporate network, and the client will accept/send > nothing else. This would be the true emulation of the Dial-in remote > access, and this can be acheived naturally using L2TP. > > chinna > > On Thu, 11 May 2000, Stephen Kent wrote: > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > >Modeconfig/Xauth are being supported as quick hack to get something to > > >work, and get something to customers, until there is a client that can do > > >IPSec and L2TP. > > > > > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I > > >beleive that Cisco's long term goal is to follow whatever is standardized > > >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > > > > > > > That's one view. > > > > Another perspective is that L2TP over IPsec represents an effort by > > Microsoft & Cisco to preserve a joint development investment in L2TP, > > irrespective of its technical merit in this context :-). If I am > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > then the extra headers introduced by L2TP are not only wasteful of > > bandwidth on a continuing basis, but they also interfere with the > > access controls that are an essential part of IPsec. One needs some > > means of dealing with bind time connection parameters, but use of > > L2TP on a continuing basis is an expensive means of achieving this > > goal. -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Thu May 11 19:05:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08434; Thu, 11 May 2000 19:05:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA22508 Thu, 11 May 2000 21:02:34 -0400 (EDT) Date: Thu, 11 May 2000 18:06:20 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Will Price cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability In-Reply-To: <391B4B7D.8A9C460F@cyphers.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Atleast we agree on one thing: we should strive for simplicity. We are essentially talking about adding all the AAA and IPCP baggage to IKE. And that you say is simple! On top of that you want each IPSec client to have a "personal firewall" too. I can see why people want to suggest that. IMHO, it is much much simpler and modular to let L2TP/PPP deal with the AAA and IPCP, and let IPSec protect L2TP. L2TP is fully encapsulated in IPSec, and I don't see how that is less secure. I don't see how it is simple to introduce the AAA and IPCP baggage into IKE. How many forms of Authenticataion do you already support. Do you support Authorization and Accounting? How many features of IPCP do you already support? Probably it is simple for you because your customer base needs only a small subset of these features. But, once we open the flood gates, then customers would like to have all the features that they have come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on an ongoing basis to add in features. chinna On Thu, 11 May 2000, Will Price wrote: > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > but the issue to get back to Stephen's point is that there is a lot of > overhead involved in doing that when the same thing can be accomplished > much more simply (and I hope we all learned that simplicity is job #1 here > after reading Bruce's paper) by just using IPsec correctly mixed the > appropriate client side personal firewall and routing as you point out. > > The latest version of our VPN client PGP 7.0 announced this week > implements both of those solutions (centrally managed client side > firewalling and the ability to direct all traffic to the secure gateway) > along with mode-config to accomplish these goals without any of the > overhead involved in trying to merge a complex protocol (L2TP) with > another complex protocol (IKE/IPsec). I can only imagine (and cringe at) > the logistics involved in doing a security code review of both of those > together. > > > "CHINNA N.R. PELLACURU" wrote: > > > > And one more benefit of using L2TP/IPSec is, it can support securing IP > > multicast traffic, atleast over the vpn link. But if you are using native > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and you > > will need to have atleast GRE to do this. > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > Regarding access control, some customers raised concerns that, if a client > > has a VPN link connected to the corporate intranet, and is also directly > > connected to the Internet, then they can't enforce the corporate firewall > > policy on that client, like they can if the client was actually in the > > intranet. There were also concerns raised that if the client is > > directly connected to the Internet, it could be hacked, and won't be able > > to have the same protection that the corporate firewall provides. > > > > There are atleast two ways of dealing with this: > > > > 1. put an equalent of the corporate firewall on the client so that it can > > defend itself, and also enforce the corporate firewall policy. > > > > 2. have a very simple policy on the client that says all traffic will go > > via the VPN link to the corporate network, and the client will accept/send > > nothing else. This would be the true emulation of the Dial-in remote > > access, and this can be acheived naturally using L2TP. > > > > chinna > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something to > > > >work, and get something to customers, until there is a client that can do > > > >IPSec and L2TP. > > > > > > > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I > > > >beleive that Cisco's long term goal is to follow whatever is standardized > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > > > > > > > > > > That's one view. > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > Microsoft & Cisco to preserve a joint development investment in L2TP, > > > irrespective of its technical merit in this context :-). If I am > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > then the extra headers introduced by L2TP are not only wasteful of > > > bandwidth on a continuing basis, but they also interfere with the > > > access controls that are an essential part of IPsec. One needs some > > > means of dealing with bind time connection parameters, but use of > > > L2TP on a continuing basis is an expensive means of achieving this > > > goal. > > > -- > Will Price, Director of Engineering > PGP Security, Inc. > a division of Network Associates, Inc. > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu May 11 20:16:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17040; Thu, 11 May 2000 20:16:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA22611 Thu, 11 May 2000 22:03:28 -0400 (EDT) Date: Thu, 11 May 2000 19:10:25 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Will Price cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I guess the bottom line is: Do you want to understand all the subtilities of AAA and IPCP, and then massively hack IKE on an ongoing basis, to incorporate all that, (with stuff like open ended exchanges, and on top of that require that every client need a "personal firewall") or Do you want to leverage all the features of AAA and IPCP in a simple modular way, and not bother too much about them, and trust them in that they do their job well. Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead? chinna On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > Atleast we agree on one thing: we should strive for simplicity. > > We are essentially talking about adding all the AAA and IPCP baggage to > IKE. And that you say is simple! > > On top of that you want each IPSec client to have a "personal firewall" > too. I can see why people want to suggest that. > > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the > AAA and IPCP, and let IPSec protect L2TP. > > L2TP is fully encapsulated in IPSec, and I don't see how that is less > secure. > > I don't see how it is simple to introduce the AAA and IPCP baggage into > IKE. How many forms of Authenticataion do you already support. Do you > support Authorization and Accounting? How many features of IPCP do you > already support? Probably it is simple for you because your customer base > needs only a small subset of these features. But, once we open the flood > gates, then customers would like to have all the features that they have > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on > an ongoing basis to add in features. > > chinna > > On Thu, 11 May 2000, Will Price wrote: > > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > > but the issue to get back to Stephen's point is that there is a lot of > > overhead involved in doing that when the same thing can be accomplished > > much more simply (and I hope we all learned that simplicity is job #1 here > > after reading Bruce's paper) by just using IPsec correctly mixed the > > appropriate client side personal firewall and routing as you point out. > > > > The latest version of our VPN client PGP 7.0 announced this week > > implements both of those solutions (centrally managed client side > > firewalling and the ability to direct all traffic to the secure gateway) > > along with mode-config to accomplish these goals without any of the > > overhead involved in trying to merge a complex protocol (L2TP) with > > another complex protocol (IKE/IPsec). I can only imagine (and cringe at) > > the logistics involved in doing a security code review of both of those > > together. > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > And one more benefit of using L2TP/IPSec is, it can support securing IP > > > multicast traffic, atleast over the vpn link. But if you are using native > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and you > > > will need to have atleast GRE to do this. > > > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > > > Regarding access control, some customers raised concerns that, if a client > > > has a VPN link connected to the corporate intranet, and is also directly > > > connected to the Internet, then they can't enforce the corporate firewall > > > policy on that client, like they can if the client was actually in the > > > intranet. There were also concerns raised that if the client is > > > directly connected to the Internet, it could be hacked, and won't be able > > > to have the same protection that the corporate firewall provides. > > > > > > There are atleast two ways of dealing with this: > > > > > > 1. put an equalent of the corporate firewall on the client so that it can > > > defend itself, and also enforce the corporate firewall policy. > > > > > > 2. have a very simple policy on the client that says all traffic will go > > > via the VPN link to the corporate network, and the client will accept/send > > > nothing else. This would be the true emulation of the Dial-in remote > > > access, and this can be acheived naturally using L2TP. > > > > > > chinna > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something to > > > > >work, and get something to customers, until there is a client that can do > > > > >IPSec and L2TP. > > > > > > > > > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I > > > > >beleive that Cisco's long term goal is to follow whatever is standardized > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > > > > > > > > > > > > > That's one view. > > > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > > Microsoft & Cisco to preserve a joint development investment in L2TP, > > > > irrespective of its technical merit in this context :-). If I am > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > > then the extra headers introduced by L2TP are not only wasteful of > > > > bandwidth on a continuing basis, but they also interfere with the > > > > access controls that are an essential part of IPsec. One needs some > > > > means of dealing with bind time connection parameters, but use of > > > > L2TP on a continuing basis is an expensive means of achieving this > > > > goal. > > > > > > -- > > Will Price, Director of Engineering > > PGP Security, Inc. > > a division of Network Associates, Inc. > > > > chinna narasimha reddy pellacuru > s/w engineer > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu May 11 20:26:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA18707; Thu, 11 May 2000 20:26:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA22642 Thu, 11 May 2000 22:23:33 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 11 May 2000 19:29:53 -0700 (PDT) From: Jan Vilhuber To: "CHINNA N.R. PELLACURU" cc: Will Price , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This discussion belongs on the IPSRA mailing list, if I'm not mistaken. jan On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > I guess the bottom line is: > > Do you want to understand all the subtilities of AAA and IPCP, and then > massively hack IKE on an ongoing basis, to incorporate all that, (with > stuff like open ended exchanges, and on top of that require that every > client need a "personal firewall") > > or > > Do you want to leverage all the features of AAA and IPCP in a simple > modular way, and not bother too much about them, and trust them in that > they do their job well. > > Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead? > > chinna > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > Atleast we agree on one thing: we should strive for simplicity. > > > > We are essentially talking about adding all the AAA and IPCP baggage to > > IKE. And that you say is simple! > > > > On top of that you want each IPSec client to have a "personal firewall" > > too. I can see why people want to suggest that. > > > > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the > > AAA and IPCP, and let IPSec protect L2TP. > > > > L2TP is fully encapsulated in IPSec, and I don't see how that is less > > secure. > > > > I don't see how it is simple to introduce the AAA and IPCP baggage into > > IKE. How many forms of Authenticataion do you already support. Do you > > support Authorization and Accounting? How many features of IPCP do you > > already support? Probably it is simple for you because your customer base > > needs only a small subset of these features. But, once we open the flood > > gates, then customers would like to have all the features that they have > > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on > > an ongoing basis to add in features. > > > > chinna > > > > On Thu, 11 May 2000, Will Price wrote: > > > > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > > > but the issue to get back to Stephen's point is that there is a lot of > > > overhead involved in doing that when the same thing can be accomplished > > > much more simply (and I hope we all learned that simplicity is job #1 here > > > after reading Bruce's paper) by just using IPsec correctly mixed the > > > appropriate client side personal firewall and routing as you point out. > > > > > > The latest version of our VPN client PGP 7.0 announced this week > > > implements both of those solutions (centrally managed client side > > > firewalling and the ability to direct all traffic to the secure gateway) > > > along with mode-config to accomplish these goals without any of the > > > overhead involved in trying to merge a complex protocol (L2TP) with > > > another complex protocol (IKE/IPsec). I can only imagine (and cringe at) > > > the logistics involved in doing a security code review of both of those > > > together. > > > > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > > > And one more benefit of using L2TP/IPSec is, it can support securing IP > > > > multicast traffic, atleast over the vpn link. But if you are using native > > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and you > > > > will need to have atleast GRE to do this. > > > > > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > > > > > Regarding access control, some customers raised concerns that, if a client > > > > has a VPN link connected to the corporate intranet, and is also directly > > > > connected to the Internet, then they can't enforce the corporate firewall > > > > policy on that client, like they can if the client was actually in the > > > > intranet. There were also concerns raised that if the client is > > > > directly connected to the Internet, it could be hacked, and won't be able > > > > to have the same protection that the corporate firewall provides. > > > > > > > > There are atleast two ways of dealing with this: > > > > > > > > 1. put an equalent of the corporate firewall on the client so that it can > > > > defend itself, and also enforce the corporate firewall policy. > > > > > > > > 2. have a very simple policy on the client that says all traffic will go > > > > via the VPN link to the corporate network, and the client will accept/send > > > > nothing else. This would be the true emulation of the Dial-in remote > > > > access, and this can be acheived naturally using L2TP. > > > > > > > > chinna > > > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something to > > > > > >work, and get something to customers, until there is a client that can do > > > > > >IPSec and L2TP. > > > > > > > > > > > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I > > > > > >beleive that Cisco's long term goal is to follow whatever is standardized > > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > > > > > > > > > > > > > > > > That's one view. > > > > > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > > > Microsoft & Cisco to preserve a joint development investment in L2TP, > > > > > irrespective of its technical merit in this context :-). If I am > > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > > > then the extra headers introduced by L2TP are not only wasteful of > > > > > bandwidth on a continuing basis, but they also interfere with the > > > > > access controls that are an essential part of IPsec. One needs some > > > > > means of dealing with bind time connection parameters, but use of > > > > > L2TP on a continuing basis is an expensive means of achieving this > > > > > goal. > > > > > > > > > -- > > > Will Price, Director of Engineering > > > PGP Security, Inc. > > > a division of Network Associates, Inc. > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > > > chinna narasimha reddy pellacuru > s/w engineer > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu May 11 20:31:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19519; Thu, 11 May 2000 20:31:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA22662 Thu, 11 May 2000 22:27:28 -0400 (EDT) Date: Thu, 11 May 2000 19:34:04 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Jan Vilhuber cc: Will Price , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is this discussion already taking place there? chinna On Thu, 11 May 2000, Jan Vilhuber wrote: > This discussion belongs on the IPSRA mailing list, if I'm not mistaken. > > jan > > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > I guess the bottom line is: > > > > Do you want to understand all the subtilities of AAA and IPCP, and then > > massively hack IKE on an ongoing basis, to incorporate all that, (with > > stuff like open ended exchanges, and on top of that require that every > > client need a "personal firewall") > > > > or > > > > Do you want to leverage all the features of AAA and IPCP in a simple > > modular way, and not bother too much about them, and trust them in that > > they do their job well. > > > > Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead? > > > > chinna > > > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > > > Atleast we agree on one thing: we should strive for simplicity. > > > > > > We are essentially talking about adding all the AAA and IPCP baggage to > > > IKE. And that you say is simple! > > > > > > On top of that you want each IPSec client to have a "personal firewall" > > > too. I can see why people want to suggest that. > > > > > > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the > > > AAA and IPCP, and let IPSec protect L2TP. > > > > > > L2TP is fully encapsulated in IPSec, and I don't see how that is less > > > secure. > > > > > > I don't see how it is simple to introduce the AAA and IPCP baggage into > > > IKE. How many forms of Authenticataion do you already support. Do you > > > support Authorization and Accounting? How many features of IPCP do you > > > already support? Probably it is simple for you because your customer base > > > needs only a small subset of these features. But, once we open the flood > > > gates, then customers would like to have all the features that they have > > > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on > > > an ongoing basis to add in features. > > > > > > chinna > > > > > > On Thu, 11 May 2000, Will Price wrote: > > > > > > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > > > > but the issue to get back to Stephen's point is that there is a lot of > > > > overhead involved in doing that when the same thing can be accomplished > > > > much more simply (and I hope we all learned that simplicity is job #1 here > > > > after reading Bruce's paper) by just using IPsec correctly mixed the > > > > appropriate client side personal firewall and routing as you point out. > > > > > > > > The latest version of our VPN client PGP 7.0 announced this week > > > > implements both of those solutions (centrally managed client side > > > > firewalling and the ability to direct all traffic to the secure gateway) > > > > along with mode-config to accomplish these goals without any of the > > > > overhead involved in trying to merge a complex protocol (L2TP) with > > > > another complex protocol (IKE/IPsec). I can only imagine (and cringe at) > > > > the logistics involved in doing a security code review of both of those > > > > together. > > > > > > > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > > > > > And one more benefit of using L2TP/IPSec is, it can support securing IP > > > > > multicast traffic, atleast over the vpn link. But if you are using native > > > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and you > > > > > will need to have atleast GRE to do this. > > > > > > > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > > > > > > > Regarding access control, some customers raised concerns that, if a client > > > > > has a VPN link connected to the corporate intranet, and is also directly > > > > > connected to the Internet, then they can't enforce the corporate firewall > > > > > policy on that client, like they can if the client was actually in the > > > > > intranet. There were also concerns raised that if the client is > > > > > directly connected to the Internet, it could be hacked, and won't be able > > > > > to have the same protection that the corporate firewall provides. > > > > > > > > > > There are atleast two ways of dealing with this: > > > > > > > > > > 1. put an equalent of the corporate firewall on the client so that it can > > > > > defend itself, and also enforce the corporate firewall policy. > > > > > > > > > > 2. have a very simple policy on the client that says all traffic will go > > > > > via the VPN link to the corporate network, and the client will accept/send > > > > > nothing else. This would be the true emulation of the Dial-in remote > > > > > access, and this can be acheived naturally using L2TP. > > > > > > > > > > chinna > > > > > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something to > > > > > > >work, and get something to customers, until there is a client that can do > > > > > > >IPSec and L2TP. > > > > > > > > > > > > > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I > > > > > > >beleive that Cisco's long term goal is to follow whatever is standardized > > > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > > > > > > > > > > > > > > > > > > > That's one view. > > > > > > > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > > > > Microsoft & Cisco to preserve a joint development investment in L2TP, > > > > > > irrespective of its technical merit in this context :-). If I am > > > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > > > > then the extra headers introduced by L2TP are not only wasteful of > > > > > > bandwidth on a continuing basis, but they also interfere with the > > > > > > access controls that are an essential part of IPsec. One needs some > > > > > > means of dealing with bind time connection parameters, but use of > > > > > > L2TP on a continuing basis is an expensive means of achieving this > > > > > > goal. > > > > > > > > > > > > -- > > > > Will Price, Director of Engineering > > > > PGP Security, Inc. > > > > a division of Network Associates, Inc. > > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu May 11 20:37:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA20056; Thu, 11 May 2000 20:37:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA22684 Thu, 11 May 2000 22:35:18 -0400 (EDT) Date: Thu, 11 May 2000 19:41:54 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Jan Vilhuber cc: Will Price , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think there was a decision made at the recent IETF meeting that anything that modifies IKE will be dealt in the IPSec WG, and that is the reason why Xauth/Modeconfig are not on the agenda of IPSRA. I guess, this is the right place to have this discussion. chinna PS: IPSec = IPsec, and IPSRA is referring to IP Security Remote Access. On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > Is this discussion already taking place there? > > chinna > > On Thu, 11 May 2000, Jan Vilhuber wrote: > > > This discussion belongs on the IPSRA mailing list, if I'm not mistaken. > > > > jan > > > > > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > > > I guess the bottom line is: > > > > > > Do you want to understand all the subtilities of AAA and IPCP, and then > > > massively hack IKE on an ongoing basis, to incorporate all that, (with > > > stuff like open ended exchanges, and on top of that require that every > > > client need a "personal firewall") > > > > > > or > > > > > > Do you want to leverage all the features of AAA and IPCP in a simple > > > modular way, and not bother too much about them, and trust them in that > > > they do their job well. > > > > > > Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead? > > > > > > chinna > > > > > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > > > > > Atleast we agree on one thing: we should strive for simplicity. > > > > > > > > We are essentially talking about adding all the AAA and IPCP baggage to > > > > IKE. And that you say is simple! > > > > > > > > On top of that you want each IPSec client to have a "personal firewall" > > > > too. I can see why people want to suggest that. > > > > > > > > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the > > > > AAA and IPCP, and let IPSec protect L2TP. > > > > > > > > L2TP is fully encapsulated in IPSec, and I don't see how that is less > > > > secure. > > > > > > > > I don't see how it is simple to introduce the AAA and IPCP baggage into > > > > IKE. How many forms of Authenticataion do you already support. Do you > > > > support Authorization and Accounting? How many features of IPCP do you > > > > already support? Probably it is simple for you because your customer base > > > > needs only a small subset of these features. But, once we open the flood > > > > gates, then customers would like to have all the features that they have > > > > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on > > > > an ongoing basis to add in features. > > > > > > > > chinna > > > > > > > > On Thu, 11 May 2000, Will Price wrote: > > > > > > > > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > > > > > but the issue to get back to Stephen's point is that there is a lot of > > > > > overhead involved in doing that when the same thing can be accomplished > > > > > much more simply (and I hope we all learned that simplicity is job #1 here > > > > > after reading Bruce's paper) by just using IPsec correctly mixed the > > > > > appropriate client side personal firewall and routing as you point out. > > > > > > > > > > The latest version of our VPN client PGP 7.0 announced this week > > > > > implements both of those solutions (centrally managed client side > > > > > firewalling and the ability to direct all traffic to the secure gateway) > > > > > along with mode-config to accomplish these goals without any of the > > > > > overhead involved in trying to merge a complex protocol (L2TP) with > > > > > another complex protocol (IKE/IPsec). I can only imagine (and cringe at) > > > > > the logistics involved in doing a security code review of both of those > > > > > together. > > > > > > > > > > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > > > > > > > And one more benefit of using L2TP/IPSec is, it can support securing IP > > > > > > multicast traffic, atleast over the vpn link. But if you are using native > > > > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and you > > > > > > will need to have atleast GRE to do this. > > > > > > > > > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > > > > > > > > > Regarding access control, some customers raised concerns that, if a client > > > > > > has a VPN link connected to the corporate intranet, and is also directly > > > > > > connected to the Internet, then they can't enforce the corporate firewall > > > > > > policy on that client, like they can if the client was actually in the > > > > > > intranet. There were also concerns raised that if the client is > > > > > > directly connected to the Internet, it could be hacked, and won't be able > > > > > > to have the same protection that the corporate firewall provides. > > > > > > > > > > > > There are atleast two ways of dealing with this: > > > > > > > > > > > > 1. put an equalent of the corporate firewall on the client so that it can > > > > > > defend itself, and also enforce the corporate firewall policy. > > > > > > > > > > > > 2. have a very simple policy on the client that says all traffic will go > > > > > > via the VPN link to the corporate network, and the client will accept/send > > > > > > nothing else. This would be the true emulation of the Dial-in remote > > > > > > access, and this can be acheived naturally using L2TP. > > > > > > > > > > > > chinna > > > > > > > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > > > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something to > > > > > > > >work, and get something to customers, until there is a client that can do > > > > > > > >IPSec and L2TP. > > > > > > > > > > > > > > > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I > > > > > > > >beleive that Cisco's long term goal is to follow whatever is standardized > > > > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > > > > > > > > > > > > > > > > > > > > > > That's one view. > > > > > > > > > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > > > > > Microsoft & Cisco to preserve a joint development investment in L2TP, > > > > > > > irrespective of its technical merit in this context :-). If I am > > > > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > > > > > then the extra headers introduced by L2TP are not only wasteful of > > > > > > > bandwidth on a continuing basis, but they also interfere with the > > > > > > > access controls that are an essential part of IPsec. One needs some > > > > > > > means of dealing with bind time connection parameters, but use of > > > > > > > L2TP on a continuing basis is an expensive means of achieving this > > > > > > > goal. > > > > > > > > > > > > > > > -- > > > > > Will Price, Director of Engineering > > > > > PGP Security, Inc. > > > > > a division of Network Associates, Inc. > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > > s/w engineer > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > > > > > > -- > > Jan Vilhuber vilhuber@cisco.com > > Cisco Systems, San Jose (408) 527-0847 > > > > chinna narasimha reddy pellacuru > s/w engineer > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri May 12 02:03:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10323; Fri, 12 May 2000 02:03:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA23456 Fri, 12 May 2000 03:44:21 -0400 (EDT) Message-ID: <391BB902.6662FAFC@cisco.com> Date: Fri, 12 May 2000 09:55:46 +0200 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: wprice@cyphers.net CC: Sami Vaarala , ipsec@lists.tislabs.com Subject: Re: Win2000 IKE and 3des References: <391A68FA.326666F2@netseal.com> <391B4C40.C64DBD37@cyphers.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I fully agree. Actually, it is not so silent. The first time it does so, Windows posts an event to the event log. But it took me a while to figure it out the first time as the event log is not very handy to debug. This is really nasty to me. Especially if you run IPSec between two Win2K boxes => negociation will succeed but you may never notice it is DES instead of 3DES. I noticed the issue when negociating against a Cisco router. Actually, Win2K will negociate DES instead of 3DES on non US registered releases only (at least). There seem to be a strong encryption version of Win2K (license ?). fred Will Price wrote: > > This sounds fairly serious to me. > > Perhaps this should be posted to BugTraq. This needs confirmation. I > thought I saw something like this when I was doing my tests against Win2K, > but it's been quite some time since then. > > Sami Vaarala wrote: > > >Are both of you saying that if you set your policy for 3-DES ONLY (not >3-DES prefered but 3-DES only) that Windows 2000 will negotiate DES >anyway? > > > > Yes, that seems to be the case. I have only checked that if I configure > > 3des, it will send des as an initiator, and a phase 1 SA with des will > > be formed (if the remote end accepts des). Haven't checked if it works > > this way as a responder; probably will. > > > > >Or are you saying that Windows 2000 will fall back from 3-DES to DES if >your configured policy lets it do so and the peer doesn't support >3-DES? > > > > No. This would be the correct way to function, and there would not be > > an issue if this were the case. > > > > >The former is a bug which I've not seen in Windows 2000. The latter is > > >expected behavior since you configured it to do so. > > > > My point exactly. The latter behavior would be the one I would prefer > > to see, of course. > > -- > Will Price, Director of Engineering > PGP Security, Inc. > a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Fri May 12 07:19:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23797; Fri, 12 May 2000 07:19:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24633 Fri, 12 May 2000 08:32:59 -0400 (EDT) Message-ID: <8B888AAAAB0FD31189590008C7918443014CFF1B@zbl6c002.corpeast.baynetworks.com> From: "Shekhar Kshirsagar" To: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Fri, 12 May 2000 05:40:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBC0F.4012FEC2" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFBC0F.4012FEC2 Content-Type: text/plain; charset="ISO-8859-1" I can understand the waste of bandwidth by L2TP. But, can you please elaborate more on how does L2TP interfere with the access controls? Thanks, Shekhar > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Thursday, May 11, 2000 5:15 PM > To: CHINNA N.R. PELLACURU > Cc: ipsec@lists.tislabs.com > Subject: Re: Windows 2000 and Cicsco router interoperability > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > >I can't speak for the whole of Cisco, but the way I look at it is: > > > >Modeconfig/Xauth are being supported as quick hack to get > something to > >work, and get something to customers, until there is a > client that can do > >IPSec and L2TP. > > > >I beleive that it is not our long term vision, to ship > Modeconfig/Xauth. I > >beleive that Cisco's long term goal is to follow whatever is > standardized > >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > > > > That's one view. > > Another perspective is that L2TP over IPsec represents an effort by > Microsoft & Cisco to preserve a joint development investment in L2TP, > irrespective of its technical merit in this context :-). If I am > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > then the extra headers introduced by L2TP are not only wasteful of > bandwidth on a continuing basis, but they also interfere with the > access controls that are an essential part of IPsec. One needs some > means of dealing with bind time connection parameters, but use of > L2TP on a continuing basis is an expensive means of achieving this > goal. > > Steve ------_=_NextPart_001_01BFBC0F.4012FEC2 Content-Type: text/html; charset="ISO-8859-1" RE: Windows 2000 and Cicsco router interoperability

I can understand the waste of bandwidth by L2TP.
But, can you please elaborate more on how does L2TP interfere
with the access controls?

Thanks,
Shekhar

> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Thursday, May 11, 2000 5:15 PM
> To: CHINNA N.R. PELLACURU
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Windows 2000 and Cicsco router interoperability
>
>
> At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote:
> >I can't speak for the whole of Cisco, but the way I look at it is:
> >
> >Modeconfig/Xauth are being supported as quick hack to get
> something to
> >work, and get something to customers, until there is a
> client that can do
> >IPSec and L2TP.
> >
> >I beleive that it is not our long term vision, to ship
> Modeconfig/Xauth. I
> >beleive that Cisco's long term goal is to follow whatever is
> standardized
> >in the IPSRA WG, because that's what IPSRA WG is chartered to solve.
> >
>
> That's one view.
>
> Another perspective is that L2TP over IPsec represents an effort by
> Microsoft & Cisco to preserve a joint development investment in L2TP,
> irrespective of its technical merit in this context :-). If I am
> sending non-IP packets, L2TP is appropriate, but if I am sending IP,
> then the extra headers introduced by L2TP are not only wasteful of
> bandwidth on a continuing basis, but they also interfere with the
> access controls that are an essential part of IPsec. One needs some
> means of dealing with bind time connection parameters, but use of
> L2TP on a continuing basis is an expensive means of achieving this
> goal.
>
> Steve

------_=_NextPart_001_01BFBC0F.4012FEC2-- From owner-ipsec@lists.tislabs.com Fri May 12 07:19:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23819; Fri, 12 May 2000 07:19:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA24702 Fri, 12 May 2000 08:57:10 -0400 (EDT) Message-ID: <71984F8FB76AD211AC3E00A0C9C578C702627E86@hasmsx32.iil.intel.com> From: "Elzur, Uri" To: Fabio Zamparelli , Philippe Piemont Cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Fri, 12 May 2000 05:53:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA24678 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Fabio You could use other NICs as well. For example Intel Pro/100 S thx Uri Elzur uri.elzur@intel.com -----Original Message----- From: Fabio Zamparelli [mailto:zamparelli@mclink.it] Sent: Wednesday, May 10, 2000 11:34 AM To: Philippe Piemont Cc: ipsec@lists.tislabs.com Subject: R: Windows 2000 and Cicsco router interoperability Hi, in two months from now I'll be setting up a similar test bed for my university final thesis for IPSEC perfomance testing purpose. I'll use 3com 3CR990-TX-95 (but I was wondering if as an Academic I was able to have the TX-97 version), 2 Win2k in tunnel-mode authenticated by a Cert Server (in first istance a Win2k Server, but in a second time, for interoperability testing I think there will be a Linux Box) 4 or 5 standard router in the meddle and 2 win9x client on the two end sides. Are you sure in your test the win2k box were Professional and not Server? I thought I would need the Server version. As my second would be a transport test host to host (authenticated by certificates) with 2 Win2k Professional I'd be happy to know the workstastions could be the same as in the first test bed. Thanks, Fabio (Zed) Zamparelli Università di Napoli Federico II GRID (Gruppo di Ricerca sull'Informatica Distribuita-Research Group on Distributed Systems) http://www.grid.unina.it/ > -----Messaggio originale----- > Da: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]Per conto di Philippe Piemont > Inviato: martedì 9 maggio 2000 16.53 > A: Mike Carney > Cc: ipsec@lists.tislabs.com > Oggetto: Re: Windows 2000 and Cicsco router interoperability > > > > > Hi Mike > To be able to sell the 3Com 3CR990 NIC Card (card allowing to > offload encryption > to a dedicated ASIC (VLSI)) > I had to demonstrate to the French NSA (SCSSI) the following config: > PCA (windows 95 no encryption) ---- PC1 (Windows 2K Professionnal IPSEC in > tunnel mode) ====== PC2 (Windows 2K Professionnal IPSEC in tunnel > mode) ---- PC2 > (windows 95 no encryption) > the test was a ping from PC1 to PC2 > with an analyser on the tunnel > No doubt it works fine > Best regards > Philippe From owner-ipsec@lists.tislabs.com Fri May 12 07:44:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24174; Fri, 12 May 2000 07:44:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24849 Fri, 12 May 2000 09:37:02 -0400 (EDT) Message-ID: <447A3F40A07FD211BA2700A0C99D759B78905C@md-exchange1.nai.com> From: "Mason, David" To: "'CHINNA N.R. PELLACURU'" , Will Price Cc: Stephen Kent , ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Fri, 12 May 2000 06:43:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Every client should have a personal firewall regardless of whether it's PPP+L2TP+IPSEC+IKE or just IPSEC+(MODECFG+IKE) since they'll often be connecting directly to the Internet without going through the corporate firewall (no VPN). -dave -----Original Message----- From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] Sent: Thursday, May 11, 2000 10:10 PM To: Will Price Cc: Stephen Kent; ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability I guess the bottom line is: Do you want to understand all the subtilities of AAA and IPCP, and then massively hack IKE on an ongoing basis, to incorporate all that, (with stuff like open ended exchanges, and on top of that require that every client need a "personal firewall") or Do you want to leverage all the features of AAA and IPCP in a simple modular way, and not bother too much about them, and trust them in that they do their job well. Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead? chinna On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > Atleast we agree on one thing: we should strive for simplicity. > > We are essentially talking about adding all the AAA and IPCP baggage to > IKE. And that you say is simple! > > On top of that you want each IPSec client to have a "personal firewall" > too. I can see why people want to suggest that. > > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the > AAA and IPCP, and let IPSec protect L2TP. > > L2TP is fully encapsulated in IPSec, and I don't see how that is less > secure. > > I don't see how it is simple to introduce the AAA and IPCP baggage into > IKE. How many forms of Authenticataion do you already support. Do you > support Authorization and Accounting? How many features of IPCP do you > already support? Probably it is simple for you because your customer base > needs only a small subset of these features. But, once we open the flood > gates, then customers would like to have all the features that they have > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on > an ongoing basis to add in features. > > chinna > > On Thu, 11 May 2000, Will Price wrote: > > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > > but the issue to get back to Stephen's point is that there is a lot of > > overhead involved in doing that when the same thing can be accomplished > > much more simply (and I hope we all learned that simplicity is job #1 here > > after reading Bruce's paper) by just using IPsec correctly mixed the > > appropriate client side personal firewall and routing as you point out. > > > > The latest version of our VPN client PGP 7.0 announced this week > > implements both of those solutions (centrally managed client side > > firewalling and the ability to direct all traffic to the secure gateway) > > along with mode-config to accomplish these goals without any of the > > overhead involved in trying to merge a complex protocol (L2TP) with > > another complex protocol (IKE/IPsec). I can only imagine (and cringe at) > > the logistics involved in doing a security code review of both of those > > together. > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > And one more benefit of using L2TP/IPSec is, it can support securing IP > > > multicast traffic, atleast over the vpn link. But if you are using native > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and you > > > will need to have atleast GRE to do this. > > > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > > > Regarding access control, some customers raised concerns that, if a client > > > has a VPN link connected to the corporate intranet, and is also directly > > > connected to the Internet, then they can't enforce the corporate firewall > > > policy on that client, like they can if the client was actually in the > > > intranet. There were also concerns raised that if the client is > > > directly connected to the Internet, it could be hacked, and won't be able > > > to have the same protection that the corporate firewall provides. > > > > > > There are atleast two ways of dealing with this: > > > > > > 1. put an equalent of the corporate firewall on the client so that it can > > > defend itself, and also enforce the corporate firewall policy. > > > > > > 2. have a very simple policy on the client that says all traffic will go > > > via the VPN link to the corporate network, and the client will accept/send > > > nothing else. This would be the true emulation of the Dial-in remote > > > access, and this can be acheived naturally using L2TP. > > > > > > chinna > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something to > > > > >work, and get something to customers, until there is a client that can do > > > > >IPSec and L2TP. > > > > > > > > > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I > > > > >beleive that Cisco's long term goal is to follow whatever is standardized > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > > > > > > > > > > > > > That's one view. > > > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > > Microsoft & Cisco to preserve a joint development investment in L2TP, > > > > irrespective of its technical merit in this context :-). If I am > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > > then the extra headers introduced by L2TP are not only wasteful of > > > > bandwidth on a continuing basis, but they also interfere with the > > > > access controls that are an essential part of IPsec. One needs some > > > > means of dealing with bind time connection parameters, but use of > > > > L2TP on a continuing basis is an expensive means of achieving this > > > > goal. > > > > > > -- > > Will Price, Director of Engineering > > PGP Security, Inc. > > a division of Network Associates, Inc. > > > > chinna narasimha reddy pellacuru > s/w engineer > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri May 12 08:25:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25262; Fri, 12 May 2000 08:25:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24996 Fri, 12 May 2000 10:18:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <8B888AAAAB0FD31189590008C7918443014CFF1B@zbl6c002.corpeast.baynetworks.co m> References: <8B888AAAAB0FD31189590008C7918443014CFF1B@zbl6c002.corpeast.baynetworks.co m> Date: Fri, 12 May 2000 10:18:32 -0400 To: "Shekhar Kshirsagar" From: Stephen Kent Subject: RE: Windows 2000 and Cicsco router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Shekhar, >I can understand the waste of bandwidth by L2TP. >But, can you please elaborate more on how does L2TP interfere >with the access controls? IPsec includes access controls analogous to those of a stateless, packet filtering firewall. The receiver knows the SA to which each packet is cryptographically bound, thus it can match the packet headers (selectors) against those that were negotiated for the SA in question. If a packet arrives over a tunnel mode SA, the receiving IPsec implementation checks the inner IP (and transport layer) header, while in transport mode, the outer IP header (and the inner transport header). When L2TP is used with IPsec, the L2TP spec calls for transport mode SAs, which means that only the outer IP header is checked. Thus the tunneled IP packet is not checked for access contorl purposes by IPsec. Once a packet leaves the IPsec environment, this binding to an SA is lost (unless some non-standard mechanisms are employed to maintain the binding). So the best that a separate firewall can do is to match the packet against its filter list to see if it matches ANY filter rule. This is much less secure. Steve From owner-ipsec@lists.tislabs.com Fri May 12 09:44:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA26825; Fri, 12 May 2000 09:44:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25173 Fri, 12 May 2000 11:25:38 -0400 (EDT) Date: Fri, 12 May 2000 08:30:55 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: "Mason, David" cc: Will Price , Stephen Kent , ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: <447A3F40A07FD211BA2700A0C99D759B78905C@md-exchange1.nai.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Frankly I like the notion of a personal firewall. I feel empowered, just by the thought that I have my own personal firewall. I agree with you that every one should have their personal firewall. But, that doesn't really fit into this paradigm of a "dumb client", that the proponents of modeconfig/xauth are pushing. The client is supposed to be dumb, and get even it's configuration parameters and phase2 policy, and if possible it's phase1 policy from the server. The average corporate executive (road warrior) is supposed to be so dumb that he is not expected to do anything other than powering up his laptop, and clicking a few icons. So, we push yet another policy to the client: the firewall policy. And if the "dumb client" wants to support securing multicast traffic, then we setup a logical GRE tunnel interface on the client, and push routing policy onto the client. So, we the client will be a dumb and powerful! chinna On Fri, 12 May 2000, Mason, David wrote: > Every client should have a personal firewall regardless of > whether it's PPP+L2TP+IPSEC+IKE or just IPSEC+(MODECFG+IKE) > since they'll often be connecting directly to the Internet > without going through the corporate firewall (no VPN). > -dave > > -----Original Message----- > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > Sent: Thursday, May 11, 2000 10:10 PM > To: Will Price > Cc: Stephen Kent; ipsec@lists.tislabs.com > Subject: Re: Windows 2000 and Cicsco router interoperability > > > I guess the bottom line is: > > Do you want to understand all the subtilities of AAA and IPCP, and then > massively hack IKE on an ongoing basis, to incorporate all that, (with > stuff like open ended exchanges, and on top of that require that every > client need a "personal firewall") > > or > > Do you want to leverage all the features of AAA and IPCP in a simple > modular way, and not bother too much about them, and trust them in that > they do their job well. > > Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead? > > chinna > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > Atleast we agree on one thing: we should strive for simplicity. > > > > We are essentially talking about adding all the AAA and IPCP baggage to > > IKE. And that you say is simple! > > > > On top of that you want each IPSec client to have a "personal firewall" > > too. I can see why people want to suggest that. > > > > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the > > AAA and IPCP, and let IPSec protect L2TP. > > > > L2TP is fully encapsulated in IPSec, and I don't see how that is less > > secure. > > > > I don't see how it is simple to introduce the AAA and IPCP baggage into > > IKE. How many forms of Authenticataion do you already support. Do you > > support Authorization and Accounting? How many features of IPCP do you > > already support? Probably it is simple for you because your customer base > > needs only a small subset of these features. But, once we open the flood > > gates, then customers would like to have all the features that they have > > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on > > an ongoing basis to add in features. > > > > chinna > > > > On Thu, 11 May 2000, Will Price wrote: > > > > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > > > but the issue to get back to Stephen's point is that there is a lot of > > > overhead involved in doing that when the same thing can be accomplished > > > much more simply (and I hope we all learned that simplicity is job #1 > here > > > after reading Bruce's paper) by just using IPsec correctly mixed the > > > appropriate client side personal firewall and routing as you point out. > > > > > > The latest version of our VPN client PGP 7.0 announced this week > > > implements both of those solutions (centrally managed client side > > > firewalling and the ability to direct all traffic to the secure gateway) > > > along with mode-config to accomplish these goals without any of the > > > overhead involved in trying to merge a complex protocol (L2TP) with > > > another complex protocol (IKE/IPsec). I can only imagine (and cringe > at) > > > the logistics involved in doing a security code review of both of those > > > together. > > > > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > > > And one more benefit of using L2TP/IPSec is, it can support securing > IP > > > > multicast traffic, atleast over the vpn link. But if you are using > native > > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and > you > > > > will need to have atleast GRE to do this. > > > > > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > > > > > Regarding access control, some customers raised concerns that, if a > client > > > > has a VPN link connected to the corporate intranet, and is also > directly > > > > connected to the Internet, then they can't enforce the corporate > firewall > > > > policy on that client, like they can if the client was actually in the > > > > intranet. There were also concerns raised that if the client is > > > > directly connected to the Internet, it could be hacked, and won't be > able > > > > to have the same protection that the corporate firewall provides. > > > > > > > > There are atleast two ways of dealing with this: > > > > > > > > 1. put an equalent of the corporate firewall on the client so that it > can > > > > defend itself, and also enforce the corporate firewall policy. > > > > > > > > 2. have a very simple policy on the client that says all traffic will > go > > > > via the VPN link to the corporate network, and the client will > accept/send > > > > nothing else. This would be the true emulation of the Dial-in remote > > > > access, and this can be acheived naturally using L2TP. > > > > > > > > chinna > > > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something > to > > > > > >work, and get something to customers, until there is a client that > can do > > > > > >IPSec and L2TP. > > > > > > > > > > > >I beleive that it is not our long term vision, to ship > Modeconfig/Xauth. I > > > > > >beleive that Cisco's long term goal is to follow whatever is > standardized > > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to > solve. > > > > > > > > > > > > > > > > That's one view. > > > > > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > > > Microsoft & Cisco to preserve a joint development investment in > L2TP, > > > > > irrespective of its technical merit in this context :-). If I am > > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > > > then the extra headers introduced by L2TP are not only wasteful of > > > > > bandwidth on a continuing basis, but they also interfere with the > > > > > access controls that are an essential part of IPsec. One needs some > > > > > means of dealing with bind time connection parameters, but use of > > > > > L2TP on a continuing basis is an expensive means of achieving this > > > > > goal. > > > > > > > > > -- > > > Will Price, Director of Engineering > > > PGP Security, Inc. > > > a division of Network Associates, Inc. > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > > > chinna narasimha reddy pellacuru > s/w engineer > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri May 12 13:46:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00366; Fri, 12 May 2000 13:46:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA26083 Fri, 12 May 2000 15:22:21 -0400 (EDT) Subject: RE: Win2000 IKE and 3des Date: Fri, 12 May 2000 12:25:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBC47.CF23CF96" Message-ID: <6A05D00595BE644E9F435BE5947423F2BB557F@fifi.platinum.corp.microsoft.com> content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4366.0 Thread-Topic: Win2000 IKE and 3des Thread-Index: Ab+76airntmDhit7QnqXThqqAPJSpAAXUnCA From: "Sumi Singh" To: , Cc: "Sami Vaarala" , X-OriginalArrivalTime: 12 May 2000 19:27:31.0397 (UTC) FILETIME=[1DD72750:01BFBC48] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFBC47.CF23CF96 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to clarify the behaviour of Windows 2000 -=20 Windows 2000 weakens 3DES policy to DES if you do not have the strong encryption pack (128-bit) installed. This weakening is announced by an event in the Audit log. So if you have 2 peers with no encryption pack installed, and a policy to use 3DES, they will talk DES since they cannot do 3DES.=20 However if one of the peers has high encryption pack installed and his policy has 3DES only, then he will not accept DES from the other peer and the negotiation will fail. For dometic versions you can install the strong crypto pack for doing 3DES from http://www.microsoft.com/windows2000/downloads/recommended/encryption/de fault.asp Sumi. -----Original Message----- From: Fr=E9d=E9ric Detienne [mailto:fd@cisco.com] Sent: Friday, May 12, 2000 12:56 AM To: wprice@cyphers.net Cc: Sami Vaarala; ipsec@lists.tislabs.com Subject: Re: Win2000 IKE and 3des I fully agree. Actually, it is not so silent. The first time it does so, Windows posts an event to the event log. But it took me a while to figure it out the first time as the event log is not very handy to debug. This is really nasty to me. Especially if you run IPSec between two Win2K boxes =3D> negociation will succeed but you may never notice it is DES instead of 3DES. I noticed the issue when negociating against a Cisco router. Actually, Win2K will negociate DES instead of 3DES on non US registered releases only (at least). There seem to be a strong encryption version of Win2K (license ?). fred Will Price wrote: >=20 > This sounds fairly serious to me. >=20 > Perhaps this should be posted to BugTraq. This needs confirmation. I > thought I saw something like this when I was doing my tests against Win2K, > but it's been quite some time since then. >=20 > Sami Vaarala wrote: > > >Are both of you saying that if you set your policy for 3-DES ONLY (not >3-DES prefered but 3-DES only) that Windows 2000 will negotiate DES >anyway? > > > > Yes, that seems to be the case. I have only checked that if I configure > > 3des, it will send des as an initiator, and a phase 1 SA with des will > > be formed (if the remote end accepts des). Haven't checked if it works > > this way as a responder; probably will. > > > > >Or are you saying that Windows 2000 will fall back from 3-DES to DES if >your configured policy lets it do so and the peer doesn't support >3-DES? > > > > No. This would be the correct way to function, and there would not be > > an issue if this were the case. > > > > >The former is a bug which I've not seen in Windows 2000. The latter is > > >expected behavior since you configured it to do so. > > > > My point exactly. The latter behavior would be the one I would prefer > > to see, of course. >=20 > -- > Will Price, Director of Engineering > PGP Security, Inc. > a division of Network Associates, Inc. ------_=_NextPart_001_01BFBC47.CF23CF96 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Win2000 IKE and 3des

Just to clarify the behaviour of Windows 2000 - =
Windows 2000 weakens 3DES policy to DES if you do not = have the strong encryption pack (128-bit) installed. This weakening is = announced by an event in the Audit log. So if you have 2 peers with no = encryption pack installed, and a policy to use 3DES, they will talk DES = since they cannot do 3DES.

However if one of the peers has high encryption pack = installed and his policy has 3DES only, then he will not accept DES from = the other peer and the negotiation will fail.

For dometic versions you can install the strong crypto = pack for doing 3DES from http://www.microsoft.com/windows2000/downloads/recommen= ded/encryption/default.asp

Sumi.
-----Original Message-----
From: Fr=E9d=E9ric Detienne [mailto:fd@cisco.com]
Sent: Friday, May 12, 2000 12:56 AM
To: wprice@cyphers.net
Cc: Sami Vaarala; ipsec@lists.tislabs.com
Subject: Re: Win2000 IKE and 3des


I fully agree.

Actually, it is not so silent. The first time it does = so, Windows posts an event to the event log. But it took me a while to = figure it out the first time as the event log is not very handy to = debug.

This is really nasty to me. Especially if you run = IPSec between two Win2K boxes =3D> negociation will succeed but you = may never notice it is DES instead of 3DES.

I noticed the issue when negociating against a Cisco = router.

Actually, Win2K will negociate DES instead of 3DES on = non US registered releases only (at least). There seem to be a strong = encryption version of Win2K (license ?).

        fred

Will Price wrote:
>
> This sounds fairly serious to me.
>
> Perhaps this should be posted to BugTraq.  = This needs confirmation.  I
> thought I saw something like this when I was = doing my tests against Win2K,
> but it's been quite some time since then.
>
> Sami Vaarala wrote:
> > >Are both of you saying that if you set = your policy for 3-DES ONLY (not >3-DES prefered but 3-DES only) that = Windows 2000 will negotiate DES >anyway?

> >
> > Yes, that seems to be the case.  I = have only checked that if I configure
> > 3des, it will send des as an initiator, and = a phase 1 SA with des will
> > be formed (if the remote end accepts = des).  Haven't checked if it works
> > this way as a responder; probably = will.
> >
> > >Or are you saying that Windows 2000 = will fall back from 3-DES to DES if >your configured policy lets it = do so and the peer doesn't support >3-DES?

> >
> > No.  This would be the correct way to = function, and there would not be
> > an issue if this were the case.
> >
> > >The former is a bug which I've not seen = in Windows 2000.  The latter is
> > >expected behavior since you configured = it to do so.
> >
> > My point exactly.  The latter behavior = would be the one I would prefer
> > to see, of course.
>
> --
> Will Price, Director of Engineering
> PGP Security, Inc.
> a division of Network Associates, Inc.

------_=_NextPart_001_01BFBC47.CF23CF96-- From owner-ipsec@lists.tislabs.com Fri May 12 14:18:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00815; Fri, 12 May 2000 14:18:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26280 Fri, 12 May 2000 16:16:17 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14620.26714.300239.321461@xedia.com> Date: Fri, 12 May 2000 16:23:54 -0400 (EDT) To: sumis@Exchange.Microsoft.com Cc: ipsec@lists.tislabs.com Subject: RE: Win2000 IKE and 3des References: <6A05D00595BE644E9F435BE5947423F2BB557F@fifi.platinum.corp.microsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Sumi" == Sumi Singh writes: Sumi> Just to clarify the behaviour of Windows 2000 - Windows 2000 Sumi> weakens 3DES policy to DES if you do not have the strong Sumi> encryption pack (128-bit) installed. This weakening is Sumi> announced by an event in the Audit log. So if you have 2 peers Sumi> with no encryption pack installed, and a policy to use 3DES, Sumi> they will talk DES since they cannot do 3DES. Clearly that's a major design error. If you ask for something that's not supported, it should be rejected. To change it (even with a message in some obscure log) is clearly wrong. You don't build secure systems that way. paul From owner-ipsec@lists.tislabs.com Fri May 12 14:27:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA00907; Fri, 12 May 2000 14:27:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA26301 Fri, 12 May 2000 16:26:09 -0400 (EDT) From: "James M. Winebrenner" To: "'Mason, David'" , "'CHINNA N.R. PELLACURU'" , "'Will Price'" Cc: "'Stephen Kent'" , Subject: RE: Windows 2000 and Cicsco router interoperability Date: Fri, 12 May 2000 13:33:08 -0700 Message-ID: <002b01bfbc51$82a1fc10$db01010a@us.checkpoint.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.2232.26 In-Reply-To: <447A3F40A07FD211BA2700A0C99D759B78905C@md-exchange1.nai.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is true, however, more important than the client having a firewall is having it enforce a policy commensurate with the security policy of the corporate network. If there is no methodology for ensuring that the client can not be (or is not already) compromised before a tunnel to the corporate network is established, the utility of the personal firewall is effectively zero. At the least, not allowing split tunnels, is somewhat effective, but the residual effect of routing all remote users Internet traffic through the corporate firewalls/gateways may not be desirable. -James -------------------------------------------------------- The content of this message may contain private views and opinions which do not constitute a formal disclosure or commitment unless specifically stated. -------------------------------------------------------- > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Mason, David > Sent: Friday, May 12, 2000 6:44 AM > To: 'CHINNA N.R. PELLACURU'; Will Price > Cc: Stephen Kent; ipsec@lists.tislabs.com > Subject: RE: Windows 2000 and Cicsco router interoperability > > > Every client should have a personal firewall regardless of > whether it's PPP+L2TP+IPSEC+IKE or just IPSEC+(MODECFG+IKE) > since they'll often be connecting directly to the Internet > without going through the corporate firewall (no VPN). > -dave > > -----Original Message----- > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > Sent: Thursday, May 11, 2000 10:10 PM > To: Will Price > Cc: Stephen Kent; ipsec@lists.tislabs.com > Subject: Re: Windows 2000 and Cicsco router interoperability > > > I guess the bottom line is: > > Do you want to understand all the subtilities of AAA and > IPCP, and then > massively hack IKE on an ongoing basis, to incorporate > all that, (with > stuff like open ended exchanges, and on top of that > require that every > client need a "personal firewall") > > or > > Do you want to leverage all the features of AAA and IPCP > in a simple > modular way, and not bother too much about them, and > trust them in that > they do their job well. > > Isn't securing CHAP/SecureID etc. within an IKE exchange > an overhead? > > chinna > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > Atleast we agree on one thing: we should strive for simplicity. > > > > We are essentially talking about adding all the AAA > and IPCP baggage to > > IKE. And that you say is simple! > > > > On top of that you want each IPSec client to have a > "personal firewall" > > too. I can see why people want to suggest that. > > > > IMHO, it is much much simpler and modular to let > L2TP/PPP deal with the > > AAA and IPCP, and let IPSec protect L2TP. > > > > L2TP is fully encapsulated in IPSec, and I don't see > how that is less > > secure. > > > > I don't see how it is simple to introduce the AAA and > IPCP baggage into > > IKE. How many forms of Authenticataion do you already > support. Do you > > support Authorization and Accounting? How many > features of IPCP do you > > already support? Probably it is simple for you because > your customer base > > needs only a small subset of these features. But, once > we open the flood > > gates, then customers would like to have all the > features that they have > > come to enjoy in AAA and IPCP, and I guess we have to > hack the protocol on > > an ongoing basis to add in features. > > > > chinna > > > > On Thu, 11 May 2000, Will Price wrote: > > > > > Those goals may be able to be "achieved naturally" > by use of L2TP/IPsec, > > > but the issue to get back to Stephen's point is that > there is a lot of > > > overhead involved in doing that when the same thing > can be accomplished > > > much more simply (and I hope we all learned that > simplicity is job #1 > here > > > after reading Bruce's paper) by just using IPsec > correctly mixed the > > > appropriate client side personal firewall and > routing as you point out. > > > > > > The latest version of our VPN client PGP 7.0 > announced this week > > > implements both of those solutions (centrally > managed client side > > > firewalling and the ability to direct all traffic to > the secure gateway) > > > along with mode-config to accomplish these goals > without any of the > > > overhead involved in trying to merge a complex > protocol (L2TP) with > > > another complex protocol (IKE/IPsec). I can only > imagine (and cringe > at) > > > the logistics involved in doing a security code > review of both of those > > > together. > > > > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > > > And one more benefit of using L2TP/IPSec is, it > can support securing > IP > > > > multicast traffic, atleast over the vpn link. But > if you are using > native > > > > IPSec with Mode-config/Xauth, you can't secure > multicast traffic, and > you > > > > will need to have atleast GRE to do this. > > > > > > > > I wonder how much benefit we can get out of "L2TP > Header Compression". > > > > > > > > Regarding access control, some customers raised > concerns that, if a > client > > > > has a VPN link connected to the corporate > intranet, and is also > directly > > > > connected to the Internet, then they can't enforce > the corporate > firewall > > > > policy on that client, like they can if the client > was actually in the > > > > intranet. There were also concerns raised that if > the client is > > > > directly connected to the Internet, it could be > hacked, and won't be > able > > > > to have the same protection that the corporate > firewall provides. > > > > > > > > There are atleast two ways of dealing with this: > > > > > > > > 1. put an equalent of the corporate firewall on > the client so that it > can > > > > defend itself, and also enforce the corporate > firewall policy. > > > > > > > > 2. have a very simple policy on the client that > says all traffic will > go > > > > via the VPN link to the corporate network, and the > client will > accept/send > > > > nothing else. This would be the true emulation of > the Dial-in remote > > > > access, and this can be acheived naturally using L2TP. > > > > > > > > chinna > > > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > > >I can't speak for the whole of Cisco, but the > way I look at it is: > > > > > > > > > > > >Modeconfig/Xauth are being supported as quick > hack to get something > to > > > > > >work, and get something to customers, until > there is a client that > can do > > > > > >IPSec and L2TP. > > > > > > > > > > > >I beleive that it is not our long term vision, to ship > Modeconfig/Xauth. I > > > > > >beleive that Cisco's long term goal is to > follow whatever is > standardized > > > > > >in the IPSRA WG, because that's what IPSRA WG > is chartered to > solve. > > > > > > > > > > > > > > > > That's one view. > > > > > > > > > > Another perspective is that L2TP over IPsec > represents an effort by > > > > > Microsoft & Cisco to preserve a joint > development investment in > L2TP, > > > > > irrespective of its technical merit in this > context :-). If I am > > > > > sending non-IP packets, L2TP is appropriate, but > if I am sending IP, > > > > > then the extra headers introduced by L2TP are > not only wasteful of > > > > > bandwidth on a continuing basis, but they also > interfere with the > > > > > access controls that are an essential part of > IPsec. One needs some > > > > > means of dealing with bind time connection > parameters, but use of > > > > > L2TP on a continuing basis is an expensive means > of achieving this > > > > > goal. > > > > > > > > > -- > > > Will Price, Director of Engineering > > > PGP Security, Inc. > > > a division of Network Associates, Inc. > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > > > chinna narasimha reddy pellacuru > s/w engineer > From owner-ipsec@lists.tislabs.com Fri May 12 15:19:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01564; Fri, 12 May 2000 15:19:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26436 Fri, 12 May 2000 17:10:13 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14620.29949.847824.235882@xedia.com> Date: Fri, 12 May 2000 17:17:49 -0400 (EDT) To: chunye@Exchange.Microsoft.com Cc: sumis@Exchange.Microsoft.com, ipsec@lists.tislabs.com Subject: RE: Win2000 IKE and 3des References: <19398D273324D3118A2B0008C7E9A56913554D@SIT.platinum.corp.microsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chun" == Chun Ye writes: Chun> This is not a design error. If you have an export driver, how Chun> can you expect to run 3DES? I didn't expect to use 3DES if that isn't supported. I never said that. What I said is that the system should either obey the instructions given to it, or reject them. It should never do something less secure than what it was told to do. Doing so is a major design error. Nothing less. Chun> Now why we can't reject it. Envision you are running a Chun> world-wide corporation where domain-based policies are assigned Chun> to clients at different sites at different counties. Some of Chun> them run the export version of Win2K. Since it is near Chun> impossible to know what version of Win2K clients are running, Chun> so all clients policies are set to use 3DES. On the corp-side, Chun> some servers will be configured to accept 3DES only and others Chun> both DES and 3DES. If you don't weaken 3DES on the export Chun> clients, there is no way to talk to servers with DES Chun> configured. That reasoning makes no sense whatsoever. If I wanted a configuration that is valid for either kind of crypto module, I would configure "3DES preferred, DES accepted". (Support for a policy of that form would be useful if it isn't supported currently.) But if the policy is set to "3DES only" then that means 3DES ONLY. It does NOT mean "3DES or whatever random insecure other cipher some random programmer decided to give me instead". paul From owner-ipsec@lists.tislabs.com Fri May 12 15:22:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01607; Fri, 12 May 2000 15:22:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26465 Fri, 12 May 2000 17:16:31 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: Win2000 IKE and 3des MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBC55.58D2F2C8" Date: Fri, 12 May 2000 14:02:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4366.0 Message-ID: <19398D273324D3118A2B0008C7E9A56913554D@SIT.platinum.corp.microsoft.com> Thread-Topic: Win2000 IKE and 3des Thread-Index: Ab+8UO9lt9iC29FKTsmip6X9Uul3kgABBVhA From: "Chun Ye" To: "Paul Koning" , "Sumi Singh" Cc: X-OriginalArrivalTime: 12 May 2000 21:08:20.0257 (UTC) FILETIME=[333DF110:01BFBC56] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFBC55.58D2F2C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is not a design error. If you have an export driver, how can you expect to run 3DES? Now why we can't reject it. Envision you are running a world-wide corporation where domain-based policies are assigned to clients at different sites at different counties. Some of them run the export version of Win2K. Since it is near impossible to know what version of Win2K clients are running, so all clients policies are set to use 3DES. On the corp-side, some servers will be configured to accept 3DES only and others both DES and 3DES. If you don't weaken 3DES on the export clients, there is no way to talk to servers with DES configured. Having said that, the report mechanism should probably be improved and we will address this in the next release.=20 --Chun -----Original Message----- From: Paul Koning [mailto:pkoning@xedia.com] Sent: Friday, May 12, 2000 1:24 PM To: Sumi Singh Cc: ipsec@lists.tislabs.com Subject: RE: Win2000 IKE and 3des >>>>> "Sumi" =3D=3D Sumi Singh writes: Sumi> Just to clarify the behaviour of Windows 2000 - Windows 2000 Sumi> weakens 3DES policy to DES if you do not have the strong Sumi> encryption pack (128-bit) installed. This weakening is Sumi> announced by an event in the Audit log. So if you have 2 peers Sumi> with no encryption pack installed, and a policy to use 3DES, Sumi> they will talk DES since they cannot do 3DES. Clearly that's a major design error. If you ask for something that's not supported, it should be rejected. To change it (even with a message in some obscure log) is clearly wrong. You don't build secure systems that way. paul ------_=_NextPart_001_01BFBC55.58D2F2C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Win2000 IKE and 3des

This is not a design error.  If you have an = export driver, how can you expect to run 3DES?

Now why we can't reject it.  Envision you are = running a world-wide corporation where domain-based policies are = assigned to clients at different sites at different counties.  Some = of them run the export version of Win2K.  Since it is near = impossible to know what version of Win2K clients are running, so all = clients policies are set to use 3DES.  On the corp-side, some = servers will be configured to accept 3DES only and others both DES and = 3DES.  If you don't weaken 3DES on the export clients, there is no = way to talk to servers with DES configured.

Having said that, the report mechanism should probably = be improved and we will address this in the next release.

--Chun

-----Original Message-----
From: Paul Koning [mailto:pkoning@xedia.com]
Sent: Friday, May 12, 2000 1:24 PM
To: Sumi Singh
Cc: ipsec@lists.tislabs.com
Subject: RE: Win2000 IKE and 3des


>>>>> "Sumi" =3D=3D Sumi = Singh <sumis@Exchange.Microsoft.com> writes:

 Sumi> Just to clarify the behaviour of = Windows 2000 - Windows 2000
 Sumi> weakens 3DES policy to DES if you do = not have the strong
 Sumi> encryption pack (128-bit) installed. = This weakening is
 Sumi> announced by an event in the Audit = log. So if you have 2 peers
 Sumi> with no encryption pack installed, and = a policy to use 3DES,
 Sumi> they will talk DES since they cannot = do 3DES.

Clearly that's a major design error.

If you ask for something that's not supported, it = should be rejected.
To change it (even with a message in some obscure = log) is clearly
wrong.  You don't build secure systems that = way.

        paul

------_=_NextPart_001_01BFBC55.58D2F2C8-- From owner-ipsec@lists.tislabs.com Fri May 12 16:57:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03125; Fri, 12 May 2000 16:57:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA26691 Fri, 12 May 2000 18:57:19 -0400 (EDT) From: "Michael Reilly" To: "Paul Koning" , Cc: , Subject: RE: Win2000 IKE and 3des Date: Fri, 12 May 2000 16:03:44 -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.2911.0) In-Reply-To: <14620.29949.847824.235882@xedia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>It should never do something less secure >>than what it was told to do. Doing so is a major design error. >>Nothing less. Paul is obviously correct. Therefore does anyone know of a third party package for Windows 2000 similar to the ones for NT 4.0 which does provide the security it is configured to provide without going behind your back to reduce security (hiding a message in an obscure logfile is not acceptable)? Any chance of a fix from Microsoft? michael From owner-ipsec@lists.tislabs.com Fri May 12 17:38:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA04102; Fri, 12 May 2000 17:38:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26777 Fri, 12 May 2000 19:23:39 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: Win2000 IKE and 3des MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBC66.95F8757C" Date: Fri, 12 May 2000 16:05:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4366.0 Message-ID: <19398D273324D3118A2B0008C7E9A56907AE68C7@SIT.platinum.corp.microsoft.com> Thread-Topic: Win2000 IKE and 3des Thread-Index: Ab+8ZbQUgeQYSdLaRriK/9E49q9LJQAAYDJg From: "Chun Ye" To: "Michael Reilly" , "Paul Koning" Cc: "Sumi Singh" , X-OriginalArrivalTime: 12 May 2000 23:11:44.0990 (UTC) FILETIME=[70CE87E0:01BFBC67] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFBC66.95F8757C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes this will be fixed. --Chun -----Original Message----- From: Michael Reilly [mailto:michaelr@cisco.com] Sent: Friday, May 12, 2000 4:04 PM To: Paul Koning; Chun Ye Cc: Sumi Singh; ipsec@lists.tislabs.com Subject: RE: Win2000 IKE and 3des >>It should never do something less secure >>than what it was told to do. Doing so is a major design error. >>Nothing less. Paul is obviously correct. Therefore does anyone know of a third party package for Windows 2000 similar to the ones for NT 4.0 which does provide the security it is configured to provide without going behind your back to reduce security (hiding a message in an obscure logfile is not acceptable)? Any chance of a fix from Microsoft? michael ------_=_NextPart_001_01BFBC66.95F8757C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Win2000 IKE and 3des

Yes this will be fixed.

--Chun

-----Original Message-----
From: Michael Reilly [mailto:michaelr@cisco.com]
Sent: Friday, May 12, 2000 4:04 PM
To: Paul Koning; Chun Ye
Cc: Sumi Singh; ipsec@lists.tislabs.com
Subject: RE: Win2000 IKE and 3des


>>It should never do something less = secure
>>than what it was told to do.  Doing so = is a major design error.
>>Nothing less.

Paul is obviously correct.  Therefore does anyone = know of a third party
package for Windows 2000 similar to the ones for NT = 4.0 which does provide
the security it is configured to provide without = going behind your back to
reduce security (hiding a message in an obscure = logfile is not acceptable)?

Any chance of a fix from Microsoft?

michael

------_=_NextPart_001_01BFBC66.95F8757C-- From owner-ipsec@lists.tislabs.com Fri May 12 18:59:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16229; Fri, 12 May 2000 18:59:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA27014 Fri, 12 May 2000 20:51:33 -0400 (EDT) Message-ID: <391CA973.8D2BD1BE@storm.ca> Date: Fri, 12 May 2000 21:01:39 -0400 From: Sandy Harris X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Chun Ye CC: Sumi Singh , ipsec@lists.tislabs.com Subject: Re: Win2000 IKE and 3des References: <19398D273324D3118A2B0008C7E9A56913554D@SIT.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Chun Ye wrote: > > This is not a design error. No, that is far too mild a term for it. > If you have an export driver, how can you expect to run 3DES? If I have a policy that says 3DES, how can you deliver DES? At least one court: http://www.thestandard.net/article/display/0,1151,1780,00.html has held a bank liable for using DES, described by the judge as "out-of-date and not safe enough". If Microsoft software changes the policy the system admin sets, who is liable for any damage? > >>>>> "Sumi" == Sumi Singh writes: > > Sumi> Just to clarify the behaviour of Windows 2000 - Windows 2000 > Sumi> weakens 3DES policy to DES if you do not have the strong > Sumi> encryption pack (128-bit) installed. This weakening is > Sumi> announced by an event in the Audit log. So if you have 2 peers > Sumi> with no encryption pack installed, and a policy to use 3DES, > Sumi> they will talk DES since they cannot do 3DES. > > Clearly that's a major design error. > > If you ask for something that's not supported, it should be rejected. > To change it (even with a message in some obscure log) is clearly > wrong. You don't build secure systems that way. Even with an audible alarm and a message in two inch red letters on the console, it is clearly wrong. From owner-ipsec@lists.tislabs.com Sat May 13 01:00:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA16595; Sat, 13 May 2000 01:00:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01078 Sat, 13 May 2000 02:52:19 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 12 May 2000 23:58:36 -0700 (PDT) From: Jan Vilhuber To: Stephen Kent cc: Shekhar Kshirsagar , ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 12 May 2000, Stephen Kent wrote: > Shekhar, > > >I can understand the waste of bandwidth by L2TP. > >But, can you please elaborate more on how does L2TP interfere > >with the access controls? > > IPsec includes access controls analogous to those of a stateless, > packet filtering firewall. The receiver knows the SA to which each > packet is cryptographically bound, thus it can match the packet > headers (selectors) against those that were negotiated for the SA in > question. If a packet arrives over a tunnel mode SA, the receiving > IPsec implementation checks the inner IP (and transport layer) > header, while in transport mode, the outer IP header (and the inner > transport header). When L2TP is used with IPsec, the L2TP spec calls > for transport mode SAs, which means that only the outer IP header is > checked. Thus the tunneled IP packet is not checked for access > contorl purposes by IPsec. > > Once a packet leaves the IPsec environment, this binding to an SA is > lost (unless some non-standard mechanisms are employed to maintain > the binding). So the best that a separate firewall can do is to match > the packet against its filter list to see if it matches ANY filter > rule. This is much less secure. > But no less usefull. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Sat May 13 01:00:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA16596; Sat, 13 May 2000 01:00:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01072 Sat, 13 May 2000 02:51:05 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Fri, 12 May 2000 23:57:24 -0700 (PDT) From: Jan Vilhuber To: Sandy Harris cc: Chun Ye , Sumi Singh , ipsec@lists.tislabs.com Subject: Re: Win2000 IKE and 3des In-Reply-To: <391CA973.8D2BD1BE@storm.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sounds to me like a CERT advisory is warranted. And wide press coverage. Of all the stupid..... jan On Fri, 12 May 2000, Sandy Harris wrote: > > Chun Ye wrote: > > > > This is not a design error. > > No, that is far too mild a term for it. > > > If you have an export driver, how can you expect to run 3DES? > > If I have a policy that says 3DES, how can you deliver DES? > > At least one court: > > http://www.thestandard.net/article/display/0,1151,1780,00.html > > has held a bank liable for using DES, described by the judge as > "out-of-date and not safe enough". If Microsoft software changes > the policy the system admin sets, who is liable for any damage? > > > >>>>> "Sumi" == Sumi Singh writes: > > > > Sumi> Just to clarify the behaviour of Windows 2000 - Windows 2000 > > Sumi> weakens 3DES policy to DES if you do not have the strong > > Sumi> encryption pack (128-bit) installed. This weakening is > > Sumi> announced by an event in the Audit log. So if you have 2 peers > > Sumi> with no encryption pack installed, and a policy to use 3DES, > > Sumi> they will talk DES since they cannot do 3DES. > > > > Clearly that's a major design error. > > > > If you ask for something that's not supported, it should be rejected. > > To change it (even with a message in some obscure log) is clearly > > wrong. You don't build secure systems that way. > > Even with an audible alarm and a message in two inch red letters on > the console, it is clearly wrong. > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Sat May 13 11:07:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08582; Sat, 13 May 2000 11:07:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02659 Sat, 13 May 2000 12:53:30 -0400 (EDT) Message-ID: <391D8B42.8A28DBDB@cisco.com> Date: Sat, 13 May 2000 19:05:06 +0200 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sumi Singh CC: wprice@cyphers.net, Sami Vaarala , ipsec@lists.tislabs.com Subject: Re: Win2000 IKE and 3des References: <6A05D00595BE644E9F435BE5947423F2BB557F@fifi.platinum.corp.microsoft.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Honestly, this is well worth a bugtrack notification. The interface should not let you configure 3DES if you can not; not post an obscure event that no one hardly sees (the proof being that nobody saw it here). (and Thanks for the hint about the domestic versions; good to know). Regards, Frederic > Sumi Singh wrote: > > Just to clarify the behaviour of Windows 2000 - > Windows 2000 weakens 3DES policy to DES if you do not have the strong encryption pack (128-bit) installed. This weakening is announced by an event in the Audit log. So if you have 2 peers with no encryption pack installed, and a policy to use 3DES, they will talk DES since they cannot do 3DES. > > However if one of the peers has high encryption pack installed and his policy has 3DES only, then he will not accept DES from the other peer and the negotiation will fail. > > For dometic versions you can install the strong crypto pack for doing 3DES from http://www.microsoft.com/windows2000/downloads/recommended/encryption/default.asp > > Sumi. > -----Original Message----- > From: Frédéric Detienne [mailto:fd@cisco.com] > Sent: Friday, May 12, 2000 12:56 AM > To: wprice@cyphers.net > Cc: Sami Vaarala; ipsec@lists.tislabs.com > Subject: Re: Win2000 IKE and 3des > > I fully agree. > > Actually, it is not so silent. The first time it does so, Windows posts an event to the event log. But it took me a while to figure it out the first time as the event log is not very handy to debug. > > This is really nasty to me. Especially if you run IPSec between two Win2K boxes => negociation will succeed but you may never notice it is DES instead of 3DES. > > I noticed the issue when negociating against a Cisco router. > > Actually, Win2K will negociate DES instead of 3DES on non US registered releases only (at least). There seem to be a strong encryption version of Win2K (license ?). > > fred > > Will Price wrote: > > > > This sounds fairly serious to me. > > > > Perhaps this should be posted to BugTraq. This needs confirmation. I > > thought I saw something like this when I was doing my tests against Win2K, > > but it's been quite some time since then. > > > > Sami Vaarala wrote: > > > >Are both of you saying that if you set your policy for 3-DES ONLY (not >3-DES prefered but 3-DES only) that Windows 2000 will negotiate DES >anyway? > > > > > > > Yes, that seems to be the case. I have only checked that if I configure > > > 3des, it will send des as an initiator, and a phase 1 SA with des will > > > be formed (if the remote end accepts des). Haven't checked if it works > > > this way as a responder; probably will. > > > > > > >Or are you saying that Windows 2000 will fall back from 3-DES to DES if >your configured policy lets it do so and the peer doesn't support >3-DES? > > > > > > > No. This would be the correct way to function, and there would not be > > > an issue if this were the case. > > > > > > >The former is a bug which I've not seen in Windows 2000. The latter is > > > >expected behavior since you configured it to do so. > > > > > > My point exactly. The latter behavior would be the one I would prefer > > > to see, of course. > > > > -- > > Will Price, Director of Engineering > > PGP Security, Inc. > > a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Sat May 13 13:41:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10320; Sat, 13 May 2000 13:41:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03168 Sat, 13 May 2000 15:34:40 -0400 (EDT) Message-Id: <200005131939.MAA00981@potassium.network-alchemy.com> To: "Chun Ye" cc: "Paul Koning" , "Sumi Singh" , ipsec@lists.tislabs.com Subject: Re: Win2000 IKE and 3des In-reply-to: Your message of "Fri, 12 May 2000 14:02:13 PDT." <19398D273324D3118A2B0008C7E9A56913554D@SIT.platinum.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <978.958246739.1@network-alchemy.com> Date: Sat, 13 May 2000 12:39:00 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I guess it's not a "design error" if you intended to design it that way but it's still a major problem because you're fooling people into thinking they're getting something they're not. Imagine designing a car that way-- it says there's an airbag but it's not really there, the ABS system only works if you get the upgrade pack even though the idiot light comes on signalling a properly working system, et cetera. Here's an idea: Don't allow configuration of 3DES if they have the export driver. Dan. On Fri, 12 May 2000 14:02:13 PDT you wrote > > This is not a design error. If you have an export driver, how can you > expect to run 3DES? > > Now why we can't reject it. Envision you are running a world-wide > corporation where domain-based policies are assigned to clients at > different sites at different counties. Some of them run the export > version of Win2K. Since it is near impossible to know what version of > Win2K clients are running, so all clients policies are set to use 3DES. > On the corp-side, some servers will be configured to accept 3DES only > and others both DES and 3DES. If you don't weaken 3DES on the export > clients, there is no way to talk to servers with DES configured. > > Having said that, the report mechanism should probably be improved and > we will address this in the next release.=20 > > --Chun > > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: Friday, May 12, 2000 1:24 PM > To: Sumi Singh > Cc: ipsec@lists.tislabs.com > Subject: RE: Win2000 IKE and 3des > > > >>>>> "Sumi" =3D=3D Sumi Singh writes: > > Sumi> Just to clarify the behaviour of Windows 2000 - Windows 2000 > Sumi> weakens 3DES policy to DES if you do not have the strong > Sumi> encryption pack (128-bit) installed. This weakening is > Sumi> announced by an event in the Audit log. So if you have 2 peers > Sumi> with no encryption pack installed, and a policy to use 3DES, > Sumi> they will talk DES since they cannot do 3DES. > > Clearly that's a major design error. > > If you ask for something that's not supported, it should be rejected. > To change it (even with a message in some obscure log) is clearly > wrong. You don't build secure systems that way. > > paul > > ------_=_NextPart_001_01BFBC55.58D2F2C8 > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Dus-ascii"> > 6.0.4366.0"> > RE: Win2000 IKE and 3des > > > > >

This is not a design error.  If you have an = > export driver, how can you expect to run 3DES? >

> >

Now why we can't reject it.  Envision you are = > running a world-wide corporation where domain-based policies are = > assigned to clients at different sites at different counties.  Some = > of them run the export version of Win2K.  Since it is near = > impossible to know what version of Win2K clients are running, so all = > clients policies are set to use 3DES.  On the corp-side, some = > servers will be configured to accept 3DES only and others both DES and = > 3DES.  If you don't weaken 3DES on the export clients, there is no = > way to talk to servers with DES configured.

> >

Having said that, the report mechanism should probably = > be improved and we will address this in the next release. >

> >

--Chun >

> >

-----Original Message----- > >
From: Paul Koning [ HREF=3D"mailto:pkoning@xedia.com">mailto:pkoning@xedia.com] > >
Sent: Friday, May 12, 2000 1:24 PM > >
To: Sumi Singh > >
Cc: ipsec@lists.tislabs.com > >
Subject: RE: Win2000 IKE and 3des >

>
> >

>>>>> "Sumi" =3D=3D Sumi = > Singh <sumis@Exchange.Microsoft.com> writes: >

> >

 Sumi> Just to clarify the behaviour of = > Windows 2000 - Windows 2000 > >
 Sumi> weakens 3DES policy to DES if you do = > not have the strong > >
 Sumi> encryption pack (128-bit) installed. = > This weakening is > >
 Sumi> announced by an event in the Audit = > log. So if you have 2 peers > >
 Sumi> with no encryption pack installed, and = > a policy to use 3DES, > >
 Sumi> they will talk DES since they cannot = > do 3DES. >

> >

Clearly that's a major design error. >

> >

If you ask for something that's not supported, it = > should be rejected. > >
To change it (even with a message in some obscure = > log) is clearly > >
wrong.  You don't build secure systems that = > way. >

> >

        paul >

> > > > ------_=_NextPart_001_01BFBC55.58D2F2C8-- From owner-ipsec@lists.tislabs.com Sun May 14 09:37:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11974; Sun, 14 May 2000 09:37:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04935 Sun, 14 May 2000 11:22:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Sun, 14 May 2000 11:30:18 -0400 To: Jan Vilhuber From: Stephen Kent Subject: RE: Windows 2000 and Cicsco router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:58 PM -0700 5/12/00, Jan Vilhuber wrote: >On Fri, 12 May 2000, Stephen Kent wrote: > > Shekhar, > > > > >I can understand the waste of bandwidth by L2TP. > > >But, can you please elaborate more on how does L2TP interfere > > >with the access controls? > > > > IPsec includes access controls analogous to those of a stateless, > > packet filtering firewall. The receiver knows the SA to which each > > packet is cryptographically bound, thus it can match the packet > > headers (selectors) against those that were negotiated for the SA in > > question. If a packet arrives over a tunnel mode SA, the receiving > > IPsec implementation checks the inner IP (and transport layer) > > header, while in transport mode, the outer IP header (and the inner > > transport header). When L2TP is used with IPsec, the L2TP spec calls > > for transport mode SAs, which means that only the outer IP header is > > checked. Thus the tunneled IP packet is not checked for access > > contorl purposes by IPsec. > > > > Once a packet leaves the IPsec environment, this binding to an SA is > > lost (unless some non-standard mechanisms are employed to maintain > > the binding). So the best that a separate firewall can do is to match > > the packet against its filter list to see if it matches ANY filter > > rule. This is much less secure. > > >But no less usefull. > >jan > -- >Jan Vilhuber vilhuber@cisco.com >Cisco Systems, San Jose (408) 527-0847 If reduced security in a context that focuses on security (else why use IPsec at all?) is considered equivalent, then maybe we all need to revisit the goals of these protocols. Steve From owner-ipsec@lists.tislabs.com Sun May 14 12:39:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13991; Sun, 14 May 2000 12:39:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05446 Sun, 14 May 2000 14:34:42 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Sun, 14 May 2000 11:41:02 -0700 (PDT) From: Jan Vilhuber To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In some people's minds, it's an acceptable trade-off, and others wil think differently. Personally, I don't see much difference with doing a check after decryption and decapsulation, than doing it before. Yes, you may loose some context, but so what. You can either burden IKE and IPSEC with a whole bunch more mechanisms for user-authentication, authorization, and accounting, thus making the protocols even MORE complex (and thus less likely to be completely understood and analyzed for weaknesses), OR you can combine two simple (relatively) mechanisms, and combine them. In fact, it precisely because I DON'T want to revisit these protocols, that I'm advocating l2tp+ipsec. The loss of security you claim exists there, I don't see. jan On Sun, 14 May 2000, Stephen Kent wrote: > At 11:58 PM -0700 5/12/00, Jan Vilhuber wrote: > >On Fri, 12 May 2000, Stephen Kent wrote: > > > Shekhar, > > > > > > >I can understand the waste of bandwidth by L2TP. > > > >But, can you please elaborate more on how does L2TP interfere > > > >with the access controls? > > > > > > IPsec includes access controls analogous to those of a stateless, > > > packet filtering firewall. The receiver knows the SA to which each > > > packet is cryptographically bound, thus it can match the packet > > > headers (selectors) against those that were negotiated for the SA in > > > question. If a packet arrives over a tunnel mode SA, the receiving > > > IPsec implementation checks the inner IP (and transport layer) > > > header, while in transport mode, the outer IP header (and the inner > > > transport header). When L2TP is used with IPsec, the L2TP spec calls > > > for transport mode SAs, which means that only the outer IP header is > > > checked. Thus the tunneled IP packet is not checked for access > > > contorl purposes by IPsec. > > > > > > Once a packet leaves the IPsec environment, this binding to an SA is > > > lost (unless some non-standard mechanisms are employed to maintain > > > the binding). So the best that a separate firewall can do is to match > > > the packet against its filter list to see if it matches ANY filter > > > rule. This is much less secure. > > > > >But no less usefull. > > > >jan > > -- > >Jan Vilhuber vilhuber@cisco.com > >Cisco Systems, San Jose (408) 527-0847 > > If reduced security in a context that focuses on security (else why > use IPsec at all?) is considered equivalent, then maybe we all need > to revisit the goals of these protocols. > > Steve > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Sun May 14 23:49:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA13133; Sun, 14 May 2000 23:49:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA06670 Mon, 15 May 2000 01:34:50 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Paul Koning Cc: sumis@Exchange.Microsoft.com, ipsec@lists.tislabs.com Subject: Re: Win2000 IKE and 3des Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 May 2000 20:12:01 -0400 Message-Id: <20000515001201.64E9C35DC7@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <14620.26714.300239.321461@xedia.com>, Paul Koning writes: >>>>>> "Sumi" == Sumi Singh writes: > > Sumi> Just to clarify the behaviour of Windows 2000 - Windows 2000 > Sumi> weakens 3DES policy to DES if you do not have the strong > Sumi> encryption pack (128-bit) installed. This weakening is > Sumi> announced by an event in the Audit log. So if you have 2 peers > Sumi> with no encryption pack installed, and a policy to use 3DES, > Sumi> they will talk DES since they cannot do 3DES. > >Clearly that's a major design error. > >If you ask for something that's not supported, it should be rejected. >To change it (even with a message in some obscure log) is clearly >wrong. You don't build secure systems that way. Absolutely. If you can't handle a requested security policy, say so, but don't lie to the application. This is *seriously* brain-damaged. I've given up expecting good software design from Microsoft (actually, from most vendors), since they (and everyone else) are far too arrogant about their abilities to design and write error-free code, but this goes above and beyond the call of duty. Users who request 3DES do so because (rightly or wrongly) they perceive a threat model that DES can't counter. Why is their reasoning invalide? Certainly, they may decide to use DES instead of being unable to communicate, but surely that's their decision, not Microsoft's? Tell me, what do you do if the exportable end system is old and doesn't even support DES? Use 40-bit toys? Send authenticated plaintext? I'm glad to hear that this fatally flawed decision will be fixed. But it's not a simple upgrade; it's a glaring bug by the design team (as opposed to the coding team), and should be treated as such, with an immediate fix and corresponding public announcement. --Steve Bellovin From owner-ipsec@lists.tislabs.com Sun May 14 23:51:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA13171; Sun, 14 May 2000 23:51:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA06692 Mon, 15 May 2000 01:44:25 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "CHINNA N.R. PELLACURU" Cc: Jan Vilhuber , Will Price , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 May 2000 01:51:08 -0400 Message-Id: <20000515055113.C414C35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "CHINNA N.R. PELLACURU" writes: >I think there was a decision made at the recent IETF meeting that anything >that modifies IKE will be dealt in the IPSec WG, and that is the reason >why Xauth/Modeconfig are not on the agenda of IPSRA. > >I guess, this is the right place to have this discussion. Not quite. The IPSRA working group has to decide if such changes are needed for remote access. If and only if that group makes such a decision will the IPsec group figure out just how to do it. --Steve Bellovin From owner-ipsec@lists.tislabs.com Mon May 15 02:45:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA15724; Mon, 15 May 2000 02:45:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA07266 Mon, 15 May 2000 04:37:31 -0400 (EDT) Message-ID: <391FB997.4CCE5446@F-Secure.com> Date: Mon, 15 May 2000 11:47:19 +0300 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "CHINNA N.R. PELLACURU" CC: "Mason, David" , Will Price , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I fail to understand your point that the proponents of modeconfig/xauth would be pushing for the paradigm of a "dumb client". A client is no dumber depending on the method used to assign it any specific configuration information like an intranet IP address. In my view the scenario of an average remote user just "powering up his laptop and clicking a few icons" is a good state of affairs. We have a centralized management system that includes modeconfig and distributed firewalling, so those are definitely not contradictory paradigms. I do think IPSec WG should define something to enable protection of multicast traffic. Forcing everyone to use L2TP/IPSec is not a good way, rather it's an effort from some vendors to protect their existing investment, like was already mentioned in here. Ari "CHINNA N.R. PELLACURU" wrote: > > Frankly I like the notion of a personal firewall. I feel empowered, just > by the thought that I have my own personal firewall. I agree with you that > every one should have their personal firewall. > > But, that doesn't really fit into this paradigm of a "dumb client", that > the proponents of modeconfig/xauth are pushing. The client is supposed to > be dumb, and get even it's configuration parameters and phase2 policy, and > if possible it's phase1 policy from the server. The average corporate > executive (road warrior) is supposed to be so dumb that he is not expected > to do anything other than powering up his laptop, and clicking a few > icons. So, we push yet another policy to the client: the firewall policy. > And if the "dumb client" wants to support securing multicast traffic, then > we setup a logical GRE tunnel interface on the client, and push routing > policy onto the client. So, we the client will be a dumb and powerful! > > chinna > > On Fri, 12 May 2000, Mason, David wrote: > > > Every client should have a personal firewall regardless of > > whether it's PPP+L2TP+IPSEC+IKE or just IPSEC+(MODECFG+IKE) > > since they'll often be connecting directly to the Internet > > without going through the corporate firewall (no VPN). > > -dave > > > > -----Original Message----- > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > Sent: Thursday, May 11, 2000 10:10 PM > > To: Will Price > > Cc: Stephen Kent; ipsec@lists.tislabs.com > > Subject: Re: Windows 2000 and Cicsco router interoperability > > > > > > I guess the bottom line is: > > > > Do you want to understand all the subtilities of AAA and IPCP, and then > > massively hack IKE on an ongoing basis, to incorporate all that, (with > > stuff like open ended exchanges, and on top of that require that every > > client need a "personal firewall") > > > > or > > > > Do you want to leverage all the features of AAA and IPCP in a simple > > modular way, and not bother too much about them, and trust them in that > > they do their job well. > > > > Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead? > > > > chinna > > > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > > > Atleast we agree on one thing: we should strive for simplicity. > > > > > > We are essentially talking about adding all the AAA and IPCP baggage to > > > IKE. And that you say is simple! > > > > > > On top of that you want each IPSec client to have a "personal firewall" > > > too. I can see why people want to suggest that. > > > > > > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the > > > AAA and IPCP, and let IPSec protect L2TP. > > > > > > L2TP is fully encapsulated in IPSec, and I don't see how that is less > > > secure. > > > > > > I don't see how it is simple to introduce the AAA and IPCP baggage into > > > IKE. How many forms of Authenticataion do you already support. Do you > > > support Authorization and Accounting? How many features of IPCP do you > > > already support? Probably it is simple for you because your customer base > > > needs only a small subset of these features. But, once we open the flood > > > gates, then customers would like to have all the features that they have > > > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on > > > an ongoing basis to add in features. > > > > > > chinna > > > > > > On Thu, 11 May 2000, Will Price wrote: > > > > > > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > > > > but the issue to get back to Stephen's point is that there is a lot of > > > > overhead involved in doing that when the same thing can be accomplished > > > > much more simply (and I hope we all learned that simplicity is job #1 > > here > > > > after reading Bruce's paper) by just using IPsec correctly mixed the > > > > appropriate client side personal firewall and routing as you point out. > > > > > > > > The latest version of our VPN client PGP 7.0 announced this week > > > > implements both of those solutions (centrally managed client side > > > > firewalling and the ability to direct all traffic to the secure gateway) > > > > along with mode-config to accomplish these goals without any of the > > > > overhead involved in trying to merge a complex protocol (L2TP) with > > > > another complex protocol (IKE/IPsec). I can only imagine (and cringe > > at) > > > > the logistics involved in doing a security code review of both of those > > > > together. > > > > > > > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > > > > > And one more benefit of using L2TP/IPSec is, it can support securing > > IP > > > > > multicast traffic, atleast over the vpn link. But if you are using > > native > > > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and > > you > > > > > will need to have atleast GRE to do this. > > > > > > > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > > > > > > > Regarding access control, some customers raised concerns that, if a > > client > > > > > has a VPN link connected to the corporate intranet, and is also > > directly > > > > > connected to the Internet, then they can't enforce the corporate > > firewall > > > > > policy on that client, like they can if the client was actually in the > > > > > intranet. There were also concerns raised that if the client is > > > > > directly connected to the Internet, it could be hacked, and won't be > > able > > > > > to have the same protection that the corporate firewall provides. > > > > > > > > > > There are atleast two ways of dealing with this: > > > > > > > > > > 1. put an equalent of the corporate firewall on the client so that it > > can > > > > > defend itself, and also enforce the corporate firewall policy. > > > > > > > > > > 2. have a very simple policy on the client that says all traffic will > > go > > > > > via the VPN link to the corporate network, and the client will > > accept/send > > > > > nothing else. This would be the true emulation of the Dial-in remote > > > > > access, and this can be acheived naturally using L2TP. > > > > > > > > > > chinna > > > > > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something > > to > > > > > > >work, and get something to customers, until there is a client that > > can do > > > > > > >IPSec and L2TP. > > > > > > > > > > > > > >I beleive that it is not our long term vision, to ship > > Modeconfig/Xauth. I > > > > > > >beleive that Cisco's long term goal is to follow whatever is > > standardized > > > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to > > solve. > > > > > > > > > > > > > > > > > > > That's one view. > > > > > > > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > > > > Microsoft & Cisco to preserve a joint development investment in > > L2TP, > > > > > > irrespective of its technical merit in this context :-). If I am > > > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > > > > then the extra headers introduced by L2TP are not only wasteful of > > > > > > bandwidth on a continuing basis, but they also interfere with the > > > > > > access controls that are an essential part of IPsec. One needs some > > > > > > means of dealing with bind time connection parameters, but use of > > > > > > L2TP on a continuing basis is an expensive means of achieving this > > > > > > goal. > > > > > > > > > > > > -- > > > > Will Price, Director of Engineering > > > > PGP Security, Inc. > > > > a division of Network Associates, Inc. > > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > chinna narasimha reddy pellacuru > s/w engineer -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon May 15 04:58:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA19677; Mon, 15 May 2000 04:58:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA07647 Mon, 15 May 2000 06:57:19 -0400 (EDT) Message-ID: <391FDB28.D3FB2850@krdl.org.sg> Date: Mon, 15 May 2000 19:10:32 +0800 From: Qiu Ying X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: generate certificate in Win2K Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, How to generate a pair of keys and certificates in Window 2000 for IKE? Thanks? From owner-ipsec@lists.tislabs.com Mon May 15 04:58:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA19678; Mon, 15 May 2000 04:58:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA07583 Mon, 15 May 2000 06:35:53 -0400 (EDT) Message-ID: <391FD622.EE88778C@krdl.org.sg> Date: Mon, 15 May 2000 18:49:06 +0800 From: Qiu Ying X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: generate certificate in Win2K Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, How to generate a pair of keys and certificates in Window 2000 for IKE? Thanks? From owner-ipsec@lists.tislabs.com Mon May 15 06:45:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA21686; Mon, 15 May 2000 06:45:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07831 Mon, 15 May 2000 08:27:28 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D280C5@new-exc1.ctron.com> From: "Waters, Stephen" To: Ari Huttunen Cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Mon, 15 May 2000 13:34:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We could have something fairly crude for this : just 'I want multicast please'. Typically, we negotiate IPSEC clients to have wide-open access (dest 0.0.0.0) and explicit src (the address assigned to the client). If further access control is needed, we use secondary access filters under the direction of the policy. The intent of a wide-open policy is to connect the remote worker as if they were in the office. Surely this should include the use of multicast services. Regards, Steve. -----Original Message----- From: Ari Huttunen [mailto:Ari.Huttunen@F-Secure.com] Sent: Monday, May 15, 2000 9:47 AM To: CHINNA N.R. PELLACURU Cc: Mason, David; Will Price; Stephen Kent; ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability I fail to understand your point that the proponents of modeconfig/xauth would be pushing for the paradigm of a "dumb client". A client is no dumber depending on the method used to assign it any specific configuration information like an intranet IP address. In my view the scenario of an average remote user just "powering up his laptop and clicking a few icons" is a good state of affairs. We have a centralized management system that includes modeconfig and distributed firewalling, so those are definitely not contradictory paradigms. I do think IPSec WG should define something to enable protection of multicast traffic. Forcing everyone to use L2TP/IPSec is not a good way, rather it's an effort from some vendors to protect their existing investment, like was already mentioned in here. Ari "CHINNA N.R. PELLACURU" wrote: > > Frankly I like the notion of a personal firewall. I feel empowered, just > by the thought that I have my own personal firewall. I agree with you that > every one should have their personal firewall. > > But, that doesn't really fit into this paradigm of a "dumb client", that > the proponents of modeconfig/xauth are pushing. The client is supposed to > be dumb, and get even it's configuration parameters and phase2 policy, and > if possible it's phase1 policy from the server. The average corporate > executive (road warrior) is supposed to be so dumb that he is not expected > to do anything other than powering up his laptop, and clicking a few > icons. So, we push yet another policy to the client: the firewall policy. > And if the "dumb client" wants to support securing multicast traffic, then > we setup a logical GRE tunnel interface on the client, and push routing > policy onto the client. So, we the client will be a dumb and powerful! > > chinna > > On Fri, 12 May 2000, Mason, David wrote: > > > Every client should have a personal firewall regardless of > > whether it's PPP+L2TP+IPSEC+IKE or just IPSEC+(MODECFG+IKE) > > since they'll often be connecting directly to the Internet > > without going through the corporate firewall (no VPN). > > -dave > > > > -----Original Message----- > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > Sent: Thursday, May 11, 2000 10:10 PM > > To: Will Price > > Cc: Stephen Kent; ipsec@lists.tislabs.com > > Subject: Re: Windows 2000 and Cicsco router interoperability > > > > > > I guess the bottom line is: > > > > Do you want to understand all the subtilities of AAA and IPCP, and then > > massively hack IKE on an ongoing basis, to incorporate all that, (with > > stuff like open ended exchanges, and on top of that require that every > > client need a "personal firewall") > > > > or > > > > Do you want to leverage all the features of AAA and IPCP in a simple > > modular way, and not bother too much about them, and trust them in that > > they do their job well. > > > > Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead? > > > > chinna > > > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > > > Atleast we agree on one thing: we should strive for simplicity. > > > > > > We are essentially talking about adding all the AAA and IPCP baggage to > > > IKE. And that you say is simple! > > > > > > On top of that you want each IPSec client to have a "personal firewall" > > > too. I can see why people want to suggest that. > > > > > > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the > > > AAA and IPCP, and let IPSec protect L2TP. > > > > > > L2TP is fully encapsulated in IPSec, and I don't see how that is less > > > secure. > > > > > > I don't see how it is simple to introduce the AAA and IPCP baggage into > > > IKE. How many forms of Authenticataion do you already support. Do you > > > support Authorization and Accounting? How many features of IPCP do you > > > already support? Probably it is simple for you because your customer base > > > needs only a small subset of these features. But, once we open the flood > > > gates, then customers would like to have all the features that they have > > > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on > > > an ongoing basis to add in features. > > > > > > chinna > > > > > > On Thu, 11 May 2000, Will Price wrote: > > > > > > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > > > > but the issue to get back to Stephen's point is that there is a lot of > > > > overhead involved in doing that when the same thing can be accomplished > > > > much more simply (and I hope we all learned that simplicity is job #1 > > here > > > > after reading Bruce's paper) by just using IPsec correctly mixed the > > > > appropriate client side personal firewall and routing as you point out. > > > > > > > > The latest version of our VPN client PGP 7.0 announced this week > > > > implements both of those solutions (centrally managed client side > > > > firewalling and the ability to direct all traffic to the secure gateway) > > > > along with mode-config to accomplish these goals without any of the > > > > overhead involved in trying to merge a complex protocol (L2TP) with > > > > another complex protocol (IKE/IPsec). I can only imagine (and cringe > > at) > > > > the logistics involved in doing a security code review of both of those > > > > together. > > > > > > > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > > > > > And one more benefit of using L2TP/IPSec is, it can support securing > > IP > > > > > multicast traffic, atleast over the vpn link. But if you are using > > native > > > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and > > you > > > > > will need to have atleast GRE to do this. > > > > > > > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > > > > > > > Regarding access control, some customers raised concerns that, if a > > client > > > > > has a VPN link connected to the corporate intranet, and is also > > directly > > > > > connected to the Internet, then they can't enforce the corporate > > firewall > > > > > policy on that client, like they can if the client was actually in the > > > > > intranet. There were also concerns raised that if the client is > > > > > directly connected to the Internet, it could be hacked, and won't be > > able > > > > > to have the same protection that the corporate firewall provides. > > > > > > > > > > There are atleast two ways of dealing with this: > > > > > > > > > > 1. put an equalent of the corporate firewall on the client so that it > > can > > > > > defend itself, and also enforce the corporate firewall policy. > > > > > > > > > > 2. have a very simple policy on the client that says all traffic will > > go > > > > > via the VPN link to the corporate network, and the client will > > accept/send > > > > > nothing else. This would be the true emulation of the Dial-in remote > > > > > access, and this can be acheived naturally using L2TP. > > > > > > > > > > chinna > > > > > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something > > to > > > > > > >work, and get something to customers, until there is a client that > > can do > > > > > > >IPSec and L2TP. > > > > > > > > > > > > > >I beleive that it is not our long term vision, to ship > > Modeconfig/Xauth. I > > > > > > >beleive that Cisco's long term goal is to follow whatever is > > standardized > > > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to > > solve. > > > > > > > > > > > > > > > > > > > That's one view. > > > > > > > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > > > > Microsoft & Cisco to preserve a joint development investment in > > L2TP, > > > > > > irrespective of its technical merit in this context :-). If I am > > > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > > > > then the extra headers introduced by L2TP are not only wasteful of > > > > > > bandwidth on a continuing basis, but they also interfere with the > > > > > > access controls that are an essential part of IPsec. One needs some > > > > > > means of dealing with bind time connection parameters, but use of > > > > > > L2TP on a continuing basis is an expensive means of achieving this > > > > > > goal. > > > > > > > > > > > > -- > > > > Will Price, Director of Engineering > > > > PGP Security, Inc. > > > > a division of Network Associates, Inc. > > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > chinna narasimha reddy pellacuru > s/w engineer -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Mon May 15 08:46:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23781; Mon, 15 May 2000 08:46:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08163 Mon, 15 May 2000 10:14:13 -0400 (EDT) Message-Id: <200005151424.JAA23915@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "CHINNA N.R. PELLACURU" cc: "Mason, David" , Will Price , Stephen Kent , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: Windows 2000 and Cicsco router interoperability In-reply-to: Your message of "Fri, 12 May 2000 08:30:55 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 May 2000 09:24:19 -0500 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If I was a suitably paranoid IT person who is about to deploy VPN clients, the fact that the each client also had a personal firewall would not be enough to turn my crank. Even if I personally configure each and every client, the capability for my employees to disable or reconfigure said firewalls makes me nervous. What I would like to see is a non-bypassable configuration option whereby when the VPN is enabled, ALL IP traffic goes out over the VPN and is subsequently subjected to our corporate perimeter policy. And all NON Protocol 50/51 traffic is blocked as well as non IP traffic. And while this scheme has certain vulnerabilities as well, it strikes me as less vulnerable. Regards, Michael Carney > Frankly I like the notion of a personal firewall. I feel empowered, just > by the thought that I have my own personal firewall. I agree with you that > every one should have their personal firewall. > > But, that doesn't really fit into this paradigm of a "dumb client", that > the proponents of modeconfig/xauth are pushing. The client is supposed to > be dumb, and get even it's configuration parameters and phase2 policy, and > if possible it's phase1 policy from the server. The average corporate > executive (road warrior) is supposed to be so dumb that he is not expected > to do anything other than powering up his laptop, and clicking a few > icons. So, we push yet another policy to the client: the firewall policy. > And if the "dumb client" wants to support securing multicast traffic, then > we setup a logical GRE tunnel interface on the client, and push routing > policy onto the client. So, we the client will be a dumb and powerful! > > chinna > > On Fri, 12 May 2000, Mason, David wrote: > > > Every client should have a personal firewall regardless of > > whether it's PPP+L2TP+IPSEC+IKE or just IPSEC+(MODECFG+IKE) > > since they'll often be connecting directly to the Internet > > without going through the corporate firewall (no VPN). > > -dave > > > > -----Original Message----- > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > Sent: Thursday, May 11, 2000 10:10 PM > > To: Will Price > > Cc: Stephen Kent; ipsec@lists.tislabs.com > > Subject: Re: Windows 2000 and Cicsco router interoperability > > > > > > I guess the bottom line is: > > > > Do you want to understand all the subtilities of AAA and IPCP, and then > > massively hack IKE on an ongoing basis, to incorporate all that, (with > > stuff like open ended exchanges, and on top of that require that every > > client need a "personal firewall") > > > > or > > > > Do you want to leverage all the features of AAA and IPCP in a simple > > modular way, and not bother too much about them, and trust them in that > > they do their job well. > > > > Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead? > > > > chinna > > > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > > > Atleast we agree on one thing: we should strive for simplicity. > > > > > > We are essentially talking about adding all the AAA and IPCP baggage to > > > IKE. And that you say is simple! > > > > > > On top of that you want each IPSec client to have a "personal firewall" > > > too. I can see why people want to suggest that. > > > > > > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the > > > AAA and IPCP, and let IPSec protect L2TP. > > > > > > L2TP is fully encapsulated in IPSec, and I don't see how that is less > > > secure. > > > > > > I don't see how it is simple to introduce the AAA and IPCP baggage into > > > IKE. How many forms of Authenticataion do you already support. Do you > > > support Authorization and Accounting? How many features of IPCP do you > > > already support? Probably it is simple for you because your customer base > > > needs only a small subset of these features. But, once we open the flood > > > gates, then customers would like to have all the features that they have > > > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on > > > an ongoing basis to add in features. > > > > > > chinna > > > > > > On Thu, 11 May 2000, Will Price wrote: > > > > > > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > > > > but the issue to get back to Stephen's point is that there is a lot of > > > > overhead involved in doing that when the same thing can be accomplished > > > > much more simply (and I hope we all learned that simplicity is job #1 > > here > > > > after reading Bruce's paper) by just using IPsec correctly mixed the > > > > appropriate client side personal firewall and routing as you point out. > > > > > > > > The latest version of our VPN client PGP 7.0 announced this week > > > > implements both of those solutions (centrally managed client side > > > > firewalling and the ability to direct all traffic to the secure gateway) > > > > along with mode-config to accomplish these goals without any of the > > > > overhead involved in trying to merge a complex protocol (L2TP) with > > > > another complex protocol (IKE/IPsec). I can only imagine (and cringe > > at) > > > > the logistics involved in doing a security code review of both of those > > > > together. > > > > > > > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > > > > > And one more benefit of using L2TP/IPSec is, it can support securing > > IP > > > > > multicast traffic, atleast over the vpn link. But if you are using > > native > > > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and > > you > > > > > will need to have atleast GRE to do this. > > > > > > > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > > > > > > > Regarding access control, some customers raised concerns that, if a > > client > > > > > has a VPN link connected to the corporate intranet, and is also > > directly > > > > > connected to the Internet, then they can't enforce the corporate > > firewall > > > > > policy on that client, like they can if the client was actually in the > > > > > intranet. There were also concerns raised that if the client is > > > > > directly connected to the Internet, it could be hacked, and won't be > > able > > > > > to have the same protection that the corporate firewall provides. > > > > > > > > > > There are atleast two ways of dealing with this: > > > > > > > > > > 1. put an equalent of the corporate firewall on the client so that it > > can > > > > > defend itself, and also enforce the corporate firewall policy. > > > > > > > > > > 2. have a very simple policy on the client that says all traffic will > > go > > > > > via the VPN link to the corporate network, and the client will > > accept/send > > > > > nothing else. This would be the true emulation of the Dial-in remote > > > > > access, and this can be acheived naturally using L2TP. > > > > > > > > > > chinna > > > > > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something > > to > > > > > > >work, and get something to customers, until there is a client that > > can do > > > > > > >IPSec and L2TP. > > > > > > > > > > > > > >I beleive that it is not our long term vision, to ship > > Modeconfig/Xauth. I > > > > > > >beleive that Cisco's long term goal is to follow whatever is > > standardized > > > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to > > solve. > > > > > > > > > > > > > > > > > > > That's one view. > > > > > > > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > > > > Microsoft & Cisco to preserve a joint development investment in > > L2TP, > > > > > > irrespective of its technical merit in this context :-). If I am > > > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > > > > then the extra headers introduced by L2TP are not only wasteful of > > > > > > bandwidth on a continuing basis, but they also interfere with the > > > > > > access controls that are an essential part of IPsec. One needs some > > > > > > means of dealing with bind time connection parameters, but use of > > > > > > L2TP on a continuing basis is an expensive means of achieving this > > > > > > goal. > > > > > > > > > > > > -- > > > > Will Price, Director of Engineering > > > > PGP Security, Inc. > > > > a division of Network Associates, Inc. > > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > chinna narasimha reddy pellacuru > s/w engineer > From owner-ipsec@lists.tislabs.com Mon May 15 08:46:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23792; Mon, 15 May 2000 08:46:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08187 Mon, 15 May 2000 10:20:54 -0400 (EDT) Message-Id: <200005151431.JAA23932@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: "Chun Ye" cc: "Paul Koning" , "Sumi Singh" , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: Win2000 IKE and 3des In-reply-to: Your message of "Fri, 12 May 2000 14:02:13 PDT." <19398D273324D3118A2B0008C7E9A56913554D@SIT.platinum.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 May 2000 09:31:48 -0500 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > This is not a design error. If you have an export driver, how can you > expect to run 3DES? You can't. > > Now why we can't reject it. Envision you are running a world-wide > corporation where domain-based policies are assigned to clients at > different sites at different counties. Some of them run the export > version of Win2K. Since it is near impossible to know what version of > Win2K clients are running, so all clients policies are set to use 3DES. > On the corp-side, some servers will be configured to accept 3DES only > and others both DES and 3DES. If you don't weaken 3DES on the export > clients, there is no way to talk to servers with DES configured. Then you need to have configuration option allows the administrator to configure 3DES and DES or 3DES only. > > Having said that, the report mechanism should probably be improved and > we will address this in the next release.=20 Sorry Chun, I see the problem you are trying to address, but I don't agree with your solution. Regards, Michael Carney > > --Chun > > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: Friday, May 12, 2000 1:24 PM > To: Sumi Singh > Cc: ipsec@lists.tislabs.com > Subject: RE: Win2000 IKE and 3des > > > >>>>> "Sumi" =3D=3D Sumi Singh writes: > > Sumi> Just to clarify the behaviour of Windows 2000 - Windows 2000 > Sumi> weakens 3DES policy to DES if you do not have the strong > Sumi> encryption pack (128-bit) installed. This weakening is > Sumi> announced by an event in the Audit log. So if you have 2 peers > Sumi> with no encryption pack installed, and a policy to use 3DES, > Sumi> they will talk DES since they cannot do 3DES. > > Clearly that's a major design error. > > If you ask for something that's not supported, it should be rejected. > To change it (even with a message in some obscure log) is clearly > wrong. You don't build secure systems that way. > > paul > > ------_=_NextPart_001_01BFBC55.58D2F2C8 > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Dus-ascii"> > 6.0.4366.0"> > RE: Win2000 IKE and 3des > > > > >

This is not a design error.  If you have an = > export driver, how can you expect to run 3DES? >

> >

Now why we can't reject it.  Envision you are = > running a world-wide corporation where domain-based policies are = > assigned to clients at different sites at different counties.  Some = > of them run the export version of Win2K.  Since it is near = > impossible to know what version of Win2K clients are running, so all = > clients policies are set to use 3DES.  On the corp-side, some = > servers will be configured to accept 3DES only and others both DES and = > 3DES.  If you don't weaken 3DES on the export clients, there is no = > way to talk to servers with DES configured.

> >

Having said that, the report mechanism should probably = > be improved and we will address this in the next release. >

> >

--Chun >

> >

-----Original Message----- > >
From: Paul Koning [ HREF=3D"mailto:pkoning@xedia.com">mailto:pkoning@xedia.com] > >
Sent: Friday, May 12, 2000 1:24 PM > >
To: Sumi Singh > >
Cc: ipsec@lists.tislabs.com > >
Subject: RE: Win2000 IKE and 3des >

>
> >

>>>>> "Sumi" =3D=3D Sumi = > Singh <sumis@Exchange.Microsoft.com> writes: >

> >

 Sumi> Just to clarify the behaviour of = > Windows 2000 - Windows 2000 > >
 Sumi> weakens 3DES policy to DES if you do = > not have the strong > >
 Sumi> encryption pack (128-bit) installed. = > This weakening is > >
 Sumi> announced by an event in the Audit = > log. So if you have 2 peers > >
 Sumi> with no encryption pack installed, and = > a policy to use 3DES, > >
 Sumi> they will talk DES since they cannot = > do 3DES. >

> >

Clearly that's a major design error. >

> >

If you ask for something that's not supported, it = > should be rejected. > >
To change it (even with a message in some obscure = > log) is clearly > >
wrong.  You don't build secure systems that = > way. >

> >

        paul >

> > > > ------_=_NextPart_001_01BFBC55.58D2F2C8-- From owner-ipsec@lists.tislabs.com Mon May 15 09:13:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24233; Mon, 15 May 2000 09:13:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08312 Mon, 15 May 2000 10:56:04 -0400 (EDT) Message-ID: <3920120D.FC51404B@cyphers.net> Date: Mon, 15 May 2000 08:04:46 -0700 From: "Will Price" Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mike Carney CC: ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: <200005151424.JAA23915@jumpsrv.stp.securecomputing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That would be a good point if it was possible. In the case of PGP 7.0, it isn't. Since the personal firewall and VPN client are one product, you can't uninstall one or the other, they come as a set. Configuration options are handled centrally, and every single option, setting, rule, etc... can be individually locked down by the administrator such that the user is unable to change it. If desired, it can be locked down so hard that the only thing the user can do pretty much is click "Connect", enter their authentication, and suddenly all their IP traffic goes to the VPN gateway. Mike Carney wrote: > > If I was a suitably paranoid IT person who is about to deploy VPN clients, > the fact that the each client also had a personal firewall would not > be enough to turn my crank. Even if I personally configure each and > every client, the capability for my employees to disable or reconfigure > said firewalls makes me nervous. > > What I would like to see is a non-bypassable configuration option > whereby when the VPN is enabled, ALL IP traffic goes out over the > VPN and is subsequently subjected to our corporate perimeter policy. > And all NON Protocol 50/51 traffic is blocked as well as non IP traffic. > > And while this scheme has certain vulnerabilities as well, it strikes > me as less vulnerable. > > Regards, > Michael Carney > > > Frankly I like the notion of a personal firewall. I feel empowered, just > > by the thought that I have my own personal firewall. I agree with you that > > every one should have their personal firewall. > > > > But, that doesn't really fit into this paradigm of a "dumb client", that > > the proponents of modeconfig/xauth are pushing. The client is supposed to > > be dumb, and get even it's configuration parameters and phase2 policy, and > > if possible it's phase1 policy from the server. The average corporate > > executive (road warrior) is supposed to be so dumb that he is not expected > > to do anything other than powering up his laptop, and clicking a few > > icons. So, we push yet another policy to the client: the firewall policy. > > And if the "dumb client" wants to support securing multicast traffic, then > > we setup a logical GRE tunnel interface on the client, and push routing > > policy onto the client. So, we the client will be a dumb and powerful! > > > > chinna > > > > On Fri, 12 May 2000, Mason, David wrote: > > > > > Every client should have a personal firewall regardless of > > > whether it's PPP+L2TP+IPSEC+IKE or just IPSEC+(MODECFG+IKE) > > > since they'll often be connecting directly to the Internet > > > without going through the corporate firewall (no VPN). > > > -dave > > > > > > -----Original Message----- > > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > > Sent: Thursday, May 11, 2000 10:10 PM > > > To: Will Price > > > Cc: Stephen Kent; ipsec@lists.tislabs.com > > > Subject: Re: Windows 2000 and Cicsco router interoperability > > > > > > > > > I guess the bottom line is: > > > > > > Do you want to understand all the subtilities of AAA and IPCP, and then > > > massively hack IKE on an ongoing basis, to incorporate all that, (with > > > stuff like open ended exchanges, and on top of that require that every > > > client need a "personal firewall") > > > > > > or > > > > > > Do you want to leverage all the features of AAA and IPCP in a simple > > > modular way, and not bother too much about them, and trust them in that > > > they do their job well. > > > > > > Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead? > > > > > > chinna > > > > > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > > > > > Atleast we agree on one thing: we should strive for simplicity. > > > > > > > > We are essentially talking about adding all the AAA and IPCP baggage to > > > > IKE. And that you say is simple! > > > > > > > > On top of that you want each IPSec client to have a "personal firewall" > > > > too. I can see why people want to suggest that. > > > > > > > > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the > > > > AAA and IPCP, and let IPSec protect L2TP. > > > > > > > > L2TP is fully encapsulated in IPSec, and I don't see how that is less > > > > secure. > > > > > > > > I don't see how it is simple to introduce the AAA and IPCP baggage into > > > > IKE. How many forms of Authenticataion do you already support. Do you > > > > support Authorization and Accounting? How many features of IPCP do you > > > > already support? Probably it is simple for you because your customer base > > > > needs only a small subset of these features. But, once we open the flood > > > > gates, then customers would like to have all the features that they have > > > > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on > > > > an ongoing basis to add in features. > > > > > > > > chinna > > > > > > > > On Thu, 11 May 2000, Will Price wrote: > > > > > > > > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > > > > > but the issue to get back to Stephen's point is that there is a lot of > > > > > overhead involved in doing that when the same thing can be accomplished > > > > > much more simply (and I hope we all learned that simplicity is job #1 > > > here > > > > > after reading Bruce's paper) by just using IPsec correctly mixed the > > > > > appropriate client side personal firewall and routing as you point out. > > > > > > > > > > The latest version of our VPN client PGP 7.0 announced this week > > > > > implements both of those solutions (centrally managed client side > > > > > firewalling and the ability to direct all traffic to the secure gateway) > > > > > along with mode-config to accomplish these goals without any of the > > > > > overhead involved in trying to merge a complex protocol (L2TP) with > > > > > another complex protocol (IKE/IPsec). I can only imagine (and cringe > > > at) > > > > > the logistics involved in doing a security code review of both of those > > > > > together. > > > > > > > > > > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > > > > > > > And one more benefit of using L2TP/IPSec is, it can support securing > > > IP > > > > > > multicast traffic, atleast over the vpn link. But if you are using > > > native > > > > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and > > > you > > > > > > will need to have atleast GRE to do this. > > > > > > > > > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > > > > > > > > > Regarding access control, some customers raised concerns that, if a > > > client > > > > > > has a VPN link connected to the corporate intranet, and is also > > > directly > > > > > > connected to the Internet, then they can't enforce the corporate > > > firewall > > > > > > policy on that client, like they can if the client was actually in the > > > > > > intranet. There were also concerns raised that if the client is > > > > > > directly connected to the Internet, it could be hacked, and won't be > > > able > > > > > > to have the same protection that the corporate firewall provides. > > > > > > > > > > > > There are atleast two ways of dealing with this: > > > > > > > > > > > > 1. put an equalent of the corporate firewall on the client so that it > > > can > > > > > > defend itself, and also enforce the corporate firewall policy. > > > > > > > > > > > > 2. have a very simple policy on the client that says all traffic will > > > go > > > > > > via the VPN link to the corporate network, and the client will > > > accept/send > > > > > > nothing else. This would be the true emulation of the Dial-in remote > > > > > > access, and this can be acheived naturally using L2TP. > > > > > > > > > > > > chinna > > > > > > > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > > > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something > > > to > > > > > > > >work, and get something to customers, until there is a client that > > > can do > > > > > > > >IPSec and L2TP. > > > > > > > > > > > > > > > >I beleive that it is not our long term vision, to ship > > > Modeconfig/Xauth. I > > > > > > > >beleive that Cisco's long term goal is to follow whatever is > > > standardized > > > > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to > > > solve. > > > > > > > > > > > > > > > > > > > > > > That's one view. > > > > > > > > > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > > > > > Microsoft & Cisco to preserve a joint development investment in > > > L2TP, > > > > > > > irrespective of its technical merit in this context :-). If I am > > > > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > > > > > then the extra headers introduced by L2TP are not only wasteful of > > > > > > > bandwidth on a continuing basis, but they also interfere with the > > > > > > > access controls that are an essential part of IPsec. One needs some > > > > > > > means of dealing with bind time connection parameters, but use of > > > > > > > L2TP on a continuing basis is an expensive means of achieving this > > > > > > > goal. > > > > > > > > > > > > > > > -- > > > > > Will Price, Director of Engineering > > > > > PGP Security, Inc. > > > > > a division of Network Associates, Inc. > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > > s/w engineer > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. Direct (408)346-5906 From owner-ipsec@lists.tislabs.com Mon May 15 09:23:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24461; Mon, 15 May 2000 09:23:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08531 Mon, 15 May 2000 11:02:57 -0400 (EDT) Message-Id: <200005151514.KAA24050@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: wprice@cyphers.net cc: Mike Carney , ipsec@lists.tislabs.com, carney@jumpsrv.stp.securecomputing.com Subject: Re: Windows 2000 and Cicsco router interoperability In-reply-to: Your message of "Mon, 15 May 2000 08:04:46 PDT." <3920120D.FC51404B@cyphers.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 May 2000 10:14:07 -0500 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > That would be a good point if it was possible. In the case of PGP 7.0, it isn't. > > Since the personal firewall and VPN client are one product, you can't > uninstall one or the other, they come as a set. Configuration options are > handled centrally, and every single option, setting, rule, etc... can be > individually locked down by the administrator such that the user is unable > to change it. If desired, it can be locked down so hard that the only > thing the user can do pretty much is click "Connect", enter their > authentication, and suddenly all their IP traffic goes to the VPN gateway. Sounds like a well thought out design and based on your last sentence will do exactly what the paranoid would want it to do. Regards, Michael Carney > > > Mike Carney wrote: > > > > If I was a suitably paranoid IT person who is about to deploy VPN clients, > > the fact that the each client also had a personal firewall would not > > be enough to turn my crank. Even if I personally configure each and > > every client, the capability for my employees to disable or reconfigure > > said firewalls makes me nervous. > > > > What I would like to see is a non-bypassable configuration option > > whereby when the VPN is enabled, ALL IP traffic goes out over the > > VPN and is subsequently subjected to our corporate perimeter policy. > > And all NON Protocol 50/51 traffic is blocked as well as non IP traffic. > > > > And while this scheme has certain vulnerabilities as well, it strikes > > me as less vulnerable. > > > > Regards, > > Michael Carney > > > > > Frankly I like the notion of a personal firewall. I feel empowered, just > > > by the thought that I have my own personal firewall. I agree with you that > > > every one should have their personal firewall. > > > > > > But, that doesn't really fit into this paradigm of a "dumb client", that > > > the proponents of modeconfig/xauth are pushing. The client is supposed to > > > be dumb, and get even it's configuration parameters and phase2 policy, and > > > if possible it's phase1 policy from the server. The average corporate > > > executive (road warrior) is supposed to be so dumb that he is not expected > > > to do anything other than powering up his laptop, and clicking a few > > > icons. So, we push yet another policy to the client: the firewall policy. > > > And if the "dumb client" wants to support securing multicast traffic, then > > > we setup a logical GRE tunnel interface on the client, and push routing > > > policy onto the client. So, we the client will be a dumb and powerful! > > > > > > chinna > > > > > > On Fri, 12 May 2000, Mason, David wrote: > > > > > > > Every client should have a personal firewall regardless of > > > > whether it's PPP+L2TP+IPSEC+IKE or just IPSEC+(MODECFG+IKE) > > > > since they'll often be connecting directly to the Internet > > > > without going through the corporate firewall (no VPN). > > > > -dave > > > > > > > > -----Original Message----- > > > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > > > Sent: Thursday, May 11, 2000 10:10 PM > > > > To: Will Price > > > > Cc: Stephen Kent; ipsec@lists.tislabs.com > > > > Subject: Re: Windows 2000 and Cicsco router interoperability > > > > > > > > > > > > I guess the bottom line is: > > > > > > > > Do you want to understand all the subtilities of AAA and IPCP, and then > > > > massively hack IKE on an ongoing basis, to incorporate all that, (with > > > > stuff like open ended exchanges, and on top of that require that every > > > > client need a "personal firewall") > > > > > > > > or > > > > > > > > Do you want to leverage all the features of AAA and IPCP in a simple > > > > modular way, and not bother too much about them, and trust them in that > > > > they do their job well. > > > > > > > > Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead? > > > > > > > > chinna > > > > > > > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > > > > > > > Atleast we agree on one thing: we should strive for simplicity. > > > > > > > > > > We are essentially talking about adding all the AAA and IPCP baggage to > > > > > IKE. And that you say is simple! > > > > > > > > > > On top of that you want each IPSec client to have a "personal firewall" > > > > > too. I can see why people want to suggest that. > > > > > > > > > > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the > > > > > AAA and IPCP, and let IPSec protect L2TP. > > > > > > > > > > L2TP is fully encapsulated in IPSec, and I don't see how that is less > > > > > secure. > > > > > > > > > > I don't see how it is simple to introduce the AAA and IPCP baggage into > > > > > IKE. How many forms of Authenticataion do you already support. Do you > > > > > support Authorization and Accounting? How many features of IPCP do you > > > > > already support? Probably it is simple for you because your customer base > > > > > needs only a small subset of these features. But, once we open the flood > > > > > gates, then customers would like to have all the features that they have > > > > > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on > > > > > an ongoing basis to add in features. > > > > > > > > > > chinna > > > > > > > > > > On Thu, 11 May 2000, Will Price wrote: > > > > > > > > > > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > > > > > > but the issue to get back to Stephen's point is that there is a lot of > > > > > > overhead involved in doing that when the same thing can be accomplished > > > > > > much more simply (and I hope we all learned that simplicity is job #1 > > > > here > > > > > > after reading Bruce's paper) by just using IPsec correctly mixed the > > > > > > appropriate client side personal firewall and routing as you point out. > > > > > > > > > > > > The latest version of our VPN client PGP 7.0 announced this week > > > > > > implements both of those solutions (centrally managed client side > > > > > > firewalling and the ability to direct all traffic to the secure gateway) > > > > > > along with mode-config to accomplish these goals without any of the > > > > > > overhead involved in trying to merge a complex protocol (L2TP) with > > > > > > another complex protocol (IKE/IPsec). I can only imagine (and cringe > > > > at) > > > > > > the logistics involved in doing a security code review of both of those > > > > > > together. > > > > > > > > > > > > > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > > > > > > > > > And one more benefit of using L2TP/IPSec is, it can support securing > > > > IP > > > > > > > multicast traffic, atleast over the vpn link. But if you are using > > > > native > > > > > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and > > > > you > > > > > > > will need to have atleast GRE to do this. > > > > > > > > > > > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > > > > > > > > > > > Regarding access control, some customers raised concerns that, if a > > > > client > > > > > > > has a VPN link connected to the corporate intranet, and is also > > > > directly > > > > > > > connected to the Internet, then they can't enforce the corporate > > > > firewall > > > > > > > policy on that client, like they can if the client was actually in the > > > > > > > intranet. There were also concerns raised that if the client is > > > > > > > directly connected to the Internet, it could be hacked, and won't be > > > > able > > > > > > > to have the same protection that the corporate firewall provides. > > > > > > > > > > > > > > There are atleast two ways of dealing with this: > > > > > > > > > > > > > > 1. put an equalent of the corporate firewall on the client so that it > > > > can > > > > > > > defend itself, and also enforce the corporate firewall policy. > > > > > > > > > > > > > > 2. have a very simple policy on the client that says all traffic will > > > > go > > > > > > > via the VPN link to the corporate network, and the client will > > > > accept/send > > > > > > > nothing else. This would be the true emulation of the Dial-in remote > > > > > > > access, and this can be acheived naturally using L2TP. > > > > > > > > > > > > > > chinna > > > > > > > > > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > > > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > > > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > > > > > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something > > > > to > > > > > > > > >work, and get something to customers, until there is a client that > > > > can do > > > > > > > > >IPSec and L2TP. > > > > > > > > > > > > > > > > > >I beleive that it is not our long term vision, to ship > > > > Modeconfig/Xauth. I > > > > > > > > >beleive that Cisco's long term goal is to follow whatever is > > > > standardized > > > > > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to > > > > solve. > > > > > > > > > > > > > > > > > > > > > > > > > That's one view. > > > > > > > > > > > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > > > > > > Microsoft & Cisco to preserve a joint development investment in > > > > L2TP, > > > > > > > > irrespective of its technical merit in this context :-). If I am > > > > > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > > > > > > then the extra headers introduced by L2TP are not only wasteful of > > > > > > > > bandwidth on a continuing basis, but they also interfere with the > > > > > > > > access controls that are an essential part of IPsec. One needs some > > > > > > > > means of dealing with bind time connection parameters, but use of > > > > > > > > L2TP on a continuing basis is an expensive means of achieving this > > > > > > > > goal. > > > > > > > > > > > > > > > > > > -- > > > > > > Will Price, Director of Engineering > > > > > > PGP Security, Inc. > > > > > > a division of Network Associates, Inc. > > > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > > > s/w engineer > > > > > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > > s/w engineer > > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > -- > > Will Price, Director of Engineering > PGP Security, Inc. > a division of Network Associates, Inc. > Direct (408)346-5906 From owner-ipsec@lists.tislabs.com Mon May 15 10:24:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28252; Mon, 15 May 2000 10:24:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08955 Mon, 15 May 2000 12:07:02 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Jan Vilhuber'" , "'Stephen Kent'" Cc: Subject: RE: Windows 2000 and Cicsco router interoperability Date: Mon, 15 May 2000 12:11:09 -0400 Message-Id: <000b01bfbe88$2fa49c50$d23e788a@andrewk3.timestep.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: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, Allowing any authorized user to potentially spoof any other authorized user is an acceptable trade-off?!? Sure, it's better than allowing unauthorized users to spoof authorized users, but... This doesn't mean you necessarily have to do firewalling in IPsec. I think Joe Touch's idea of doing IP in IP and passing the context information by reference has a lot of technical merit. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber > Sent: Sunday, May 14, 2000 2:41 PM > To: Stephen Kent > Cc: ipsec@lists.tislabs.com > Subject: RE: Windows 2000 and Cicsco router interoperability > > > In some people's minds, it's an acceptable trade-off, and > others wil think > differently. > > Personally, I don't see much difference with doing a check > after decryption > and decapsulation, than doing it before. Yes, you may loose > some context, but > so what. > > You can either burden IKE and IPSEC with a whole bunch more > mechanisms for > user-authentication, authorization, and accounting, thus > making the protocols > even MORE complex (and thus less likely to be completely > understood and > analyzed for weaknesses), OR you can combine two simple (relatively) > mechanisms, and combine them. In fact, it precisely because I > DON'T want to > revisit these protocols, that I'm advocating l2tp+ipsec. > > The loss of security you claim exists there, I don't see. > > jan > > > On Sun, 14 May 2000, Stephen Kent wrote: > > > At 11:58 PM -0700 5/12/00, Jan Vilhuber wrote: > > >On Fri, 12 May 2000, Stephen Kent wrote: > > > > Shekhar, > > > > > > > > >I can understand the waste of bandwidth by L2TP. > > > > >But, can you please elaborate more on how does L2TP interfere > > > > >with the access controls? > > > > > > > > IPsec includes access controls analogous to those of a > stateless, > > > > packet filtering firewall. The receiver knows the SA > to which each > > > > packet is cryptographically bound, thus it can match the packet > > > > headers (selectors) against those that were negotiated > for the SA in > > > > question. If a packet arrives over a tunnel mode SA, > the receiving > > > > IPsec implementation checks the inner IP (and transport layer) > > > > header, while in transport mode, the outer IP header > (and the inner > > > > transport header). When L2TP is used with IPsec, the > L2TP spec calls > > > > for transport mode SAs, which means that only the > outer IP header is > > > > checked. Thus the tunneled IP packet is not checked for access > > > > contorl purposes by IPsec. > > > > > > > > Once a packet leaves the IPsec environment, this > binding to an SA is > > > > lost (unless some non-standard mechanisms are employed > to maintain > > > > the binding). So the best that a separate firewall can > do is to match > > > > the packet against its filter list to see if it > matches ANY filter > > > > rule. This is much less secure. > > > > > > >But no less usefull. > > > > > >jan > > > -- > > >Jan Vilhuber > vilhuber@cisco.com > > >Cisco Systems, San Jose > (408) 527-0847 > > > > If reduced security in a context that focuses on security (else why > > use IPsec at all?) is considered equivalent, then maybe we all need > > to revisit the goals of these protocols. > > > > Steve > > > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > > From owner-ipsec@lists.tislabs.com Mon May 15 10:24:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28251; Mon, 15 May 2000 10:24:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08971 Mon, 15 May 2000 12:11:19 -0400 (EDT) Message-ID: <3920243C.36689AE4@redcreek.com> Date: Mon, 15 May 2000 09:22:20 -0700 From: "Scott G. Kelly" 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 To: Qiu Ying CC: ipsec@lists.tislabs.com Subject: Re: generate certificate in Win2K References: <391FDB28.D3FB2850@krdl.org.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Qiu Ying wrote: > > Hi, > > How to generate a pair of keys and certificates in Window 2000 for IKE? > > Thanks? Questions like this should be directed to microsoft technical support, rather than to an ietf working group mailing list. From owner-ipsec@lists.tislabs.com Mon May 15 10:37:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28649; Mon, 15 May 2000 10:37:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09037 Mon, 15 May 2000 12:29:08 -0400 (EDT) Date: Mon, 15 May 2000 09:34:32 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Ari Huttunen cc: "Mason, David" , Will Price , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability In-Reply-To: <391FB997.4CCE5446@F-Secure.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The contradictory notions are of "dumb client", "powering up his laptop and clicking a few icons randomly" and client having a personal firewall, and thus being able to protect it/him/her self. Looks like no one else has an interest in protecting their investment: like their implemtation of modeconfig/xauth. If that makes you feel any better, I would want to bring it to your notice once again, that we had implemented modeconfig and xauth... the whole nine yards, and we are currently shipping these features to customers. This decision to suppoet xauth/modeconfig was made, after we had both IPSec/L2TP working between two routers, but we couldn't get a client that could do both L2TP and IPSec. chinna On Mon, 15 May 2000, Ari Huttunen wrote: > I fail to understand your point that the proponents of modeconfig/xauth > would be pushing for the paradigm of a "dumb client". A client is no dumber > depending on the method used to assign it any specific configuration information > like an intranet IP address. > > In my view the scenario of an average remote user just "powering up his > laptop and clicking a few icons" is a good state of affairs. We have > a centralized management system that includes modeconfig and distributed > firewalling, so those are definitely not contradictory paradigms. > > I do think IPSec WG should define something to enable protection of > multicast traffic. Forcing everyone to use L2TP/IPSec is not a good > way, rather it's an effort from some vendors to protect their existing > investment, like was already mentioned in here. > > Ari > > "CHINNA N.R. PELLACURU" wrote: > > > > Frankly I like the notion of a personal firewall. I feel empowered, just > > by the thought that I have my own personal firewall. I agree with you that > > every one should have their personal firewall. > > > > But, that doesn't really fit into this paradigm of a "dumb client", that > > the proponents of modeconfig/xauth are pushing. The client is supposed to > > be dumb, and get even it's configuration parameters and phase2 policy, and > > if possible it's phase1 policy from the server. The average corporate > > executive (road warrior) is supposed to be so dumb that he is not expected > > to do anything other than powering up his laptop, and clicking a few > > icons. So, we push yet another policy to the client: the firewall policy. > > And if the "dumb client" wants to support securing multicast traffic, then > > we setup a logical GRE tunnel interface on the client, and push routing > > policy onto the client. So, we the client will be a dumb and powerful! > > > > chinna > > > > On Fri, 12 May 2000, Mason, David wrote: > > > > > Every client should have a personal firewall regardless of > > > whether it's PPP+L2TP+IPSEC+IKE or just IPSEC+(MODECFG+IKE) > > > since they'll often be connecting directly to the Internet > > > without going through the corporate firewall (no VPN). > > > -dave > > > > > > -----Original Message----- > > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > > Sent: Thursday, May 11, 2000 10:10 PM > > > To: Will Price > > > Cc: Stephen Kent; ipsec@lists.tislabs.com > > > Subject: Re: Windows 2000 and Cicsco router interoperability > > > > > > > > > I guess the bottom line is: > > > > > > Do you want to understand all the subtilities of AAA and IPCP, and then > > > massively hack IKE on an ongoing basis, to incorporate all that, (with > > > stuff like open ended exchanges, and on top of that require that every > > > client need a "personal firewall") > > > > > > or > > > > > > Do you want to leverage all the features of AAA and IPCP in a simple > > > modular way, and not bother too much about them, and trust them in that > > > they do their job well. > > > > > > Isn't securing CHAP/SecureID etc. within an IKE exchange an overhead? > > > > > > chinna > > > > > > On Thu, 11 May 2000, CHINNA N.R. PELLACURU wrote: > > > > > > > Atleast we agree on one thing: we should strive for simplicity. > > > > > > > > We are essentially talking about adding all the AAA and IPCP baggage to > > > > IKE. And that you say is simple! > > > > > > > > On top of that you want each IPSec client to have a "personal firewall" > > > > too. I can see why people want to suggest that. > > > > > > > > IMHO, it is much much simpler and modular to let L2TP/PPP deal with the > > > > AAA and IPCP, and let IPSec protect L2TP. > > > > > > > > L2TP is fully encapsulated in IPSec, and I don't see how that is less > > > > secure. > > > > > > > > I don't see how it is simple to introduce the AAA and IPCP baggage into > > > > IKE. How many forms of Authenticataion do you already support. Do you > > > > support Authorization and Accounting? How many features of IPCP do you > > > > already support? Probably it is simple for you because your customer base > > > > needs only a small subset of these features. But, once we open the flood > > > > gates, then customers would like to have all the features that they have > > > > come to enjoy in AAA and IPCP, and I guess we have to hack the protocol on > > > > an ongoing basis to add in features. > > > > > > > > chinna > > > > > > > > On Thu, 11 May 2000, Will Price wrote: > > > > > > > > > Those goals may be able to be "achieved naturally" by use of L2TP/IPsec, > > > > > but the issue to get back to Stephen's point is that there is a lot of > > > > > overhead involved in doing that when the same thing can be accomplished > > > > > much more simply (and I hope we all learned that simplicity is job #1 > > > here > > > > > after reading Bruce's paper) by just using IPsec correctly mixed the > > > > > appropriate client side personal firewall and routing as you point out. > > > > > > > > > > The latest version of our VPN client PGP 7.0 announced this week > > > > > implements both of those solutions (centrally managed client side > > > > > firewalling and the ability to direct all traffic to the secure gateway) > > > > > along with mode-config to accomplish these goals without any of the > > > > > overhead involved in trying to merge a complex protocol (L2TP) with > > > > > another complex protocol (IKE/IPsec). I can only imagine (and cringe > > > at) > > > > > the logistics involved in doing a security code review of both of those > > > > > together. > > > > > > > > > > > > > > > "CHINNA N.R. PELLACURU" wrote: > > > > > > > > > > > > And one more benefit of using L2TP/IPSec is, it can support securing > > > IP > > > > > > multicast traffic, atleast over the vpn link. But if you are using > > > native > > > > > > IPSec with Mode-config/Xauth, you can't secure multicast traffic, and > > > you > > > > > > will need to have atleast GRE to do this. > > > > > > > > > > > > I wonder how much benefit we can get out of "L2TP Header Compression". > > > > > > > > > > > > Regarding access control, some customers raised concerns that, if a > > > client > > > > > > has a VPN link connected to the corporate intranet, and is also > > > directly > > > > > > connected to the Internet, then they can't enforce the corporate > > > firewall > > > > > > policy on that client, like they can if the client was actually in the > > > > > > intranet. There were also concerns raised that if the client is > > > > > > directly connected to the Internet, it could be hacked, and won't be > > > able > > > > > > to have the same protection that the corporate firewall provides. > > > > > > > > > > > > There are atleast two ways of dealing with this: > > > > > > > > > > > > 1. put an equalent of the corporate firewall on the client so that it > > > can > > > > > > defend itself, and also enforce the corporate firewall policy. > > > > > > > > > > > > 2. have a very simple policy on the client that says all traffic will > > > go > > > > > > via the VPN link to the corporate network, and the client will > > > accept/send > > > > > > nothing else. This would be the true emulation of the Dial-in remote > > > > > > access, and this can be acheived naturally using L2TP. > > > > > > > > > > > > chinna > > > > > > > > > > > > On Thu, 11 May 2000, Stephen Kent wrote: > > > > > > > > > > > > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > > > > > > > >I can't speak for the whole of Cisco, but the way I look at it is: > > > > > > > > > > > > > > > >Modeconfig/Xauth are being supported as quick hack to get something > > > to > > > > > > > >work, and get something to customers, until there is a client that > > > can do > > > > > > > >IPSec and L2TP. > > > > > > > > > > > > > > > >I beleive that it is not our long term vision, to ship > > > Modeconfig/Xauth. I > > > > > > > >beleive that Cisco's long term goal is to follow whatever is > > > standardized > > > > > > > >in the IPSRA WG, because that's what IPSRA WG is chartered to > > > solve. > > > > > > > > > > > > > > > > > > > > > > That's one view. > > > > > > > > > > > > > > Another perspective is that L2TP over IPsec represents an effort by > > > > > > > Microsoft & Cisco to preserve a joint development investment in > > > L2TP, > > > > > > > irrespective of its technical merit in this context :-). If I am > > > > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > > > > > then the extra headers introduced by L2TP are not only wasteful of > > > > > > > bandwidth on a continuing basis, but they also interfere with the > > > > > > > access controls that are an essential part of IPsec. One needs some > > > > > > > means of dealing with bind time connection parameters, but use of > > > > > > > L2TP on a continuing basis is an expensive means of achieving this > > > > > > > goal. > > > > > > > > > > > > > > > -- > > > > > Will Price, Director of Engineering > > > > > PGP Security, Inc. > > > > > a division of Network Associates, Inc. > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > > s/w engineer > > > > > > > > > > > > > > chinna narasimha reddy pellacuru > > > s/w engineer > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > -- > 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 > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Mon May 15 11:09:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA29341; Mon, 15 May 2000 11:09:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09170 Mon, 15 May 2000 13:01:34 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Mon, 15 May 2000 10:07:55 -0700 (PDT) From: Jan Vilhuber To: Andrew Krywaniuk cc: "'Stephen Kent'" , ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: <000b01bfbe88$2fa49c50$d23e788a@andrewk3.timestep.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 15 May 2000, Andrew Krywaniuk wrote: > Jan, > > Allowing any authorized user to potentially spoof any other authorized user > is an acceptable trade-off?!? Do you have an example of such a thing and why this would be possible in l2tp+ipsec (+firewall if needed)? jan > Sure, it's better than allowing unauthorized > users to spoof authorized users, but... > > This doesn't mean you necessarily have to do firewalling in IPsec. I think > Joe Touch's idea of doing IP in IP and passing the context information by > reference has a lot of technical merit. > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber > > Sent: Sunday, May 14, 2000 2:41 PM > > To: Stephen Kent > > Cc: ipsec@lists.tislabs.com > > Subject: RE: Windows 2000 and Cicsco router interoperability > > > > > > In some people's minds, it's an acceptable trade-off, and > > others wil think > > differently. > > > > Personally, I don't see much difference with doing a check > > after decryption > > and decapsulation, than doing it before. Yes, you may loose > > some context, but > > so what. > > > > You can either burden IKE and IPSEC with a whole bunch more > > mechanisms for > > user-authentication, authorization, and accounting, thus > > making the protocols > > even MORE complex (and thus less likely to be completely > > understood and > > analyzed for weaknesses), OR you can combine two simple (relatively) > > mechanisms, and combine them. In fact, it precisely because I > > DON'T want to > > revisit these protocols, that I'm advocating l2tp+ipsec. > > > > The loss of security you claim exists there, I don't see. > > > > jan > > > > > > On Sun, 14 May 2000, Stephen Kent wrote: > > > > > At 11:58 PM -0700 5/12/00, Jan Vilhuber wrote: > > > >On Fri, 12 May 2000, Stephen Kent wrote: > > > > > Shekhar, > > > > > > > > > > >I can understand the waste of bandwidth by L2TP. > > > > > >But, can you please elaborate more on how does L2TP interfere > > > > > >with the access controls? > > > > > > > > > > IPsec includes access controls analogous to those of a > > stateless, > > > > > packet filtering firewall. The receiver knows the SA > > to which each > > > > > packet is cryptographically bound, thus it can match the packet > > > > > headers (selectors) against those that were negotiated > > for the SA in > > > > > question. If a packet arrives over a tunnel mode SA, > > the receiving > > > > > IPsec implementation checks the inner IP (and transport layer) > > > > > header, while in transport mode, the outer IP header > > (and the inner > > > > > transport header). When L2TP is used with IPsec, the > > L2TP spec calls > > > > > for transport mode SAs, which means that only the > > outer IP header is > > > > > checked. Thus the tunneled IP packet is not checked for access > > > > > contorl purposes by IPsec. > > > > > > > > > > Once a packet leaves the IPsec environment, this > > binding to an SA is > > > > > lost (unless some non-standard mechanisms are employed > > to maintain > > > > > the binding). So the best that a separate firewall can > > do is to match > > > > > the packet against its filter list to see if it > > matches ANY filter > > > > > rule. This is much less secure. > > > > > > > > >But no less usefull. > > > > > > > >jan > > > > -- > > > >Jan Vilhuber > > vilhuber@cisco.com > > > >Cisco Systems, San Jose > > (408) 527-0847 > > > > > > If reduced security in a context that focuses on security (else why > > > use IPsec at all?) is considered equivalent, then maybe we all need > > > to revisit the goals of these protocols. > > > > > > Steve > > > > > > > > > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose > > (408) 527-0847 > > > > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon May 15 12:28:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA01933; Mon, 15 May 2000 12:28:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09514 Mon, 15 May 2000 14:16:26 -0400 (EDT) Date: Mon, 15 May 2000 11:23:36 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Andrew Krywaniuk cc: "'Jan Vilhuber'" , "'Stephen Kent'" , ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: <000b01bfbe88$2fa49c50$d23e788a@andrewk3.timestep.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "allowing any authorized user to potentially spoof any other authorized user" Can you elaborate on how this is possible if you use L2TP/AAA/IPSec, and how modeconfig/xauth prevents this? I beleive that L2TP/AAA/IPSec can do anything that modeconfig/xauth does with native IPSec, and does it only better(clean, simple, and modular). And there are somethings that L2TP/IPSec can support that modeconfig/xauth with native IPSec cannot, like multicast/multiprotocol traffic. chinna On Mon, 15 May 2000, Andrew Krywaniuk wrote: > Jan, > > Allowing any authorized user to potentially spoof any other authorized user > is an acceptable trade-off?!? Sure, it's better than allowing unauthorized > users to spoof authorized users, but... > > This doesn't mean you necessarily have to do firewalling in IPsec. I think > Joe Touch's idea of doing IP in IP and passing the context information by > reference has a lot of technical merit. > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber > > Sent: Sunday, May 14, 2000 2:41 PM > > To: Stephen Kent > > Cc: ipsec@lists.tislabs.com > > Subject: RE: Windows 2000 and Cicsco router interoperability > > > > > > In some people's minds, it's an acceptable trade-off, and > > others wil think > > differently. > > > > Personally, I don't see much difference with doing a check > > after decryption > > and decapsulation, than doing it before. Yes, you may loose > > some context, but > > so what. > > > > You can either burden IKE and IPSEC with a whole bunch more > > mechanisms for > > user-authentication, authorization, and accounting, thus > > making the protocols > > even MORE complex (and thus less likely to be completely > > understood and > > analyzed for weaknesses), OR you can combine two simple (relatively) > > mechanisms, and combine them. In fact, it precisely because I > > DON'T want to > > revisit these protocols, that I'm advocating l2tp+ipsec. > > > > The loss of security you claim exists there, I don't see. > > > > jan > > > > > > On Sun, 14 May 2000, Stephen Kent wrote: > > > > > At 11:58 PM -0700 5/12/00, Jan Vilhuber wrote: > > > >On Fri, 12 May 2000, Stephen Kent wrote: > > > > > Shekhar, > > > > > > > > > > >I can understand the waste of bandwidth by L2TP. > > > > > >But, can you please elaborate more on how does L2TP interfere > > > > > >with the access controls? > > > > > > > > > > IPsec includes access controls analogous to those of a > > stateless, > > > > > packet filtering firewall. The receiver knows the SA > > to which each > > > > > packet is cryptographically bound, thus it can match the packet > > > > > headers (selectors) against those that were negotiated > > for the SA in > > > > > question. If a packet arrives over a tunnel mode SA, > > the receiving > > > > > IPsec implementation checks the inner IP (and transport layer) > > > > > header, while in transport mode, the outer IP header > > (and the inner > > > > > transport header). When L2TP is used with IPsec, the > > L2TP spec calls > > > > > for transport mode SAs, which means that only the > > outer IP header is > > > > > checked. Thus the tunneled IP packet is not checked for access > > > > > contorl purposes by IPsec. > > > > > > > > > > Once a packet leaves the IPsec environment, this > > binding to an SA is > > > > > lost (unless some non-standard mechanisms are employed > > to maintain > > > > > the binding). So the best that a separate firewall can > > do is to match > > > > > the packet against its filter list to see if it > > matches ANY filter > > > > > rule. This is much less secure. > > > > > > > > >But no less usefull. > > > > > > > >jan > > > > -- > > > >Jan Vilhuber > > vilhuber@cisco.com > > > >Cisco Systems, San Jose > > (408) 527-0847 > > > > > > If reduced security in a context that focuses on security (else why > > > use IPsec at all?) is considered equivalent, then maybe we all need > > > to revisit the goals of these protocols. > > > > > > Steve > > > > > > > > > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose > > (408) 527-0847 > > > > > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Mon May 15 12:45:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02327; Mon, 15 May 2000 12:45:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09579 Mon, 15 May 2000 14:41:33 -0400 (EDT) Message-Id: <4.3.0.20000515144843.027d87e0@mail.well.com> X-Sender: y2kc@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 15 May 2000 14:49:12 -0400 To: ipsec@lists.tislabs.com From: Declan McCullagh Subject: Wired query on Windows 2000 and DES/3DES Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm writing an article on the 3DES/single DES issue, and am posting here to get feedback and head off any potential errors. I've read all the messages in the thread. I have also asked Microsoft for comment directly. My summary so far: * Even when Windows 2000 is told to use triple-DES, export versions will quietly use single-DES. The only case in which this silent (modulo log entry) switch happens is when export versions are talking to export versions. * Microsoft intentionally designed this in and thinks of it as feature, not a bug. It's documented somewhere in the manual and obsessive readers might even find it. * Poor saps with export versions can download the 3DES upgrade from microsoft.com. * 3DES is up to 10^17 (2^(112-56)) times as resistant as DES to an exhaustive search. I assume that differential cryptanalysis cuts this substantially, but I haven't been able to find any figures. I have come across a related key attack that cuts total effort to 2^56 to 2^72, but I understand this isn't practical. * The fastest single DES "crack" yet is the January 1999 one of 22 hours: http://www.eff.org/pub/Privacy/Crypto_misc/DESCracker/HTML/19990119_deschallenge3.html * Windows 2000 came out around the same time that U.S. crypto policy changed. Future versions of the OS may be approved by Commerce Dept for general export. -Declan Wired News http://www.wired.com/ 202 986 3455 From owner-ipsec@lists.tislabs.com Mon May 15 13:03:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA02707; Mon, 15 May 2000 13:03:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09669 Mon, 15 May 2000 14:57:39 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4366.0 content-class: urn:content-classes:message Subject: RE: Win2000 IKE and 3des MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBE9E.AEC7A836" Date: Mon, 15 May 2000 11:52:13 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2FFC3D6@fifi.platinum.corp.microsoft.com> Thread-Topic: Win2000 IKE and 3des Thread-Index: Ab++eqJHzzRtfNWfRWm0ROjvY/0YugAH3hRA From: "William Dixon" To: "Mike Carney" , "Chun Ye" Cc: "Paul Koning" , "Sumi Singh" , , X-OriginalArrivalTime: 15 May 2000 18:55:13.0569 (UTC) FILETIME=[1A0B5110:01BFBE9F] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFBE9E.AEC7A836 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I will be in touch with Declan regarding this shortly. I will note in separate email the info available on Win2k IPSec. I'd appreciate it if there are other issues regarding Windows 2000 IPSec that media representatives need addressed, send email directly to me for IPSec only, or Rob Trace, robt@microsoft.com, who is the program manager for VPN.=20 Wm William Dixon Program Manager - Internet Protocol Security Windows Operating Systems Division Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: WDixon@microsoft.com (preferred), Work: 425-703-8729 -----Original Message----- From: Mike Carney [mailto:carney@securecomputing.com] Sent: Monday, May 15, 2000 7:32 AM To: Chun Ye Cc: Paul Koning; Sumi Singh; ipsec@lists.tislabs.com; carney@jumpsrv.stp.securecomputing.com Subject: Re: Win2000 IKE and 3des=20 > This is not a design error. If you have an export driver, how can you > expect to run 3DES? You can't. >=20 > Now why we can't reject it. Envision you are running a world-wide > corporation where domain-based policies are assigned to clients at > different sites at different counties. Some of them run the export > version of Win2K. Since it is near impossible to know what version of > Win2K clients are running, so all clients policies are set to use 3DES. > On the corp-side, some servers will be configured to accept 3DES only > and others both DES and 3DES. If you don't weaken 3DES on the export > clients, there is no way to talk to servers with DES configured. Then you need to have configuration option allows the administrator to configure 3DES and DES or 3DES only. >=20 > Having said that, the report mechanism should probably be improved and > we will address this in the next release.=3D20 Sorry Chun, I see the problem you are trying to address, but I don't agree with your solution. Regards, Michael Carney >=20 > --Chun >=20 > -----Original Message----- > From: Paul Koning [mailto:pkoning@xedia.com] > Sent: Friday, May 12, 2000 1:24 PM > To: Sumi Singh > Cc: ipsec@lists.tislabs.com > Subject: RE: Win2000 IKE and 3des >=20 >=20 > >>>>> "Sumi" =3D3D=3D3D Sumi Singh = writes: >=20 > Sumi> Just to clarify the behaviour of Windows 2000 - Windows 2000 > Sumi> weakens 3DES policy to DES if you do not have the strong > Sumi> encryption pack (128-bit) installed. This weakening is > Sumi> announced by an event in the Audit log. So if you have 2 peers > Sumi> with no encryption pack installed, and a policy to use 3DES, > Sumi> they will talk DES since they cannot do 3DES. >=20 > Clearly that's a major design error. >=20 > If you ask for something that's not supported, it should be rejected. > To change it (even with a message in some obscure log) is clearly > wrong. You don't build secure systems that way. >=20 > paul >=20 > ------_=3D_NextPart_001_01BFBC55.58D2F2C8 > Content-Type: text/html; > charset=3D"us-ascii" > Content-Transfer-Encoding: quoted-printable >=20 > > > > charset=3D3Dus-ascii"> > 6.0.4366.0"> > RE: Win2000 IKE and 3des > > > >=20 >

This is not a design error.  If you have an = =3D > export driver, how can you expect to run 3DES? >

>=20 >

Now why we can't reject it.  Envision you are = =3D > running a world-wide corporation where domain-based policies are =3D > assigned to clients at different sites at different counties.  Some =3D > of them run the export version of Win2K.  Since it is near =3D > impossible to know what version of Win2K clients are running, so all = =3D > clients policies are set to use 3DES.  On the corp-side, some =3D > servers will be configured to accept 3DES only and others both DES and =3D > 3DES.  If you don't weaken 3DES on the export clients, there is no =3D > way to talk to servers with DES configured.

>=20 >

Having said that, the report mechanism should probably =3D > be improved and we will address this in the next release. >

>=20 >

--Chun >

>=20 >

-----Original Message----- >=20 >
From: Paul Koning [ = HREF=3D3D"mailto:pkoning@xedia.com">mailto:pkoning@xedia.com] >=20 >
Sent: Friday, May 12, 2000 1:24 PM >=20 >
To: Sumi Singh >=20 >
Cc: ipsec@lists.tislabs.com >=20 >
Subject: RE: Win2000 IKE and 3des >

>
>=20 >

>>>>> "Sumi" =3D3D=3D3D = Sumi =3D > Singh <sumis@Exchange.Microsoft.com> writes: >

>=20 >

 Sumi> Just to clarify the behaviour of = =3D > Windows 2000 - Windows 2000 >=20 >
 Sumi> weakens 3DES policy to DES if you = do =3D > not have the strong >=20 >
 Sumi> encryption pack (128-bit) = installed. =3D > This weakening is >=20 >
 Sumi> announced by an event in the Audit = =3D > log. So if you have 2 peers >=20 >
 Sumi> with no encryption pack installed, and =3D > a policy to use 3DES, >=20 >
 Sumi> they will talk DES since they = cannot =3D > do 3DES. >

>=20 >

Clearly that's a major design error. >

>=20 >

If you ask for something that's not supported, it = =3D > should be rejected. >=20 >
To change it (even with a message in some obscure = =3D > log) is clearly >=20 >
wrong.  You don't build secure systems that = =3D > way. >

>=20 >

        paul >

>=20 > > > ------_=3D_NextPart_001_01BFBC55.58D2F2C8-- ------_=_NextPart_001_01BFBE9E.AEC7A836 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: Win2000 IKE and 3des

I will be in touch with Declan regarding this = shortly.  I will note in separate email the info available on Win2k = IPSec.  I'd appreciate it if there are other issues regarding = Windows 2000 IPSec that media representatives need addressed, send email = directly to me for IPSec only, or Rob Trace, robt@microsoft.com, who is = the program manager for VPN.

Wm
William Dixon
Program Manager - Internet Protocol Security
Windows Operating Systems Division
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email: WDixon@microsoft.com (preferred), Work: = 425-703-8729

-----Original Message-----
From: Mike Carney [mailto:carney@securecomputing.= com]
Sent: Monday, May 15, 2000 7:32 AM
To: Chun Ye
Cc: Paul Koning; Sumi Singh; = ipsec@lists.tislabs.com;
carney@jumpsrv.stp.securecomputing.com
Subject: Re: Win2000 IKE and 3des



> This is not a design error.  If you have an = export driver, how can you
> expect to run 3DES?

You can't.

>
> Now why we can't reject it.  Envision you = are running a world-wide
> corporation where domain-based policies are = assigned to clients at
> different sites at different counties.  = Some of them run the export
> version of Win2K.  Since it is near = impossible to know what version of
> Win2K clients are running, so all clients = policies are set to use 3DES.
> On the corp-side, some servers will be = configured to accept 3DES only
> and others both DES and 3DES.  If you don't = weaken 3DES on the export
> clients, there is no way to talk to servers with = DES configured.

Then you need to have configuration option allows the = administrator
to configure 3DES and DES or 3DES only.

>
> Having said that, the report mechanism should = probably be improved and
> we will address this in the next = release.=3D20

Sorry Chun,
  I see the problem you are trying to address, = but I don't agree
with your solution.

Regards,
Michael Carney

>
> --Chun
>
> -----Original Message-----
> From: Paul Koning [mailto:pkoning@xedia.com]
> Sent: Friday, May 12, 2000 1:24 PM
> To: Sumi Singh
> Cc: ipsec@lists.tislabs.com
> Subject: RE: Win2000 IKE and 3des
>
>
> >>>>> "Sumi" =3D3D=3D3D = Sumi Singh <sumis@Exchange.Microsoft.com> writes:
>
>  Sumi> Just to clarify the behaviour of = Windows 2000 - Windows 2000
>  Sumi> weakens 3DES policy to DES if you = do not have the strong
>  Sumi> encryption pack (128-bit) = installed. This weakening is
>  Sumi> announced by an event in the = Audit log. So if you have 2 peers
>  Sumi> with no encryption pack = installed, and a policy to use 3DES,
>  Sumi> they will talk DES since they = cannot do 3DES.
>
> Clearly that's a major design error.
>
> If you ask for something that's not supported, = it should be rejected.
> To change it (even with a message in some = obscure log) is clearly
> wrong.  You don't build secure systems that = way.
>
>       paul
>
> ------_=3D_NextPart_001_01BFBC55.58D2F2C8
> Content-Type: text/html;
>       = charset=3D"us-ascii"
> Content-Transfer-Encoding: = quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML = 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D3D"Content-Type" = CONTENT=3D3D"text/html; =3D
> charset=3D3Dus-ascii">
> <META NAME=3D3D"Generator" = CONTENT=3D3D"MS Exchange Server version =3D
> 6.0.4366.0">
> <TITLE>RE: Win2000 IKE and = 3des</TITLE>
> </HEAD>
> <BODY>
> <!-- Converted from text/plain format = -->
>
> <P><FONT SIZE=3D3D2>This is not a = design error.&nbsp; If you have an =3D
> export driver, how can you expect to run = 3DES?</FONT>
> </P>
>
> <P><FONT SIZE=3D3D2>Now why we can't = reject it.&nbsp; Envision you are =3D
> running a world-wide corporation where = domain-based policies are =3D
> assigned to clients at different sites at = different counties.&nbsp; Some =3D
> of them run the export version of = Win2K.&nbsp; Since it is near =3D
> impossible to know what version of Win2K clients = are running, so all =3D
> clients policies are set to use 3DES.&nbsp; = On the corp-side, some =3D
> servers will be configured to accept 3DES only = and others both DES and =3D
> 3DES.&nbsp; If you don't weaken 3DES on the = export clients, there is no =3D
> way to talk to servers with DES = configured.</FONT></P>
>
> <P><FONT SIZE=3D3D2>Having said = that, the report mechanism should probably =3D
> be improved and we will address this in the next = release. </FONT>
> </P>
>
> <P><FONT = SIZE=3D3D2>--Chun</FONT>
> </P>
>
> <P><FONT SIZE=3D3D2>-----Original = Message-----</FONT>
>
> <BR><FONT SIZE=3D3D2>From: Paul = Koning [<A =3D
> HREF=3D3D"mailto:pkoning@xedia.com"><= A = HREF=3D"mailto:pkoning@xedia.com">mailto:pkoning@xedia.com</A>]= </FONT>
>
> <BR><FONT SIZE=3D3D2>Sent: Friday, = May 12, 2000 1:24 PM</FONT>
>
> <BR><FONT SIZE=3D3D2>To: Sumi = Singh</FONT>
>
> <BR><FONT SIZE=3D3D2>Cc: = ipsec@lists.tislabs.com</FONT>
>
> <BR><FONT SIZE=3D3D2>Subject: RE: = Win2000 IKE and 3des</FONT>
> </P>
> <BR>
>
> <P><FONT = SIZE=3D3D2>&gt;&gt;&gt;&gt;&gt; = &quot;Sumi&quot; =3D3D=3D3D Sumi =3D
> Singh = &lt;sumis@Exchange.Microsoft.com&gt; writes:</FONT>
> </P>
>
> <P><FONT = SIZE=3D3D2>&nbsp;Sumi&gt; Just to clarify the behaviour of = =3D
> Windows 2000 - Windows 2000</FONT>
>
> <BR><FONT = SIZE=3D3D2>&nbsp;Sumi&gt; weakens 3DES policy to DES if you = do =3D
> not have the strong</FONT>
>
> <BR><FONT = SIZE=3D3D2>&nbsp;Sumi&gt; encryption pack (128-bit) = installed. =3D
> This weakening is</FONT>
>
> <BR><FONT = SIZE=3D3D2>&nbsp;Sumi&gt; announced by an event in the Audit = =3D
> log. So if you have 2 peers</FONT>
>
> <BR><FONT = SIZE=3D3D2>&nbsp;Sumi&gt; with no encryption pack installed, = and =3D
> a policy to use 3DES,</FONT>
>
> <BR><FONT = SIZE=3D3D2>&nbsp;Sumi&gt; they will talk DES since they = cannot =3D
> do 3DES.</FONT>
> </P>
>
> <P><FONT SIZE=3D3D2>Clearly that's a = major design error.</FONT>
> </P>
>
> <P><FONT SIZE=3D3D2>If you ask for = something that's not supported, it =3D
> should be rejected.</FONT>
>
> <BR><FONT SIZE=3D3D2>To change it = (even with a message in some obscure =3D
> log) is clearly</FONT>
>
> <BR><FONT = SIZE=3D3D2>wrong.&nbsp; You don't build secure systems that = =3D
> way.</FONT>
> </P>
>
> = <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp; <FONT SIZE=3D3D2>paul</FONT>
> </P>
>
> </BODY>
> </HTML>
> = ------_=3D_NextPart_001_01BFBC55.58D2F2C8--

------_=_NextPart_001_01BFBE9E.AEC7A836-- From owner-ipsec@lists.tislabs.com Mon May 15 15:24:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05672; Mon, 15 May 2000 15:24:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10130 Mon, 15 May 2000 17:08:38 -0400 (EDT) From: kbrown@mier.com Message-ID: To: declan@wired.com, ipsec@lists.tislabs.com Subject: RE: Wired query on Windows 2000 and DES/3DES Date: Mon, 15 May 2000 17:20:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="windows-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How did you come up with "3DES is up to 10^17 (2^(112-56)) times as resistant as DES"? Is 3DES properly noted as (2^56)^3 or is it 3*(2^56)? Kevin -----Original Message----- From: Declan McCullagh [mailto:declan@wired.com] Sent: Monday, May 15, 2000 2:49 PM To: ipsec@lists.tislabs.com Subject: Wired query on Windows 2000 and DES/3DES I'm writing an article on the 3DES/single DES issue, and am posting here to get feedback and head off any potential errors. I've read all the messages in the thread. I have also asked Microsoft for comment directly. My summary so far: * Even when Windows 2000 is told to use triple-DES, export versions will quietly use single-DES. The only case in which this silent (modulo log entry) switch happens is when export versions are talking to export versions. * Microsoft intentionally designed this in and thinks of it as feature, not a bug. It's documented somewhere in the manual and obsessive readers might even find it. * Poor saps with export versions can download the 3DES upgrade from microsoft.com. * 3DES is up to 10^17 (2^(112-56)) times as resistant as DES to an exhaustive search. I assume that differential cryptanalysis cuts this substantially, but I haven't been able to find any figures. I have come across a related key attack that cuts total effort to 2^56 to 2^72, but I understand this isn't practical. * The fastest single DES "crack" yet is the January 1999 one of 22 hours: http://www.eff.org/pub/Privacy/Crypto_misc/DESCracker/HTML/19990119_deschall enge3.html * Windows 2000 came out around the same time that U.S. crypto policy changed. Future versions of the OS may be approved by Commerce Dept for general export. -Declan Wired News http://www.wired.com/ 202 986 3455 From owner-ipsec@lists.tislabs.com Mon May 15 15:24:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05691; Mon, 15 May 2000 15:24:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10086 Mon, 15 May 2000 16:57:36 -0400 (EDT) From: yzhuang@chrysalis-its.com Message-ID: <7E8CCF56F7F8D211894700104B9DF96D387624@NTSERVER2> To: ipsec@lists.tislabs.com Subject: Q: Win2K L2TP/IPSec Compression Date: Mon, 15 May 2000 14:59:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Does anyone know whether Microsoft supports MPPC or any compression algorithm on PPP (L2TP) level if L2TP over IPSec is used? Thanks a lot! Yong yzhuang@chrysalis-its.com From owner-ipsec@lists.tislabs.com Mon May 15 15:24:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05673; Mon, 15 May 2000 15:24:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10085 Mon, 15 May 2000 16:57:35 -0400 (EDT) Message-Id: <4.3.0.20000515133852.030fae40@mail.well.com> X-Sender: declan@mail.well.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 15 May 2000 13:42:30 -0400 To: ipsec@lists.tislabs.com From: Declan McCullagh Subject: Wired query on Windows 2000 and DES/3DES Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm writing an article on the 3DES/single DES issue, and am posting here to get feedback and head off any potential errors. I've read all the messages in the thread. My summary so far: * Even when Windows 2000 is told to use triple-DES, export versions will quietly use single-DES. The only case in which this silent (modulo log entry) switch happens is when export versions are talking to export versions. * Microsoft intentionally designed this in and thinks of it as feature, not a bug. It's documented somewhere in the manual and obsessive readers might even find it. * Poor saps with export versions can download the 3DES upgrade from microsoft.com. * 3DES is up to 10^17 (2^(112-56)) times as resistant as DES to an exhaustive search. I assume that differential cryptanalysis cuts this substantially, but I haven't been able to find any figures. I have come across a related key attack that cuts total effort to 2^56 to 2^72, but I understand this isn't practical. * The fastest single DES "crack" yet is the January 1999 one of 22 hours: http://www.eff.org/pub/Privacy/Crypto_misc/DESCracker/HTML/19990119_deschallenge3.html * Windows 2000 came out around the same time that U.S. crypto policy changed. Future versions of the OS may be approved by Commerce Dept for general export. -Declan Wired News http://www.wired.com/ 202 986 3455 From owner-ipsec@lists.tislabs.com Mon May 15 17:28:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08378; Mon, 15 May 2000 17:28:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10549 Mon, 15 May 2000 19:23:07 -0400 (EDT) From: akrywani@newbridge.com Reply-To: To: "'CHINNA N.R. PELLACURU'" , "Andrew Krywaniuk" Cc: "'Jan Vilhuber'" , "'Stephen Kent'" , Subject: RE: Windows 2000 and Cicsco router interoperability Date: Mon, 15 May 2000 19:26:47 -0400 Message-Id: <000201bfbec5$0aaabe60$d23e788a@andrewk3.timestep.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chinna, Sorry, but this has nothing to do with Config Mode or XAuth and very little to do with L2TP specifically. I was merely addressing Jan's claim that skipping the step where you back-check the tunnelled IP (whether it be through L2TP or IPsec tunnel mode or IP-in-IP) against the tunnel endpoint is just some kind of design trade-off. In fact, this is a security feature that prevents one authorized user from spoofing other authorized users. Steve was merely pointing out that this feature is built into IPsec tunnel mode whereas with L2TP you have to add it separately. IMHO, the idea with the most technical merit is to remove packet filtering from IPsec and make the firewalls IPsec aware. (No, I'm not saying we should rewrite all the specs; that's just the *ideal* solution in my mind.) All clear now? Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of CHINNA > N.R. PELLACURU > Sent: Monday, May 15, 2000 2:24 PM > To: Andrew Krywaniuk > Cc: 'Jan Vilhuber'; 'Stephen Kent'; ipsec@lists.tislabs.com > Subject: RE: Windows 2000 and Cicsco router interoperability > > > "allowing any authorized user to potentially spoof any other > authorized > user" > > Can you elaborate on how this is possible if you use > L2TP/AAA/IPSec, and > how modeconfig/xauth prevents this? > > I beleive that L2TP/AAA/IPSec can do anything that > modeconfig/xauth does > with native IPSec, and does it only better(clean, simple, and > modular). > And there are somethings that L2TP/IPSec can support that > modeconfig/xauth > with native IPSec cannot, like multicast/multiprotocol traffic. > > chinna > > On Mon, 15 May 2000, Andrew Krywaniuk wrote: > > > Jan, > > > > Allowing any authorized user to potentially spoof any other > authorized user > > is an acceptable trade-off?!? Sure, it's better than > allowing unauthorized > > users to spoof authorized users, but... > > > > This doesn't mean you necessarily have to do firewalling in > IPsec. I think > > Joe Touch's idea of doing IP in IP and passing the context > information by > > reference has a lot of technical merit. > > > > Andrew > > -------------------------------------- > > Beauty with out truth is insubstantial. > > Truth without beauty is unbearable. > > > > > > > -----Original Message----- > > > From: owner-ipsec@lists.tislabs.com > > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber > > > Sent: Sunday, May 14, 2000 2:41 PM > > > To: Stephen Kent > > > Cc: ipsec@lists.tislabs.com > > > Subject: RE: Windows 2000 and Cicsco router interoperability > > > > > > > > > In some people's minds, it's an acceptable trade-off, and > > > others wil think > > > differently. > > > > > > Personally, I don't see much difference with doing a check > > > after decryption > > > and decapsulation, than doing it before. Yes, you may loose > > > some context, but > > > so what. > > > > > > You can either burden IKE and IPSEC with a whole bunch more > > > mechanisms for > > > user-authentication, authorization, and accounting, thus > > > making the protocols > > > even MORE complex (and thus less likely to be completely > > > understood and > > > analyzed for weaknesses), OR you can combine two simple > (relatively) > > > mechanisms, and combine them. In fact, it precisely because I > > > DON'T want to > > > revisit these protocols, that I'm advocating l2tp+ipsec. > > > > > > The loss of security you claim exists there, I don't see. > > > > > > jan > > > > > > > > > On Sun, 14 May 2000, Stephen Kent wrote: > > > > > > > At 11:58 PM -0700 5/12/00, Jan Vilhuber wrote: > > > > >On Fri, 12 May 2000, Stephen Kent wrote: > > > > > > Shekhar, > > > > > > > > > > > > >I can understand the waste of bandwidth by L2TP. > > > > > > >But, can you please elaborate more on how does > L2TP interfere > > > > > > >with the access controls? > > > > > > > > > > > > IPsec includes access controls analogous to those of a > > > stateless, > > > > > > packet filtering firewall. The receiver knows the SA > > > to which each > > > > > > packet is cryptographically bound, thus it can > match the packet > > > > > > headers (selectors) against those that were negotiated > > > for the SA in > > > > > > question. If a packet arrives over a tunnel mode SA, > > > the receiving > > > > > > IPsec implementation checks the inner IP (and > transport layer) > > > > > > header, while in transport mode, the outer IP header > > > (and the inner > > > > > > transport header). When L2TP is used with IPsec, the > > > L2TP spec calls > > > > > > for transport mode SAs, which means that only the > > > outer IP header is > > > > > > checked. Thus the tunneled IP packet is not > checked for access > > > > > > contorl purposes by IPsec. > > > > > > > > > > > > Once a packet leaves the IPsec environment, this > > > binding to an SA is > > > > > > lost (unless some non-standard mechanisms are employed > > > to maintain > > > > > > the binding). So the best that a separate firewall can > > > do is to match > > > > > > the packet against its filter list to see if it > > > matches ANY filter > > > > > > rule. This is much less secure. > > > > > > > > > > >But no less usefull. > > > > > > > > > >jan > > > > > -- > > > > >Jan Vilhuber > > > vilhuber@cisco.com > > > > >Cisco Systems, San Jose > > > (408) 527-0847 > > > > > > > > If reduced security in a context that focuses on > security (else why > > > > use IPsec at all?) is considered equivalent, then maybe > we all need > > > > to revisit the goals of these protocols. > > > > > > > > Steve > > > > > > > > > > > > > > -- > > > Jan Vilhuber > > > vilhuber@cisco.com > > > Cisco Systems, San Jose > > > (408) 527-0847 > > > > > > > > > > > > chinna narasimha reddy pellacuru > s/w engineer > > From owner-ipsec@lists.tislabs.com Mon May 15 17:44:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08770; Mon, 15 May 2000 17:44:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10600 Mon, 15 May 2000 19:38:17 -0400 (EDT) Message-Id: <4.3.0.20000515194606.01f67f00@pop.webcom.com> X-Sender: y2kc@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 15 May 2000 19:46:14 -0400 To: ipsec@lists.tislabs.com From: Declan McCullagh Subject: Re: Wired query on Windows 2000 and DES/3DES Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I just got off the phone with MS. * They say the "feature" is reasonably well-documented, and that the 3DES crypto comes on a sep. disk/CDROM in all W2K installations, not just U.S. * They say it's possible to configure a W2K box to use 3DES *only* and it will *not* drop down. I suspect this is not the default, but I didn't think to ask. * They say it's for remote ease-of-maintenance: "if i misconfigured a system, rather than having to travel out to that machine to fix it or rather than having that machine be completely in the clear, what we did was use the highest level of encryption that we could export and import into the country. what we did was leave it in a state that could be managed." * They say their customers like it: "no one has disputed this or questioned this. clearly the customers must think this is a proper approach, rather than some people who come from a philosophical background that you manage policy from the end system and not the directory." Any thoughts? I'm writing my article now. -Declan From owner-ipsec@lists.tislabs.com Mon May 15 17:53:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09058; Mon, 15 May 2000 17:53:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10651 Mon, 15 May 2000 19:46:09 -0400 (EDT) Date: Mon, 15 May 2000 15:52:35 -0400 (EDT) From: Henry Spencer To: Declan McCullagh cc: ipsec@lists.tislabs.com Subject: Re: Wired query on Windows 2000 and DES/3DES In-Reply-To: <4.3.0.20000515144843.027d87e0@mail.well.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 15 May 2000, Declan McCullagh wrote: > * 3DES is up to 10^17 (2^(112-56)) times as resistant as DES to an > exhaustive search. It's 2^112 (about 10^34) better against a simple exhaustive search, thanks to having 112 more key bits. It's only 2^56 (about 10^17) better against a meet-in-the-middle exhaustive search, with a *very* large memory in the middle -- the memory is big enough to be expensive and problematic but not utterly infeasible. > I assume that differential cryptanalysis cuts this > substantially, but I haven't been able to find any figures. Last I heard -- caution, this is not an area I keep up on -- it didn't help things very much. Differential cryptanalysis, at least in its pure form, is a largely theoretical approach: it requires preconditions which are very difficult to arrange in practice, partly because DES was specifically designed to resist it. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon May 15 18:11:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA13586; Mon, 15 May 2000 18:11:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10711 Mon, 15 May 2000 20:04:13 -0400 (EDT) Message-Id: <4.3.0.20000515201050.01fab3c0@pop.webcom.com> X-Sender: y2kc@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 15 May 2000 20:12:09 -0400 To: ipsec@lists.tislabs.com From: Declan McCullagh Subject: Re: Wired query on Windows 2000 and DES/3DES Cc: kbrown@mier.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk kbrown@mier.com wrote: >How did you come up with "3DES is up to 10^17 (2^(112-56)) times as >resistant as DES"? Is 3DES properly noted as (2^56)^3 or is it 3*(2^56)? My calculation came from _Applied Cryptography_. -Declan From owner-ipsec@lists.tislabs.com Mon May 15 18:17:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14625; Mon, 15 May 2000 18:17:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10736 Mon, 15 May 2000 20:06:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4366.0 content-class: urn:content-classes:message Subject: RE: Win2k IKE MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBEC9.911941DE" Date: Mon, 15 May 2000 16:59:12 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2A21DCF@fifi.platinum.corp.microsoft.com> Thread-Topic: Win2k IKE Thread-Index: Ab+qblqT5xMu5gJ8QKyJv6VSUsP/XgUWxygQ From: "William Dixon" To: "Jianying Zhou" , "Brian Swander" Cc: X-OriginalArrivalTime: 16 May 2000 00:01:22.0725 (UTC) FILETIME=[DEEA1550:01BFBEC9] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFBEC9.911941DE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Jianying, the basic options win2k supports is noted in our supported options list on the last bakeoff form: http://www.calbug.org:8080/cgi-bin/vpn/index.cgi -----Original Message----- From: Jianying Zhou [mailto:jyzhou@krdl.org.sg] Sent: Wednesday, April 19, 2000 6:48 PM To: Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Win2k IKE Thanks, Brian.=20 A further question. What are the functions or API used in Win2k for IPSec encryption and hash operations? Jianying Zhou On Mon, 17 Apr 2000, Brian Swander wrote: > ike and ipsec are in all flavors of win2k. >=20 > bs >=20 > -----Original Message----- > From: Jianying Zhou [mailto:jyzhou@krdl.org.sg] > Sent: Sunday, April 16, 2000 6:33 PM > To: ipsec@lists.tislabs.com > Subject: Win2k IKE >=20 >=20 > Hi, >=20 > Does anyone know whether IKE and IPsec are supported in all Win2k versions, > that is professional, server, and advanced server versions? >=20 > Thanks. >=20 > Jianying Zhou >=20 ------_=_NextPart_001_01BFBEC9.911941DE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: Win2k IKE

Jianying, the basic options win2k supports is noted in = our supported options list on the last bakeoff form:

     http://www.calb= ug.org:8080/cgi-bin/vpn/index.cgi

-----Original Message-----
From: Jianying Zhou [mailto:jyzhou@krdl.org.sg]
Sent: Wednesday, April 19, 2000 6:48 PM
To: Brian Swander
Cc: ipsec@lists.tislabs.com
Subject: RE: Win2k IKE


Thanks, Brian.

A further question. What are the functions or API used = in Win2k for IPSec
encryption and hash operations?

Jianying Zhou


On Mon, 17 Apr 2000, Brian Swander wrote:

> ike and ipsec are in all flavors of win2k.
>
> bs
>
> -----Original Message-----
> From: Jianying Zhou [mailto:jyzhou@krdl.org.sg]
> Sent: Sunday, April 16, 2000 6:33 PM
> To: ipsec@lists.tislabs.com
> Subject: Win2k IKE
>
>
> Hi,
>
> Does anyone know whether IKE and IPsec are = supported in all Win2k versions,
> that is professional, server, and advanced = server versions?
>
> Thanks.
>
> Jianying Zhou
>

------_=_NextPart_001_01BFBEC9.911941DE-- From owner-ipsec@lists.tislabs.com Mon May 15 18:41:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19614; Mon, 15 May 2000 18:41:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10820 Mon, 15 May 2000 20:28:12 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Declan McCullagh Cc: ipsec@lists.tislabs.com, kbrown@mier.com Subject: Re: Wired query on Windows 2000 and DES/3DES Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 May 2000 20:35:19 -0400 Message-Id: <20000516003523.B6C2E35DCD@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <4.3.0.20000515201050.01fab3c0@pop.webcom.com>, Declan McCullagh wri tes: >kbrown@mier.com wrote: >>How did you come up with "3DES is up to 10^17 (2^(112-56)) times as >>resistant as DES"? Is 3DES properly noted as (2^56)^3 or is it 3*(2^56)? > >My calculation came from _Applied Cryptography_. > 3DES was originally spec'd as "encrypt with K1, decrypt with K2, encrypt with K1 again". IPsec uses "encrypt with K1, decrypt with K2, encrypt with K3", i.e., with three different keys, not two. --Steve Bellovin From owner-ipsec@lists.tislabs.com Mon May 15 19:06:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA22745; Mon, 15 May 2000 19:06:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10960 Mon, 15 May 2000 20:58:04 -0400 (EDT) Date: Mon, 15 May 2000 20:05:27 -0400 From: "Michael H. Warfield" To: Declan McCullagh Cc: ipsec@lists.tislabs.com Subject: Re: Wired query on Windows 2000 and DES/3DES Message-ID: <20000515200527.I17459@alcove.wittsend.com> References: <4.3.0.20000515194606.01f67f00@pop.webcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.5i In-Reply-To: <4.3.0.20000515194606.01f67f00@pop.webcom.com>; from declan@wired.com on Mon, May 15, 2000 at 07:46:14PM -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, May 15, 2000 at 07:46:14PM -0400, Declan McCullagh wrote: > I just got off the phone with MS. [...] > * They say their customers like it: "no one has disputed this or questioned > this. clearly the customers must think this is a proper approach, rather > than some people who come from a philosophical background that you manage > policy from the end system and not the directory." Whoa! Time out! There is a fundamental brain fart right there. This ranks right up with the old "silent majority" nonsense. Nobody disputes it or questions it, because nobody is informed of it. So from their (Microsoft's) point of view, if you keep it below the users radar by not telling them what you are doing, they must therefore approve of what you are doing. IS THAT what they are saying? Unfortunately, that's consistant with their attitude on a lot of things. Hide it so the user doesn't know what's going on (even if it doesn't work) and then claim that nobody complains about it, so they must all like it (or, in the case of scripting and other nonsense, they demand it as a feature). Cryptography, at it's best, is quite subtle. It's very easy to deceive or confuse the end user or hide what the little man is doing behind the curtain. How would anyone dispute or question what they are doing if they didn't tell anyone (or buried the explaination so deep that only the most desparate insomniac would ever find it). The absence of complaints does NOT imply the approval of the users. It really implies the deliberate, orchestrated, and calculated ignorance of the users. When someone finally DOES dig down and find the truth, then they wear the hair shirt and complain that no one else has complained. Well fine. Someone has to be first and someone has to bring to light what they have kept hidden through subtle subterfuge. It may be there in the documentation, but it is something that the AVERAGE user is likely to ever discover, or are they more likely to trust what the fancy point and click gui's are telling them? One is a bald face lier, even if the other is literally, but surreptuously, true. Heinlein once wrote that there are two ways of lying artfully. One is to tell the truth, you just don't tell all of it. The other is to tell the truth, but you tell it so badly that nobody believes you. Which is this? I don't know. But they may have told the truth, but the users were lied to... > Any thoughts? I'm writing my article now. > -Declan Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Mon May 15 21:22:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA07067; Mon, 15 May 2000 21:22:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA11341 Mon, 15 May 2000 23:13:23 -0400 (EDT) Message-Id: <3.0.5.32.20000515231639.008081a0@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 15 May 2000 23:16:39 -0400 To: "Michael H. Warfield" From: David Jablon Subject: Re: Wired query on Windows 2000 and DES/3DES Cc: Declan McCullagh , ipsec@lists.tislabs.com In-Reply-To: <20000515200527.I17459@alcove.wittsend.com> References: <4.3.0.20000515194606.01f67f00@pop.webcom.com> <4.3.0.20000515194606.01f67f00@pop.webcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >On Mon, May 15, 2000 at 07:46:14PM -0400, Declan McCullagh wrote: >> I just got off the phone with MS. [...] > >> * They say their customers like it: "no one has disputed this or questioned >> this. clearly the customers must think this is a proper approach, rather >> than some people who come from a philosophical background that you manage >> policy from the end system and not the directory." [...] >> >> Any thoughts? I'm writing my article now. At 08:05 PM 5/15/00 -0400, "Michael H. Warfield" wrote: > Heinlein once wrote that there are two ways of lying artfully. >One is to tell the truth, you just don't tell all of it. The other is >to tell the truth, but you tell it so badly that nobody believes you. There's also "the BIG lie", which I first read in Ian Fleming. One so bold and obviously false on it's face that it must be true. Otherwise, who would think they could get away with it? "Our users are asking for this." Who knows. Maybe these are the same users who demand that fresh out-of-the-box unstoppable virus proliferation feature. That said, MS is certainly not the only vendor to take a cynical attitude towards naive users. But they seem to be the boldest in openly stating this philosophy. -- dpj From owner-ipsec@lists.tislabs.com Mon May 15 22:25:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA11975; Mon, 15 May 2000 22:25:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA11493 Tue, 16 May 2000 00:23:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 15 May 2000 12:33:44 -0400 To: Jan Vilhuber From: Stephen Kent Subject: RE: Windows 2000 and Cicsco router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:41 AM -0700 5/14/00, Jan Vilhuber wrote: >In some people's minds, it's an acceptable trade-off, and others wil think >differently. > >Personally, I don't see much difference with doing a check after decryption >and decapsulation, than doing it before. Yes, you may loose some context, but >so what. > >You can either burden IKE and IPSEC with a whole bunch more mechanisms for >user-authentication, authorization, and accounting, thus making the protocols >even MORE complex (and thus less likely to be completely understood and >analyzed for weaknesses), OR you can combine two simple (relatively) >mechanisms, and combine them. In fact, it precisely because I DON'T want to >revisit these protocols, that I'm advocating l2tp+ipsec. > >The loss of security you claim exists there, I don't see. > >jan As I noted, if one has lost the binding between a packet and the SA via which it arrived, because the access control decision is being made outside the IPsec module, then this decision is being made based on unauthenticated inputs, which is no better than what one gets from a typical firewall w/o IPsec. I'd say this is a significant degradation of the security potential offered by IPsec. Steve From owner-ipsec@lists.tislabs.com Mon May 15 22:50:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA13573; Mon, 15 May 2000 22:50:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA11614 Tue, 16 May 2000 00:48:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 16 May 2000 00:56:26 -0400 To: "CHINNA N.R. PELLACURU" From: Stephen Kent Subject: RE: Windows 2000 and Cicsco router interoperability Cc: Andrew Krywaniuk , "'Jan Vilhuber'" , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chinna, Go back an reread the last few messages I have sent describing the difference between what native IPsec does vs. what any standard says about L2TP over IPsec re access control. That is the basis for my comments and those of Andrew. Steve From owner-ipsec@lists.tislabs.com Tue May 16 00:20:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA17919; Tue, 16 May 2000 00:20:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA11945 Tue, 16 May 2000 02:23:39 -0400 (EDT) Date: Mon, 15 May 2000 23:30:47 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Stephen Kent cc: Andrew Krywaniuk , "'Jan Vilhuber'" , ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Frankly, I don't understand what Andrew is trying to tell me. His bottom line was: "IMHO, the idea with the most technical merit is to remove packet filtering from IPsec and make the firewalls IPsec aware. (No, I'm not saying we should rewrite all the specs; that's just the *ideal* solution in my mind.) All clear now?" !!! Anyway, regarding access control: How many people beleive that the IPSec access control mechanism, is going to solve all our access control problems? If people beleived that IPSec access control mechanism solves all their access control problems, then I guess we wouldn't have a need to leverage the access control features that AAA provides. I have seen customers who are so fond of their AAA infrastructure, that they by-pass IKE authentication by using an equivalent of a global pre-shared key! and totally base their authentication on AAA authentication(and if you do this via xauth, that doesn't authenticate the DH exchange)! Let's face it, how many implementations support some form of global pre-shared key? Supposedly the customers wants this badly, and if we dont provide this, there are implementations that already provide this! To investigate the cryptographic binding between a packet that has been decapsulated, and to which the IPSec selector has to be applied, lets start by how the binding took form at the encapsulation side in the first place. At the encapsulation side, in the context on an IPSec implementaion, we have a selector based on IP Addresses, protocol and ports. Once a packet matches this selector, it is encapsulated, and that is all IPSec can truly enforce. Are you saying that this is all we need to enforce all kinds of access control requirements, and complex policies that any corporation can have? It's not just the access control folks that see IPSec as a nuance, but there are the Intrution Detection (ID) folks. If we do end to end security, IE from the client of some service to the server of that service, the ID folks don't like that. If we had an IPSec selector that says all traffic from any TCP high port to port 21 needs to be secured with a certain policy, it doesn't stop a legitimate user/a hacker who gained control of the system to do a simple TCP SYN flood attack. If this traffic was encrypted using IPSec, then there is no way that the Intrution Detection System (IDS), is going to detect this. So, these guys have a requirement that all IPSec tunnels should terminate on the perimeter of the network, so that these guys can do their job. I guess, someone is busy, out there trying to integrate ID into IPSec. xids? Then we can have xauth, xauthr, xacc, xids, mode config etc... and we can update these documents once every 6 months, to incorporate/support more and more features of these protocols. There are supposedly 6 versions(revisions) of the draft that we already have, and different vendors support different versions. I leart today that we support version 3 on the cisco router. I guess we are just waiting for some customer to bang on our heads, demanding that they want version 6 because it has a feature x that version 3 cannot support. chinna On Tue, 16 May 2000, Stephen Kent wrote: > Chinna, > > Go back an reread the last few messages I have sent describing the > difference between what native IPsec does vs. what any standard says > about L2TP over IPsec re access control. That is the basis for my > comments and those of Andrew. > > Steve > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue May 16 00:35:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18971; Tue, 16 May 2000 00:35:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12049 Tue, 16 May 2000 02:40:23 -0400 (EDT) Message-Id: <01BFBF2F.FB121E60.RuheenaR@future.futsoft.com> From: Ruheena Rashid Reply-To: "RuheenaR@future.futsoft.com" To: "ipsec@lists.tislabs.com" , "'Joern Sierwald'" , "'Markku Savela'" , "'Stephen Kent'" Subject: Regarding DES/3DES Date: Tue, 16 May 2000 12:12:17 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello I have query regarding using DES and 3DES for encryption. RFC 2420 states that - for 3DES "The keyed DES function is iterated three times, an encryption (E) followed by a decryption (D) followed by an encryption (E), and generates the ciphertext (C1) for the block. Each iteration uses an independent key: k1, k2 and k3. To decrypt, the order of the functions is reversed: decrypt with k3, encrypt with k2, decrypt with k1, and XOR with the previous cipher- text block." Since 3 different keys are used in 3DES, is it that the second and third keys (k2 and k3) are generated using the first key(k1) ? If not, then how are the second and third keys (k2 and k3) generated ? Regards Ruheena Rashid. From owner-ipsec@lists.tislabs.com Tue May 16 00:47:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA19719; Tue, 16 May 2000 00:47:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA12038 Tue, 16 May 2000 02:39:55 -0400 (EDT) Date: Mon, 15 May 2000 23:47:07 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Stephen Kent cc: Andrew Krywaniuk , "'Jan Vilhuber'" , ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk And BTW, a global pre-shared key is the key technology that enables centralized policy management, and the whole idea of the server downloading policy to the dumb clients via modeconfig!!!!!!!!!!!! And this supposedly also elimanates the overhead of double authentication, when doing xauth!!!!!! So, if you think that you already know all the overheads that these protocols eliminate, please think again. chinna PS: I really don't know which arm of our marketing came up with this idea, it could be either the inbound marketing or the outbound marketing, or the product marketing, and we have a marketing organisation in each line of buisiness. The best part of it is that they supposedly stole this brilliant idea from the IPSec solution of a competitor. Wonder who that is... On Mon, 15 May 2000, CHINNA N.R. PELLACURU wrote: > Frankly, I don't understand what Andrew is trying to tell me. His bottom > line was: > > "IMHO, the idea with the most technical merit is to remove packet > filtering from IPsec and make the firewalls IPsec aware. (No, I'm not > saying we should rewrite all the specs; that's just the *ideal* solution > in my mind.) > > All clear now?" !!! > > Anyway, regarding access control: > > How many people beleive that the IPSec access control mechanism, is going > to solve all our access control problems? > > If people beleived that IPSec access control mechanism solves all their > access control problems, then I guess we wouldn't have a need to leverage > the access control features that AAA provides. I have seen customers who > are so fond of their AAA infrastructure, that they by-pass IKE > authentication by using an equivalent of a global pre-shared key! and > totally base their authentication on AAA authentication(and if you do this > via xauth, that doesn't authenticate the DH exchange)! Let's face it, how > many implementations support some form of global pre-shared key? > Supposedly the customers wants this badly, and if we dont provide this, > there are implementations that already provide this! > > To investigate the cryptographic binding between a packet that has been > decapsulated, and to which the IPSec selector has to be applied, lets > start by how the binding took form at the encapsulation side in the first > place. At the encapsulation side, in the context on an IPSec > implementaion, we have a selector based on IP Addresses, protocol and > ports. Once a packet matches this selector, it is encapsulated, and that > is all IPSec can truly enforce. Are you saying that this is all we need to > enforce all kinds of access control requirements, and complex policies > that any corporation can have? > > It's not just the access control folks that see IPSec as a nuance, but > there are the Intrution Detection (ID) folks. If we do end to end > security, IE from the client of some service to the server of that > service, the ID folks don't like that. If we had an IPSec selector that > says all traffic from any TCP high port to port 21 needs to be secured > with a certain policy, it doesn't stop a legitimate user/a hacker who > gained control of the system to do a simple TCP SYN flood attack. If this > traffic was encrypted using IPSec, then there is no way that the Intrution > Detection System (IDS), is going to detect this. So, these guys have a > requirement that all IPSec tunnels should terminate on the perimeter of > the network, so that these guys can do their job. I guess, someone is > busy, out there trying to integrate ID into IPSec. xids? Then we can have > xauth, xauthr, xacc, xids, mode config etc... and we can update these > documents once every 6 months, to incorporate/support more and more > features of these protocols. There are supposedly 6 versions(revisions) of > the draft that we already have, and different vendors support different > versions. I leart today that we support version 3 on the cisco router. > I guess we are just waiting for some customer to bang on our heads, > demanding that they want version 6 because it has a feature x that version > 3 cannot support. > > chinna > > On Tue, 16 May 2000, Stephen Kent wrote: > > > Chinna, > > > > Go back an reread the last few messages I have sent describing the > > difference between what native IPsec does vs. what any standard says > > about L2TP over IPsec re access control. That is the basis for my > > comments and those of Andrew. > > > > Steve > > > > chinna narasimha reddy pellacuru > s/w engineer > > > > > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue May 16 02:03:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA25089; Tue, 16 May 2000 02:03:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA12273 Tue, 16 May 2000 03:54:25 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A363@baltimore.com> From: Chris Trobridge To: RuheenaR@future.futsoft.com, ipsec@lists.tislabs.com, "'Joern Sierwald'" , "'Markku Savela'" , "'Stephen Kent'" Subject: RE: Regarding DES/3DES Date: Tue, 16 May 2000 09:01:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As the text you quoted states the 3 DES keys are independent. You need to generate 3 DES keys - this means taking 168 (3x56) bits from your (pseudo)random source. Chris > -----Original Message----- > From: Ruheena Rashid [mailto:RuheenaR@future.futsoft.com] > Sent: 16 May 2000 07:42 > To: ipsec@lists.tislabs.com; 'Joern Sierwald'; 'Markku > Savela'; 'Stephen > Kent' > Subject: Regarding DES/3DES > > > Hello > > I have query regarding using DES and 3DES for encryption. > RFC 2420 states that - for 3DES > "The keyed DES function is iterated three times, an > encryption (E) followed > by a decryption (D) followed by an encryption (E), and generates the > ciphertext (C1) for the block. Each iteration uses an > independent key: k1, > k2 and k3. To decrypt, the order of the functions is > reversed: decrypt with > k3, encrypt with k2, decrypt with k1, and XOR with the > previous cipher- > text block." > > Since 3 different keys are used in 3DES, is it that the > second and third > keys (k2 and k3) are generated using the first key(k1) ? > > If not, then how are the second and third keys (k2 and k3) > generated ? > > Regards > Ruheena Rashid. > From owner-ipsec@lists.tislabs.com Tue May 16 02:04:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA25251; Tue, 16 May 2000 02:04:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA12302 Tue, 16 May 2000 04:04:15 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A364@baltimore.com> From: Chris Trobridge To: "CHINNA N.R. PELLACURU" , Stephen Kent Cc: Andrew Krywaniuk , "'Jan Vilhuber'" , ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Tue, 16 May 2000 09:11:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The point is that with an IPSEC SA traffic is only allowed that matches the selector for that SA. In the access control case this means you can enforce that anyone who connects via an IPSEC tunnel can only send or receive datagrams associated with his client address. This prevents him from spoofing other clients or hosts and from receiving traffic not addressed to him. The moment you tunnel L2TP through an SA IPSEC loses its ability to perform this filtering. Depending on the whether 'extra' work has been done, once IPSEC processing has been completed the L2TP layer will not know via which SA a datagram was received, allowing a client to spoof other addresses. However, I agree with Andrew: The packet filtering in IPSEC is rather primitive and would be better provided via an IPSEC aware firewall. Chris > -----Original Message----- > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > Sent: 16 May 2000 07:31 > To: Stephen Kent > Cc: Andrew Krywaniuk; 'Jan Vilhuber'; ipsec@lists.tislabs.com > Subject: RE: Windows 2000 and Cicsco router interoperability > > > Frankly, I don't understand what Andrew is trying to tell me. > His bottom > line was: > > "IMHO, the idea with the most technical merit is to remove packet > filtering from IPsec and make the firewalls IPsec aware. (No, I'm not > saying we should rewrite all the specs; that's just the > *ideal* solution > in my mind.) > > All clear now?" !!! > > Anyway, regarding access control: > > How many people beleive that the IPSec access control > mechanism, is going > to solve all our access control problems? > > If people beleived that IPSec access control mechanism solves > all their > access control problems, then I guess we wouldn't have a need > to leverage > the access control features that AAA provides. I have seen > customers who > are so fond of their AAA infrastructure, that they by-pass IKE > authentication by using an equivalent of a global pre-shared key! and > totally base their authentication on AAA authentication(and > if you do this > via xauth, that doesn't authenticate the DH exchange)! Let's > face it, how > many implementations support some form of global pre-shared key? > Supposedly the customers wants this badly, and if we dont > provide this, > there are implementations that already provide this! > > To investigate the cryptographic binding between a packet > that has been > decapsulated, and to which the IPSec selector has to be applied, lets > start by how the binding took form at the encapsulation side > in the first > place. At the encapsulation side, in the context on an IPSec > implementaion, we have a selector based on IP Addresses, protocol and > ports. Once a packet matches this selector, it is > encapsulated, and that > is all IPSec can truly enforce. Are you saying that this is > all we need to > enforce all kinds of access control requirements, and complex policies > that any corporation can have? > > It's not just the access control folks that see IPSec as a nuance, but > there are the Intrution Detection (ID) folks. If we do end to end > security, IE from the client of some service to the server of that > service, the ID folks don't like that. If we had an IPSec > selector that > says all traffic from any TCP high port to port 21 needs to be secured > with a certain policy, it doesn't stop a legitimate user/a hacker who > gained control of the system to do a simple TCP SYN flood > attack. If this > traffic was encrypted using IPSec, then there is no way that > the Intrution > Detection System (IDS), is going to detect this. So, these guys have a > requirement that all IPSec tunnels should terminate on the > perimeter of > the network, so that these guys can do their job. I guess, someone is > busy, out there trying to integrate ID into IPSec. xids? Then > we can have > xauth, xauthr, xacc, xids, mode config etc... and we can update these > documents once every 6 months, to incorporate/support more and more > features of these protocols. There are supposedly 6 > versions(revisions) of > the draft that we already have, and different vendors support > different > versions. I leart today that we support version 3 on the cisco router. > I guess we are just waiting for some customer to bang on our heads, > demanding that they want version 6 because it has a feature x > that version > 3 cannot support. > > chinna > > On Tue, 16 May 2000, Stephen Kent wrote: > > > Chinna, > > > > Go back an reread the last few messages I have sent describing the > > difference between what native IPsec does vs. what any > standard says > > about L2TP over IPsec re access control. That is the basis for my > > comments and those of Andrew. > > > > Steve > > > > chinna narasimha reddy pellacuru > s/w engineer > > > > > From owner-ipsec@lists.tislabs.com Tue May 16 04:26:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA05622; Tue, 16 May 2000 04:26:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12976 Tue, 16 May 2000 06:21:44 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D280CF@new-exc1.ctron.com> From: "Waters, Stephen" To: yzhuang@chrysalis-its.com Cc: ipsec@lists.tislabs.com Subject: RE: Win2K L2TP/IPSec Compression Date: Tue, 16 May 2000 11:28:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Compression is via PPP, yes. No IPCOMP with IPSEC. Steve. -----Original Message----- From: yzhuang@chrysalis-its.com [mailto:yzhuang@chrysalis-its.com] Sent: Monday, May 15, 2000 7:59 PM To: ipsec@lists.tislabs.com Subject: Q: Win2K L2TP/IPSec Compression Does anyone know whether Microsoft supports MPPC or any compression algorithm on PPP (L2TP) level if L2TP over IPSec is used? Thanks a lot! Yong yzhuang@chrysalis-its.com From owner-ipsec@lists.tislabs.com Tue May 16 04:31:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA05940; Tue, 16 May 2000 04:31:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA13044 Tue, 16 May 2000 06:34:35 -0400 (EDT) Message-ID: From: Dominique Bastien To: RuheenaR@future.futsoft.com, ipsec@lists.tislabs.com Subject: Regarding DES/3DES Date: Tue, 16 May 2000 06:42:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I send you a text from The ESP Triple DES Transform draft "draft-ietf-ipsec-ciph-des3-00.txt" 4.2. Manual Key Management When configured manually, three independently generated keys are required, in the order used for encryption, and 64-bits (8 bytes) are configured for each individual key. Keys with incorrect parity SHOULD be rejected by the configuration utility, ensuring that the keys have been correctly configured. Each key is examined sequentially, in the order used for encryption. A key that is identical to a previous key MAY be rejected. The 64 known weak DES keys [RFC-1829x] SHOULD be rejected. If you K1 and K2 are identical it's just like DES with K3. http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-des3-00.txt I hope micr*s*ft do this check in is super "encryption pack". p.s. Check the weak keys into Schneier p. 233 (Schneier, B., "Applied Cryptography", John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2 ). Or from FIPS74 ( US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981, http://www.itl.nist.gov/div897/pubs/fip74.htm ). >Hello >I have query regarding using DES and 3DES for encryption. >RFC 2420 states that - for 3DES >"The keyed DES function is iterated three times, an encryption (E) followed >by a decryption (D) followed by an encryption (E), and generates the >ciphertext (C1) for the block. Each iteration uses an independent key: k1, >k2 and k3. To decrypt, the order of the functions is reversed: decrypt with >k3, encrypt with k2, decrypt with k1, and XOR with the previous cipher- >text block." >Since 3 different keys are used in 3DES, is it that the second and third >keys (k2 and k3) are generated using the first key(k1) ? >If not, then how are the second and third keys (k2 and k3) generated ? >Regards >Ruheena Rashid. From owner-ipsec@lists.tislabs.com Tue May 16 04:41:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06404; Tue, 16 May 2000 04:41:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA13071 Tue, 16 May 2000 06:40:39 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E373EF@eseis06nok> To: ipsec@lists.tislabs.com Subject: IKE transforms selection Date: Tue, 16 May 2000 13:48:12 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk According to the RFC 2408 (ISAKMP) section 4.2 at the end: "The responder SHOULD retain the Proposal # field in the Proposal payload and the Transform # field in each Transform payload of the selected Proposal." Does it mean that the reply should contain these number even though there only one transform selected? Does it apply for phase 1 and phase 2? I've tried with a couple of implementations and they don't seem to act like taht at least during phase 1. If anyone could clarify me that it would be very useful. Thanks! Toni Barrera -----Original Message----- From: EXT Chris Trobridge [mailto:CTrobridge@baltimore.com] Sent: 16. May 2000 11:12 To: CHINNA N.R. PELLACURU; Stephen Kent Cc: Andrew Krywaniuk; 'Jan Vilhuber'; ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability The point is that with an IPSEC SA traffic is only allowed that matches the selector for that SA. In the access control case this means you can enforce that anyone who connects via an IPSEC tunnel can only send or receive datagrams associated with his client address. This prevents him from spoofing other clients or hosts and from receiving traffic not addressed to him. The moment you tunnel L2TP through an SA IPSEC loses its ability to perform this filtering. Depending on the whether 'extra' work has been done, once IPSEC processing has been completed the L2TP layer will not know via which SA a datagram was received, allowing a client to spoof other addresses. However, I agree with Andrew: The packet filtering in IPSEC is rather primitive and would be better provided via an IPSEC aware firewall. Chris > -----Original Message----- > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > Sent: 16 May 2000 07:31 > To: Stephen Kent > Cc: Andrew Krywaniuk; 'Jan Vilhuber'; ipsec@lists.tislabs.com > Subject: RE: Windows 2000 and Cicsco router interoperability > > > Frankly, I don't understand what Andrew is trying to tell me. > His bottom > line was: > > "IMHO, the idea with the most technical merit is to remove packet > filtering from IPsec and make the firewalls IPsec aware. (No, I'm not > saying we should rewrite all the specs; that's just the > *ideal* solution > in my mind.) > > All clear now?" !!! > > Anyway, regarding access control: > > How many people beleive that the IPSec access control > mechanism, is going > to solve all our access control problems? > > If people beleived that IPSec access control mechanism solves > all their > access control problems, then I guess we wouldn't have a need > to leverage > the access control features that AAA provides. I have seen > customers who > are so fond of their AAA infrastructure, that they by-pass IKE > authentication by using an equivalent of a global pre-shared key! and > totally base their authentication on AAA authentication(and > if you do this > via xauth, that doesn't authenticate the DH exchange)! Let's > face it, how > many implementations support some form of global pre-shared key? > Supposedly the customers wants this badly, and if we dont > provide this, > there are implementations that already provide this! > > To investigate the cryptographic binding between a packet > that has been > decapsulated, and to which the IPSec selector has to be applied, lets > start by how the binding took form at the encapsulation side > in the first > place. At the encapsulation side, in the context on an IPSec > implementaion, we have a selector based on IP Addresses, protocol and > ports. Once a packet matches this selector, it is > encapsulated, and that > is all IPSec can truly enforce. Are you saying that this is > all we need to > enforce all kinds of access control requirements, and complex policies > that any corporation can have? > > It's not just the access control folks that see IPSec as a nuance, but > there are the Intrution Detection (ID) folks. If we do end to end > security, IE from the client of some service to the server of that > service, the ID folks don't like that. If we had an IPSec > selector that > says all traffic from any TCP high port to port 21 needs to be secured > with a certain policy, it doesn't stop a legitimate user/a hacker who > gained control of the system to do a simple TCP SYN flood > attack. If this > traffic was encrypted using IPSec, then there is no way that > the Intrution > Detection System (IDS), is going to detect this. So, these guys have a > requirement that all IPSec tunnels should terminate on the > perimeter of > the network, so that these guys can do their job. I guess, someone is > busy, out there trying to integrate ID into IPSec. xids? Then > we can have > xauth, xauthr, xacc, xids, mode config etc... and we can update these > documents once every 6 months, to incorporate/support more and more > features of these protocols. There are supposedly 6 > versions(revisions) of > the draft that we already have, and different vendors support > different > versions. I leart today that we support version 3 on the cisco router. > I guess we are just waiting for some customer to bang on our heads, > demanding that they want version 6 because it has a feature x > that version > 3 cannot support. > > chinna > > On Tue, 16 May 2000, Stephen Kent wrote: > > > Chinna, > > > > Go back an reread the last few messages I have sent describing the > > difference between what native IPsec does vs. what any > standard says > > about L2TP over IPsec re access control. That is the basis for my > > comments and those of Andrew. > > > > Steve > > > > chinna narasimha reddy pellacuru > s/w engineer > > > > > From owner-ipsec@lists.tislabs.com Tue May 16 06:53:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13004; Tue, 16 May 2000 06:53:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13586 Tue, 16 May 2000 08:37:13 -0400 (EDT) Date: Tue, 16 May 2000 09:27:22 +0300 (EET DST) From: Markku-Juhani Saarinen X-Sender: mjos@tukki To: Declan McCullagh cc: ipsec@lists.tislabs.com Subject: Re: Wired query on Windows 2000 and DES/3DES In-Reply-To: <4.3.0.20000515133852.030fae40@mail.well.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > * 3DES is up to 10^17 (2^(112-56)) times as resistant as DES to an > exhaustive search. I assume that differential cryptanalysis cuts this > substantially, but I haven't been able to find any figures. I have come > across a related key attack that cuts total effort to 2^56 to 2^72, but I > understand this isn't practical. Hi, - Biham's related key attack [1] uses assumptions that do not hold in IPSec. - Differential and linear cryptanalysis against 3DES requires more than 2^64 known ciphertexts and can't work for that reason. - The best attack (that I know of) is by Stefan Lucks [2]. He describes an attack that breaks 3DES in 2^108 steps. If you only count the single DES operations (and assume that memory access is fast etc) you only require 2^90 of these. This is consistent with the overall IPSec security level. [1] Eli Biham, "New Types of Cryptanalytic Attacks Using Related Keys," Technical Report CS0753, Technion CS Department, 1992 [2] Stefan Lucks, "Attacking Triple Encryption," Proc. FSE'98, Springer LNCS series, 1998 Cheers, - mj Markku-Juhani O. Saarinen University of Jyv”skyl”, Finland From owner-ipsec@lists.tislabs.com Tue May 16 06:56:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13100; Tue, 16 May 2000 06:56:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13988 Tue, 16 May 2000 08:57:01 -0400 (EDT) Message-Id: <4.3.0.20000516090152.023d3030@pop.webcom.com> X-Sender: y2kc@pop.webcom.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 16 May 2000 09:02:28 -0400 To: ipsec@lists.tislabs.com From: Declan McCullagh Subject: Re: Wired query on Windows 2000 and DES/3DES Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My article is here: http://www.wired.com/news/technology/0,1282,36336,00.html Thanks, all for the help. -Declan From owner-ipsec@lists.tislabs.com Tue May 16 08:08:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15609; Tue, 16 May 2000 08:08:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14475 Tue, 16 May 2000 09:56:27 -0400 (EDT) Date: Tue, 16 May 2000 09:03:33 -0400 From: "Michael H. Warfield" To: Ruheena Rashid Cc: "ipsec@lists.tislabs.com" , "'Joern Sierwald'" , "'Markku Savela'" , "'Stephen Kent'" Subject: Re: Regarding DES/3DES Message-ID: <20000516090333.M17459@alcove.wittsend.com> References: <01BFBF2F.FB121E60.RuheenaR@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.5i In-Reply-To: <01BFBF2F.FB121E60.RuheenaR@future.futsoft.com>; from RuheenaR@future.futsoft.com on Tue, May 16, 2000 at 12:12:17PM +0530 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, May 16, 2000 at 12:12:17PM +0530, Ruheena Rashid wrote: > Hello > I have query regarding using DES and 3DES for encryption. > RFC 2420 states that - for 3DES > "The keyed DES function is iterated three times, an encryption (E) followed > by a decryption (D) followed by an encryption (E), and generates the > ciphertext (C1) for the block. Each iteration uses an independent key: k1, > k2 and k3. To decrypt, the order of the functions is reversed: decrypt with > k3, encrypt with k2, decrypt with k1, and XOR with the previous cipher- > text block." > Since 3 different keys are used in 3DES, is it that the second and third > keys (k2 and k3) are generated using the first key(k1) ? Each key is a 56 bit quantity and are considered independent. When all three keys are different, this is 168 bit 3DES. If the first and third keys are the same, this is 112 bit EDE 3DES. If all three keys are the same, this is the degenerate 56 bit single DES compatible mode (the encrypt-decrypt-encrypt reduces to be identical to just a single encrypt with a single key when all three are identical). > If not, then how are the second and third keys (k2 and k3) generated ? If you generate a 168 bit key, the first key is the first 56 bits, the second key is the next 56 bits, and the third key is the last 56bits. Or was that the other way around??? :-) Now was that bigendian or little endian??? :-) (Sorry, had to poke some humor.) Each of the three "keys" are 56 bits long. > Regards > Ruheena Rashid. Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Tue May 16 08:10:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15650; Tue, 16 May 2000 08:10:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14498 Tue, 16 May 2000 10:02:36 -0400 (EDT) Date: Tue, 16 May 2000 10:09:33 -0400 (EDT) From: Henry Spencer To: Ruheena Rashid cc: "ipsec@lists.tislabs.com" Subject: Re: Regarding DES/3DES In-Reply-To: <01BFBF2F.FB121E60.RuheenaR@future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 16 May 2000, Ruheena Rashid wrote: > If not, then how are the second and third keys (k2 and k3) generated ? The same way the first one was generated. Do the same process -- which preferably involves a good random-bits source -- two more times. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue May 16 09:50:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17966; Tue, 16 May 2000 09:50:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14957 Tue, 16 May 2000 11:36:20 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14625.27840.954459.565468@xedia.com> Date: Tue, 16 May 2000 11:44:00 -0400 (EDT) To: Dominique.Bastien@abl.ca Cc: RuheenaR@future.futsoft.com, ipsec@lists.tislabs.com Subject: Re: Regarding DES/3DES References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Dominique" == Dominique Bastien writes: Dominique> I send you a text from The ESP Triple DES Transform draft Dominique> "draft-ietf-ipsec-ciph-des3-00.txt" ... A key that Dominique> is identical to a previous key MAY be rejected.... Dominique> If you K1 and K2 are identical it's just like DES with K3. You quoted an out of date document. Use RFC 2451 instead. It says that K1 == K2 MUST be rejected, which is only reasonable... paul From owner-ipsec@lists.tislabs.com Tue May 16 09:57:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18145; Tue, 16 May 2000 09:57:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15027 Tue, 16 May 2000 11:58:55 -0400 (EDT) Date: Tue, 16 May 2000 09:05:39 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Chris Trobridge cc: Stephen Kent , Andrew Krywaniuk , "'Jan Vilhuber'" , ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: <1FD60AE4DB6CD2118C420008C74C27B854A364@baltimore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So, you want filtering in IPSec, but you really think the filtering in IPSec is primitive, and really feel that it should be handled elsewhere! chinna On Tue, 16 May 2000, Chris Trobridge wrote: > The point is that with an IPSEC SA traffic is only allowed that matches the > selector for that SA. In the access control case this means you can enforce > that anyone who connects via an IPSEC tunnel can only send or receive > datagrams associated with his client address. This prevents him from > spoofing other clients or hosts and from receiving traffic not addressed to > him. > > The moment you tunnel L2TP through an SA IPSEC loses its ability to perform > this filtering. Depending on the whether 'extra' work has been done, once > IPSEC processing has been completed the L2TP layer will not know via which > SA a datagram was received, allowing a client to spoof other addresses. > > However, I agree with Andrew: The packet filtering in IPSEC is rather > primitive and would be better provided via an IPSEC aware firewall. > > Chris > > > -----Original Message----- > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > Sent: 16 May 2000 07:31 > > To: Stephen Kent > > Cc: Andrew Krywaniuk; 'Jan Vilhuber'; ipsec@lists.tislabs.com > > Subject: RE: Windows 2000 and Cicsco router interoperability > > > > > > Frankly, I don't understand what Andrew is trying to tell me. > > His bottom > > line was: > > > > "IMHO, the idea with the most technical merit is to remove packet > > filtering from IPsec and make the firewalls IPsec aware. (No, I'm not > > saying we should rewrite all the specs; that's just the > > *ideal* solution > > in my mind.) > > > > All clear now?" !!! > > > > Anyway, regarding access control: > > > > How many people beleive that the IPSec access control > > mechanism, is going > > to solve all our access control problems? > > > > If people beleived that IPSec access control mechanism solves > > all their > > access control problems, then I guess we wouldn't have a need > > to leverage > > the access control features that AAA provides. I have seen > > customers who > > are so fond of their AAA infrastructure, that they by-pass IKE > > authentication by using an equivalent of a global pre-shared key! and > > totally base their authentication on AAA authentication(and > > if you do this > > via xauth, that doesn't authenticate the DH exchange)! Let's > > face it, how > > many implementations support some form of global pre-shared key? > > Supposedly the customers wants this badly, and if we dont > > provide this, > > there are implementations that already provide this! > > > > To investigate the cryptographic binding between a packet > > that has been > > decapsulated, and to which the IPSec selector has to be applied, lets > > start by how the binding took form at the encapsulation side > > in the first > > place. At the encapsulation side, in the context on an IPSec > > implementaion, we have a selector based on IP Addresses, protocol and > > ports. Once a packet matches this selector, it is > > encapsulated, and that > > is all IPSec can truly enforce. Are you saying that this is > > all we need to > > enforce all kinds of access control requirements, and complex policies > > that any corporation can have? > > > > It's not just the access control folks that see IPSec as a nuance, but > > there are the Intrution Detection (ID) folks. If we do end to end > > security, IE from the client of some service to the server of that > > service, the ID folks don't like that. If we had an IPSec > > selector that > > says all traffic from any TCP high port to port 21 needs to be secured > > with a certain policy, it doesn't stop a legitimate user/a hacker who > > gained control of the system to do a simple TCP SYN flood > > attack. If this > > traffic was encrypted using IPSec, then there is no way that > > the Intrution > > Detection System (IDS), is going to detect this. So, these guys have a > > requirement that all IPSec tunnels should terminate on the > > perimeter of > > the network, so that these guys can do their job. I guess, someone is > > busy, out there trying to integrate ID into IPSec. xids? Then > > we can have > > xauth, xauthr, xacc, xids, mode config etc... and we can update these > > documents once every 6 months, to incorporate/support more and more > > features of these protocols. There are supposedly 6 > > versions(revisions) of > > the draft that we already have, and different vendors support > > different > > versions. I leart today that we support version 3 on the cisco router. > > I guess we are just waiting for some customer to bang on our heads, > > demanding that they want version 6 because it has a feature x > > that version > > 3 cannot support. > > > > chinna > > > > On Tue, 16 May 2000, Stephen Kent wrote: > > > > > Chinna, > > > > > > Go back an reread the last few messages I have sent describing the > > > difference between what native IPsec does vs. what any > > standard says > > > about L2TP over IPsec re access control. That is the basis for my > > > comments and those of Andrew. > > > > > > Steve > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > > > > > > > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue May 16 11:15:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20215; Tue, 16 May 2000 11:15:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15214 Tue, 16 May 2000 12:52:19 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A376@baltimore.com> From: Chris Trobridge To: "CHINNA N.R. PELLACURU" Cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Tue, 16 May 2000 17:59:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > Sent: 16 May 2000 17:06 > To: Chris Trobridge > Cc: Stephen Kent; Andrew Krywaniuk; 'Jan Vilhuber'; > ipsec@lists.tislabs.com > Subject: RE: Windows 2000 and Cicsco router interoperability > > > So, you want filtering in IPSec, but you really think the filtering in > IPSec is primitive, and really feel that it should be handled > elsewhere! That's not what I wrote! There already is strongly coupled filtering, if a little primitive, in IPSEC. It is stronger because the filtering ties up the IP addresses with the SA selector. This information may be lost if the checking is done later. The filtering is primitive because the selector rules don't cope with policy like "ftp to host A, pop3 or smtp to host B, or http to hosts C or D" - they allow a limited specification of ranges/wildcards. I don't think the filtering should be done in IPSEC but it should take account of the IPSEC SA. I think the principle role of IPSEC should be to provide secure communications between two points - eg provide services for traffic confidentiality, authentication and integrity between two points. Access control etc I think should be elsewhere. Chris > chinna > > On Tue, 16 May 2000, Chris Trobridge wrote: > > > The point is that with an IPSEC SA traffic is only allowed > that matches the > > selector for that SA. In the access control case this > means you can enforce > > that anyone who connects via an IPSEC tunnel can only send > or receive > > datagrams associated with his client address. This > prevents him from > > spoofing other clients or hosts and from receiving traffic > not addressed to > > him. > > > > The moment you tunnel L2TP through an SA IPSEC loses its > ability to perform > > this filtering. Depending on the whether 'extra' work has > been done, once > > IPSEC processing has been completed the L2TP layer will not > know via which > > SA a datagram was received, allowing a client to spoof > other addresses. > > > > However, I agree with Andrew: The packet filtering in > IPSEC is rather > > primitive and would be better provided via an IPSEC aware firewall. > > > > Chris From owner-ipsec@lists.tislabs.com Tue May 16 11:16:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20305; Tue, 16 May 2000 11:16:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15199 Tue, 16 May 2000 12:46:23 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'CHINNA N.R. PELLACURU'" Cc: Subject: RE: Windows 2000 and Cicsco router interoperability Date: Tue, 16 May 2000 12:49:04 -0400 Message-Id: <000901bfbf56$a6372df0$d23e788a@andrewk3.timestep.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 In-Reply-To: Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As Mister T. would say, "Stop you rantin, foo." My bottom line (which may have inadvertently appeared at the top of my message) was: "Sorry, but this has nothing to do with Config Mode or XAuth and very little to do with L2TP specifically." If you want to turn this into a debate about everything and anything then you'll excuse me while I step outside. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of CHINNA > N.R. PELLACURU > Sent: Tuesday, May 16, 2000 2:31 AM > To: Stephen Kent > Cc: Andrew Krywaniuk; 'Jan Vilhuber'; ipsec@lists.tislabs.com > Subject: RE: Windows 2000 and Cicsco router interoperability > > > Frankly, I don't understand what Andrew is trying to tell me. > His bottom > line was: > > "IMHO, the idea with the most technical merit is to remove packet > filtering from IPsec and make the firewalls IPsec aware. (No, I'm not > saying we should rewrite all the specs; that's just the > *ideal* solution > in my mind.) > > All clear now?" !!! > > Anyway, regarding access control: > > How many people beleive that the IPSec access control > mechanism, is going > to solve all our access control problems? > > If people beleived that IPSec access control mechanism solves > all their > access control problems, then I guess we wouldn't have a need > to leverage > the access control features that AAA provides. I have seen > customers who > are so fond of their AAA infrastructure, that they by-pass IKE > authentication by using an equivalent of a global pre-shared key! and > totally base their authentication on AAA authentication(and > if you do this > via xauth, that doesn't authenticate the DH exchange)! Let's > face it, how > many implementations support some form of global pre-shared key? > Supposedly the customers wants this badly, and if we dont > provide this, > there are implementations that already provide this! > > To investigate the cryptographic binding between a packet > that has been > decapsulated, and to which the IPSec selector has to be applied, lets > start by how the binding took form at the encapsulation side > in the first > place. At the encapsulation side, in the context on an IPSec > implementaion, we have a selector based on IP Addresses, protocol and > ports. Once a packet matches this selector, it is > encapsulated, and that > is all IPSec can truly enforce. Are you saying that this is > all we need to > enforce all kinds of access control requirements, and complex policies > that any corporation can have? > > It's not just the access control folks that see IPSec as a nuance, but > there are the Intrution Detection (ID) folks. If we do end to end > security, IE from the client of some service to the server of that > service, the ID folks don't like that. If we had an IPSec > selector that > says all traffic from any TCP high port to port 21 needs to be secured > with a certain policy, it doesn't stop a legitimate user/a hacker who > gained control of the system to do a simple TCP SYN flood > attack. If this > traffic was encrypted using IPSec, then there is no way that > the Intrution > Detection System (IDS), is going to detect this. So, these guys have a > requirement that all IPSec tunnels should terminate on the > perimeter of > the network, so that these guys can do their job. I guess, someone is > busy, out there trying to integrate ID into IPSec. xids? Then > we can have > xauth, xauthr, xacc, xids, mode config etc... and we can update these > documents once every 6 months, to incorporate/support more and more > features of these protocols. There are supposedly 6 > versions(revisions) of > the draft that we already have, and different vendors support > different > versions. I leart today that we support version 3 on the cisco router. > I guess we are just waiting for some customer to bang on our heads, > demanding that they want version 6 because it has a feature x > that version > 3 cannot support. > > chinna > > On Tue, 16 May 2000, Stephen Kent wrote: > > > Chinna, > > > > Go back an reread the last few messages I have sent describing the > > difference between what native IPsec does vs. what any > standard says > > about L2TP over IPsec re access control. That is the basis for my > > comments and those of Andrew. > > > > Steve > > > > chinna narasimha reddy pellacuru > s/w engineer > > > > > > From owner-ipsec@lists.tislabs.com Tue May 16 11:16:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20325; Tue, 16 May 2000 11:16:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15248 Tue, 16 May 2000 13:00:31 -0400 (EDT) Date: Tue, 16 May 2000 10:07:40 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Chris Trobridge cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: <1FD60AE4DB6CD2118C420008C74C27B854A376@baltimore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think that is what most of us feel. chinna On Tue, 16 May 2000, Chris Trobridge wrote: > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > Sent: 16 May 2000 17:06 > > To: Chris Trobridge > > Cc: Stephen Kent; Andrew Krywaniuk; 'Jan Vilhuber'; > > ipsec@lists.tislabs.com > > Subject: RE: Windows 2000 and Cicsco router interoperability > > > > > > So, you want filtering in IPSec, but you really think the filtering in > > IPSec is primitive, and really feel that it should be handled > > elsewhere! > > That's not what I wrote! > > There already is strongly coupled filtering, if a little primitive, in > IPSEC. It is stronger because the filtering ties up the IP addresses with > the SA selector. This information may be lost if the checking is done > later. The filtering is primitive because the selector rules don't cope > with policy like "ftp to host A, pop3 or smtp to host B, or http to hosts C > or D" - they allow a limited specification of ranges/wildcards. > > I don't think the filtering should be done in IPSEC but it should take > account of the IPSEC SA. I think the principle role of IPSEC should be to > provide secure communications between two points - eg provide services for > traffic confidentiality, authentication and integrity between two points. > Access control etc I think should be elsewhere. > > Chris > > > chinna > > > > On Tue, 16 May 2000, Chris Trobridge wrote: > > > > > The point is that with an IPSEC SA traffic is only allowed > > that matches the > > > selector for that SA. In the access control case this > > means you can enforce > > > that anyone who connects via an IPSEC tunnel can only send > > or receive > > > datagrams associated with his client address. This > > prevents him from > > > spoofing other clients or hosts and from receiving traffic > > not addressed to > > > him. > > > > > > The moment you tunnel L2TP through an SA IPSEC loses its > > ability to perform > > > this filtering. Depending on the whether 'extra' work has > > been done, once > > > IPSEC processing has been completed the L2TP layer will not > > know via which > > > SA a datagram was received, allowing a client to spoof > > other addresses. > > > > > > However, I agree with Andrew: The packet filtering in > > IPSEC is rather > > > primitive and would be better provided via an IPSEC aware firewall. > > > > > > Chris > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue May 16 12:00:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21151; Tue, 16 May 2000 12:00:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15350 Tue, 16 May 2000 13:23:52 -0400 (EDT) Date: Tue, 16 May 2000 10:31:00 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Chris Trobridge cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When we use L2TP to provide a VPN link to a user into the private network, it is just emulating as if the user is on the private network. When a user requests for VPN access, he has to authenticate and prove his credentials before he can gain access to private network. Once the user has gained access, he is virtually on the private network. He can do whatever he would be normally allowed to do when he is physically on the private network. So, if your private network allows one user to easily spoof other users, then that is _not_ a failure of the VPN technology, but your security infrastructure in the private network. If anyone else other than the authenticated user, is able to gain access into the private network, then that would be a failure of the VPN technology. That is the beauty of layered security architectures. Each layer does it job, and does it well. No single technology is going to solve all the problems, and I guess no one wants to put all their eggs in one basket. chinna On Tue, 16 May 2000, CHINNA N.R. PELLACURU wrote: > I think that is what most of us feel. > > chinna > > On Tue, 16 May 2000, Chris Trobridge wrote: > > > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > > Sent: 16 May 2000 17:06 > > > To: Chris Trobridge > > > Cc: Stephen Kent; Andrew Krywaniuk; 'Jan Vilhuber'; > > > ipsec@lists.tislabs.com > > > Subject: RE: Windows 2000 and Cicsco router interoperability > > > > > > > > > So, you want filtering in IPSec, but you really think the filtering in > > > IPSec is primitive, and really feel that it should be handled > > > elsewhere! > > > > That's not what I wrote! > > > > There already is strongly coupled filtering, if a little primitive, in > > IPSEC. It is stronger because the filtering ties up the IP addresses with > > the SA selector. This information may be lost if the checking is done > > later. The filtering is primitive because the selector rules don't cope > > with policy like "ftp to host A, pop3 or smtp to host B, or http to hosts C > > or D" - they allow a limited specification of ranges/wildcards. > > > > I don't think the filtering should be done in IPSEC but it should take > > account of the IPSEC SA. I think the principle role of IPSEC should be to > > provide secure communications between two points - eg provide services for > > traffic confidentiality, authentication and integrity between two points. > > Access control etc I think should be elsewhere. > > > > Chris > > > > > chinna > > > > > > On Tue, 16 May 2000, Chris Trobridge wrote: > > > > > > > The point is that with an IPSEC SA traffic is only allowed > > > that matches the > > > > selector for that SA. In the access control case this > > > means you can enforce > > > > that anyone who connects via an IPSEC tunnel can only send > > > or receive > > > > datagrams associated with his client address. This > > > prevents him from > > > > spoofing other clients or hosts and from receiving traffic > > > not addressed to > > > > him. > > > > > > > > The moment you tunnel L2TP through an SA IPSEC loses its > > > ability to perform > > > > this filtering. Depending on the whether 'extra' work has > > > been done, once > > > > IPSEC processing has been completed the L2TP layer will not > > > know via which > > > > SA a datagram was received, allowing a client to spoof > > > other addresses. > > > > > > > > However, I agree with Andrew: The packet filtering in > > > IPSEC is rather > > > > primitive and would be better provided via an IPSEC aware firewall. > > > > > > > > Chris > > > > chinna narasimha reddy pellacuru > s/w engineer > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue May 16 13:17:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22559; Tue, 16 May 2000 13:17:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15748 Tue, 16 May 2000 14:55:31 -0400 (EDT) Message-ID: <39219B57.5DAAF857@F-Secure.com> Date: Tue, 16 May 2000 22:02:47 +0300 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: Qiu Ying , ipsec@lists.tislabs.com Subject: Re: generate certificate in Win2K References: <391FDB28.D3FB2850@krdl.org.sg> <3920243C.36689AE4@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Scott G. Kelly" wrote: > > Qiu Ying wrote: > > > > Hi, > > > > How to generate a pair of keys and certificates in Window 2000 for IKE? > > > > Thanks? > > Questions like this should be directed to microsoft technical support, > rather than to an ietf working group mailing list. True. However, due to the way it is done, it might be of interest to readers of this mailing list too. If it isn't, I apologize. Basically you will need Internet Explorer, and you will need to browse to the Win2000 Certificate Services web page. You then edit a web form and submit it. (I didn't try any CEP thingies, neither did I have a Windows domain.) I found it odd that 1) If you browse to the same certificate services page with Netscape Communicator, the page to create certificates is non-accessible. (Netscape running in another machine in my case.) 2) If you want to use a 3rd party CA via a web page, you will still need both the Internet Explorer and the Win2000 Certificate Services installed. That's because the only way to get a cert request to a file is via the CertSrv web page. 3) I'm not quite sure whether the server side or the client side of this web connection actually creates the keys. Anybody know? 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-ipsec@lists.tislabs.com Tue May 16 14:14:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23559; Tue, 16 May 2000 14:14:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16025 Tue, 16 May 2000 16:03:20 -0400 (EDT) Message-ID: <3921AB39.F854611@cisco.com> Date: Tue, 16 May 2000 16:10:33 -0400 From: "W. Mark Townsley" Organization: cisco Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: Jan Vilhuber , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > At 11:41 AM -0700 5/14/00, Jan Vilhuber wrote: > >In some people's minds, it's an acceptable trade-off, and others wil think > >differently. > > > >Personally, I don't see much difference with doing a check after decryption > >and decapsulation, than doing it before. Yes, you may loose some context, but > >so what. > > > >You can either burden IKE and IPSEC with a whole bunch more mechanisms for > >user-authentication, authorization, and accounting, thus making the protocols > >even MORE complex (and thus less likely to be completely understood and > >analyzed for weaknesses), OR you can combine two simple (relatively) > >mechanisms, and combine them. In fact, it precisely because I DON'T want to > >revisit these protocols, that I'm advocating l2tp+ipsec. > > > >The loss of security you claim exists there, I don't see. > > > >jan > > As I noted, if one has lost the binding between a packet and the SA > via which it arrived, because the access control decision is being Ah, but the binding is not lost. As I have said to you and on this list before, there is a 1:1 correlation between the SA, the l2tp session, the "user-authorized" PPP session, and thus the access control and policy for that user. This is key to the way l2tp+ipsec is intended to operate. If you wish, we could even include a section in the l2tp-security draft that spells this out in a more direct manner. The omission of this specific text is only due to the fact that it so plainly obvious to those who have lived and worked in the traditional dialup space for years. Perhaps it is this kind of input we need, however, to ensure that we cover all points of reference. > made outside the IPsec module, then this decision is being made based > on unauthenticated inputs, which is no better than what one gets from > a typical firewall w/o IPsec. I'd say this is a significant > degradation of the security potential offered by IPsec. > > Steve From owner-ipsec@lists.tislabs.com Tue May 16 14:54:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24679; Tue, 16 May 2000 14:54:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16138 Tue, 16 May 2000 16:42:10 -0400 (EDT) Message-ID: <3921B453.E9572D4E@cisco.com> Date: Tue, 16 May 2000 16:49:23 -0400 From: "W. Mark Townsley" Organization: cisco Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote: > >I can't speak for the whole of Cisco, but the way I look at it is: > > > >Modeconfig/Xauth are being supported as quick hack to get something to > >work, and get something to customers, until there is a client that can do > >IPSec and L2TP. > > > >I beleive that it is not our long term vision, to ship Modeconfig/Xauth. I > >beleive that Cisco's long term goal is to follow whatever is standardized > >in the IPSRA WG, because that's what IPSRA WG is chartered to solve. > > > > That's one view. > > Another perspective is that L2TP over IPsec represents an effort by > Microsoft & Cisco to preserve a joint development investment in L2TP, > irrespective of its technical merit in this context :-). If I am Please allow me to dispose of this view with some facts. First, L2TP is a standards track document that has support of many vendors, of which cisco and Microsoft are only two. Further, the fact that L2TP exists and is supported by both companies you single out is actually a tribute to support of IETF standards by each in the face of significant opposing development efforts. Clearly, if either were to try and capitalize on past development efforts as you suggest, L2TP would not exist and the world would have to choose between cisco's support of L2F and Microsoft's support of PPTP (each joint development efforts in their own right). No IETF. No standard RFC. Creation of L2TP and support of it is precisely the opposite of what you are claiming. Here Microsoft and cisco are both championing support of an IETF standard protocol, in direct opposition to that which each developed in-house and deployed first, and you are still being branding both as evil? > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > then the extra headers introduced by L2TP are not only wasteful of > bandwidth on a continuing basis, but they also interfere with the Let's talk facts again. On a highly scaled, high bandwidth system, header size becomes increasingly less important. Over slow dialup lines, of course, it is worthwhile to try and get the header as small as possible. Negotiate PPP ACFC and PFC, and you get 1 byte of PPP header. L2TP's typical header for a voluntary tunnel would be either 6 bytes, or perhaps even 1 byte if you perform l2tphc. 2 bytes (or even 7 bytes w/o l2tphc) of overhead for l2tp and ppp is small potatoes compared to ESP tunnel mode on each packet. Also, you get all sorts of nifty things that PPP is working on to reduce overhead. For instance, draft-ietf-pppext-pppmux-00.txt allows you to frame small packets into a single PPP frame. Given IPsec's large header, multiplexing small packets into a single frame before encrypting and tunneling could result in a *significant* header overhead reduction. Care to add that to IPsec's repertoire of features too? > access controls that are an essential part of IPsec. One needs some > means of dealing with bind time connection parameters, but use of > L2TP on a continuing basis is an expensive means of achieving this > goal. > > Steve From owner-ipsec@lists.tislabs.com Tue May 16 15:05:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25053; Tue, 16 May 2000 15:05:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16203 Tue, 16 May 2000 16:54:32 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 16 May 2000 14:00:55 -0700 (PDT) From: Jan Vilhuber Reply-To: Jan Vilhuber To: ipsec@lists.tislabs.com cc: wdixon@Exchange.Microsoft.com Subject: more microsoft policy issues? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From an email I just saw going across my desk: > Even though the "do not use IPSec" is marked in the W2000 configuration the > W2000 client still uses IPSec. Please note in Windows 2000 build 2195 > Microsoft have decided to use IPSec all the time. Come on, guys! Please tell me that THIS at least is a bug, and not another one of those design decisions... jan P.S. Caveat: I don't have any idea of build numbers. Maybe 2195 is really old and this is already fixed... -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue May 16 15:05:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25067; Tue, 16 May 2000 15:05:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16198 Tue, 16 May 2000 16:54:04 -0400 (EDT) Message-ID: <3921B71C.C7F3FD14@cisco.com> Date: Tue, 16 May 2000 17:01:16 -0400 From: "W. Mark Townsley" Organization: cisco Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Trobridge CC: "CHINNA N.R. PELLACURU" , Stephen Kent , Andrew Krywaniuk , "'Jan Vilhuber'" , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: <1FD60AE4DB6CD2118C420008C74C27B854A364@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chris Trobridge wrote: > > The point is that with an IPSEC SA traffic is only allowed that matches the > selector for that SA. In the access control case this means you can enforce > that anyone who connects via an IPSEC tunnel can only send or receive > datagrams associated with his client address. This prevents him from > spoofing other clients or hosts and from receiving traffic not addressed to > him. > > The moment you tunnel L2TP through an SA IPSEC loses its ability to perform > this filtering. Depending on the whether 'extra' work has been done, once > IPSEC processing has been completed the L2TP layer will not know via which > SA a datagram was received, allowing a client to spoof other addresses. Why not? An SA protects an l2tp tunnel, which carries a PPP session, which performed user authentication and authorization. Such authorization is the basis for access control lists that can do a number of L3 checks on the traffic which PPP framed. Here, a direct correlation between a given SA, the authenticated user, and finally her authorization for the network. ISPs and enterprises have been doing filter checks on incoming PPP encapsulated data for years. The requirements for such have evolved considerably over this time. I doubt that they want to toss this functionality out the door and I cannot blame them. > > However, I agree with Andrew: The packet filtering in IPSEC is rather > primitive and would be better provided via an IPSEC aware firewall. > > Chris > > > -----Original Message----- > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > Sent: 16 May 2000 07:31 > > To: Stephen Kent > > Cc: Andrew Krywaniuk; 'Jan Vilhuber'; ipsec@lists.tislabs.com > > Subject: RE: Windows 2000 and Cicsco router interoperability > > > > > > Frankly, I don't understand what Andrew is trying to tell me. > > His bottom > > line was: > > > > "IMHO, the idea with the most technical merit is to remove packet > > filtering from IPsec and make the firewalls IPsec aware. (No, I'm not > > saying we should rewrite all the specs; that's just the > > *ideal* solution > > in my mind.) > > > > All clear now?" !!! > > > > Anyway, regarding access control: > > > > How many people beleive that the IPSec access control > > mechanism, is going > > to solve all our access control problems? > > > > If people beleived that IPSec access control mechanism solves > > all their > > access control problems, then I guess we wouldn't have a need > > to leverage > > the access control features that AAA provides. I have seen > > customers who > > are so fond of their AAA infrastructure, that they by-pass IKE > > authentication by using an equivalent of a global pre-shared key! and > > totally base their authentication on AAA authentication(and > > if you do this > > via xauth, that doesn't authenticate the DH exchange)! Let's > > face it, how > > many implementations support some form of global pre-shared key? > > Supposedly the customers wants this badly, and if we dont > > provide this, > > there are implementations that already provide this! > > > > To investigate the cryptographic binding between a packet > > that has been > > decapsulated, and to which the IPSec selector has to be applied, lets > > start by how the binding took form at the encapsulation side > > in the first > > place. At the encapsulation side, in the context on an IPSec > > implementaion, we have a selector based on IP Addresses, protocol and > > ports. Once a packet matches this selector, it is > > encapsulated, and that > > is all IPSec can truly enforce. Are you saying that this is > > all we need to > > enforce all kinds of access control requirements, and complex policies > > that any corporation can have? > > > > It's not just the access control folks that see IPSec as a nuance, but > > there are the Intrution Detection (ID) folks. If we do end to end > > security, IE from the client of some service to the server of that > > service, the ID folks don't like that. If we had an IPSec > > selector that > > says all traffic from any TCP high port to port 21 needs to be secured > > with a certain policy, it doesn't stop a legitimate user/a hacker who > > gained control of the system to do a simple TCP SYN flood > > attack. If this > > traffic was encrypted using IPSec, then there is no way that > > the Intrution > > Detection System (IDS), is going to detect this. So, these guys have a > > requirement that all IPSec tunnels should terminate on the > > perimeter of > > the network, so that these guys can do their job. I guess, someone is > > busy, out there trying to integrate ID into IPSec. xids? Then > > we can have > > xauth, xauthr, xacc, xids, mode config etc... and we can update these > > documents once every 6 months, to incorporate/support more and more > > features of these protocols. There are supposedly 6 > > versions(revisions) of > > the draft that we already have, and different vendors support > > different > > versions. I leart today that we support version 3 on the cisco router. > > I guess we are just waiting for some customer to bang on our heads, > > demanding that they want version 6 because it has a feature x > > that version > > 3 cannot support. > > > > chinna > > > > On Tue, 16 May 2000, Stephen Kent wrote: > > > > > Chinna, > > > > > > Go back an reread the last few messages I have sent describing the > > > difference between what native IPsec does vs. what any > > standard says > > > about L2TP over IPsec re access control. That is the basis for my > > > comments and those of Andrew. > > > > > > Steve > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > > > > > > > From owner-ipsec@lists.tislabs.com Tue May 16 19:17:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12672; Tue, 16 May 2000 19:17:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17054 Tue, 16 May 2000 21:04:50 -0400 (EDT) Date: Tue, 16 May 2000 20:12:35 -0500 From: Will Fiveash To: IETF IPSec Subject: HTML in mail on list Message-ID: <20000516201235.D52068@austin.ibm.com> Mail-Followup-To: IETF IPSec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't want to start a long thread on this but I'm requesting that folks try not to auto-attach HTML that states the same thing as in the text body of their messages. These messages are over twice as long as they should be because of this. So check your setting on Outlook or Navigator and make sure the setting for including HTML are off. Okay, so I'm AR. I'm also on a number of mail lists and the archives are getting big. ;^) -- Will Fiveash IBM AIX System Development From owner-ipsec@lists.tislabs.com Tue May 16 19:17:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12673; Tue, 16 May 2000 19:17:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17073 Tue, 16 May 2000 21:19:05 -0400 (EDT) Date: Tue, 16 May 2000 18:26:14 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Andrew Krywaniuk cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: <000901bfbf56$a6372df0$d23e788a@andrewk3.timestep.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sorry... Just for the record, I would like to clarify some things: First of all, if you step back and see, I wasn't the one who dragged you into this particular sub thread. Second of all, in whatever context you said the stuff that I quoted, it still applies to this sub thread, and I guess was referred to first, not by me. Third of all, you don't want to get into this debate: point taken. Lastly, for the good of everyone, let's follow atleast the basic email etiquette. chinna On Tue, 16 May 2000, Andrew Krywaniuk wrote: > As Mister T. would say, "Stop you rantin, foo." > > My bottom line (which may have inadvertently appeared at the top of my > message) was: > > "Sorry, but this has nothing to do with Config Mode or XAuth and very little > to do with L2TP specifically." > > If you want to turn this into a debate about everything and anything then > you'll excuse me while I step outside. > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of CHINNA > > N.R. PELLACURU > > Sent: Tuesday, May 16, 2000 2:31 AM > > To: Stephen Kent > > Cc: Andrew Krywaniuk; 'Jan Vilhuber'; ipsec@lists.tislabs.com > > Subject: RE: Windows 2000 and Cicsco router interoperability > > > > > > Frankly, I don't understand what Andrew is trying to tell me. > > His bottom > > line was: > > > > "IMHO, the idea with the most technical merit is to remove packet > > filtering from IPsec and make the firewalls IPsec aware. (No, I'm not > > saying we should rewrite all the specs; that's just the > > *ideal* solution > > in my mind.) > > > > All clear now?" !!! > > > > Anyway, regarding access control: > > > > How many people beleive that the IPSec access control > > mechanism, is going > > to solve all our access control problems? > > > > If people beleived that IPSec access control mechanism solves > > all their > > access control problems, then I guess we wouldn't have a need > > to leverage > > the access control features that AAA provides. I have seen > > customers who > > are so fond of their AAA infrastructure, that they by-pass IKE > > authentication by using an equivalent of a global pre-shared key! and > > totally base their authentication on AAA authentication(and > > if you do this > > via xauth, that doesn't authenticate the DH exchange)! Let's > > face it, how > > many implementations support some form of global pre-shared key? > > Supposedly the customers wants this badly, and if we dont > > provide this, > > there are implementations that already provide this! > > > > To investigate the cryptographic binding between a packet > > that has been > > decapsulated, and to which the IPSec selector has to be applied, lets > > start by how the binding took form at the encapsulation side > > in the first > > place. At the encapsulation side, in the context on an IPSec > > implementaion, we have a selector based on IP Addresses, protocol and > > ports. Once a packet matches this selector, it is > > encapsulated, and that > > is all IPSec can truly enforce. Are you saying that this is > > all we need to > > enforce all kinds of access control requirements, and complex policies > > that any corporation can have? > > > > It's not just the access control folks that see IPSec as a nuance, but > > there are the Intrution Detection (ID) folks. If we do end to end > > security, IE from the client of some service to the server of that > > service, the ID folks don't like that. If we had an IPSec > > selector that > > says all traffic from any TCP high port to port 21 needs to be secured > > with a certain policy, it doesn't stop a legitimate user/a hacker who > > gained control of the system to do a simple TCP SYN flood > > attack. If this > > traffic was encrypted using IPSec, then there is no way that > > the Intrution > > Detection System (IDS), is going to detect this. So, these guys have a > > requirement that all IPSec tunnels should terminate on the > > perimeter of > > the network, so that these guys can do their job. I guess, someone is > > busy, out there trying to integrate ID into IPSec. xids? Then > > we can have > > xauth, xauthr, xacc, xids, mode config etc... and we can update these > > documents once every 6 months, to incorporate/support more and more > > features of these protocols. There are supposedly 6 > > versions(revisions) of > > the draft that we already have, and different vendors support > > different > > versions. I leart today that we support version 3 on the cisco router. > > I guess we are just waiting for some customer to bang on our heads, > > demanding that they want version 6 because it has a feature x > > that version > > 3 cannot support. > > > > chinna > > > > On Tue, 16 May 2000, Stephen Kent wrote: > > > > > Chinna, > > > > > > Go back an reread the last few messages I have sent describing the > > > difference between what native IPsec does vs. what any > > standard says > > > about L2TP over IPsec re access control. That is the basis for my > > > comments and those of Andrew. > > > > > > Steve > > > > > > > chinna narasimha reddy pellacuru > > s/w engineer > > > > > > > > > > > > > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue May 16 19:19:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA12994; Tue, 16 May 2000 19:19:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA17009 Tue, 16 May 2000 20:47:55 -0400 (EDT) Date: Tue, 16 May 2000 19:55:37 -0500 From: Will Fiveash To: IETF IPSec Subject: Beating the dead horse (responder life notify questions) Message-ID: <20000516195537.B52068@austin.ibm.com> Mail-Followup-To: IETF IPSec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.14i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am in the process of refining the AIX code to behave better when negotiating lifetime (for time and size types). Of course I have a few questions (it wouldn't be IKE development otherwise ;^): 1. Is anyone using NOTIFY-SA-LIFETIME to notify the initiator that a smaller lifetime is being used by the responder in Phase 1 negotiations? I noticed that Dan Harkin mentioned in some earlier ipsec-list e-mail that: "But that only works with phase 2 negotiation because RFC2409, sadly, does not define a notify message analogous to the DOI's RESPONDER-LIFETIME. So the only options for phase 1 are 1 or 2: fail the negotiation or just ignore what the operator has configured. One of the action items from http://www.lounge.org/ike_doi_errata.html is to rectify that though." So from this I'm thinking I shouldn't send a lifetime notify in Phase 1 but I wasn't sure if folks were implementing draft-ietf-ipsec-notifymsg-02.txt which describes NOTIFY-SA-LIFETIME. 2. If in Phase 2, the responder receives both seconds and KB lifetimes and wants to reduce both, should it append a RESPONDER-LIFETIME notify to the quickmode reply and place all the life attributes (for seconds and KB) in the Notification Data section encoded in a manner similar to attributes in a transform payload? I'm also a little confused by the following statement in RFC2407 (Internet IPSec DOI): Implementation Note: saying that the Notification Data field contains an attribute list is equivalent to saying that the Notification Data field has zero length and the Notification Payload has an associated attribute list. Why does the Notification Data field have 0 length when sending a list of attributes? I thought the Notification Data field would contain the attributes since there isn't an separate attribute payload (at least not in RFC2408). Okay, I'll stop now. -- Will Fiveash IBM AIX System Development From owner-ipsec@lists.tislabs.com Tue May 16 20:06:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA18741; Tue, 16 May 2000 20:06:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17171 Tue, 16 May 2000 21:54:28 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4366.0 content-class: urn:content-classes:message Subject: RE: more microsoft policy issues? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFBFA3.882066A4" Date: Tue, 16 May 2000 18:59:27 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2FFC3E1@fifi.platinum.corp.microsoft.com> Thread-Topic: more microsoft policy issues? Thread-Index: Ab+/ezBOnWhoy8tqR8mVEN3ingOi8wAIxYdg From: "William Dixon" To: "Jan Vilhuber" , X-OriginalArrivalTime: 17 May 2000 02:02:16.0990 (UTC) FILETIME=[ED34D3E0:01BFBFA3] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFBFA3.882066A4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Jan, posting this without context is just inflammatory. If it makes you happy, send flame to me personally. The list isn't here to discuss product bugs, postulate on what may be a bug, nor complain about the wording on dialogs. The news group for Windows 2000 networking functionality in general is: microsoft.public.win2000.networking Or you can email NTBUGTRAQ to report verified problems or email secure@microsoft.com to get a formal corporate response to a discovered security weakness for any Microsoft product. This setting is in the advanced properties of the TCPIP properties and allows a local admin to select a default IPSec policy. By default the selection is says in text "Do not use IPSec". This is a local setting which can be overridden by Win2k domain IPSec policy, and by OS components such as L2TP which require IPSec for their operation. And once again, the behavior is documented in online help and elsewhere. The TCPIP properties UI is a quick and easy way for an admin to change between different custom policies that have been created on the local system. As one of our KB articles notes, we provide the default policies as an example only, for initial testing only - real production use requires your own custom designed IPSec policy. =20 -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Tuesday, May 16, 2000 2:01 PM To: ipsec@lists.tislabs.com Cc: William Dixon Subject: more microsoft policy issues? >From an email I just saw going across my desk: > Even though the "do not use IPSec" is marked in the W2000 configuration the > W2000 client still uses IPSec. Please note in Windows 2000 build 2195 > Microsoft have decided to use IPSec all the time. Come on, guys! Please tell me that THIS at least is a bug, and not another one of those design decisions... jan P.S. Caveat: I don't have any idea of build numbers. Maybe 2195 is really old and this is already fixed... -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 ------_=_NextPart_001_01BFBFA3.882066A4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: more microsoft policy issues?

Jan, posting this without context is just = inflammatory.  If it makes you happy, send flame to me = personally.  The list isn't here to discuss product bugs, postulate = on what may be a bug, nor complain about the wording on = dialogs.

The news group for Windows 2000 networking = functionality in general is: microsoft.public.win2000.networking

Or you can email NTBUGTRAQ to report verified problems = or email secure@microsoft.com to get a formal corporate response to a = discovered security weakness for any Microsoft product.

This setting is in the advanced properties of the = TCPIP properties and allows a local admin to select a default IPSec = policy.  By default the selection is says in text "Do not use = IPSec".  This is a local setting which can be overridden by = Win2k domain IPSec policy, and by OS components such as L2TP which = require IPSec for their operation.  And once again, the behavior is = documented in online help and elsewhere.  The TCPIP properties UI = is a quick and easy way for an admin to change between different custom = policies that have been created on the local system.

As one of our KB articles notes, we provide the = default policies as an example only, for initial testing only - real = production use requires your own custom designed IPSec policy.  =


-----Original Message-----
From: Jan Vilhuber [mailto:vilhuber@cisco.com]
Sent: Tuesday, May 16, 2000 2:01 PM
To: ipsec@lists.tislabs.com
Cc: William Dixon
Subject: more microsoft policy issues?


From an email I just saw going across my desk:

> Even though the "do not use IPSec" is = marked in the W2000 configuration the
> W2000 client still uses IPSec.  Please note = in Windows 2000 build 2195
> Microsoft have decided to use IPSec all the = time.

Come on, guys! Please tell me that THIS at least is a = bug, and not another one
of those design decisions...

jan
P.S. Caveat: I don't have any idea of build numbers. = Maybe 2195 is really old
and this is already fixed...
 --
Jan = Vilhuber           = ;            =             &= nbsp;        = vilhuber@cisco.com
Cisco Systems, San = Jose           &nb= sp;           &nbs= p;            = ; (408) 527-0847

------_=_NextPart_001_01BFBFA3.882066A4-- From owner-ipsec@lists.tislabs.com Tue May 16 20:14:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19618; Tue, 16 May 2000 20:14:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17210 Tue, 16 May 2000 22:11:11 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 16 May 2000 19:17:34 -0700 (PDT) From: Jan Vilhuber To: William Dixon cc: ipsec@lists.tislabs.com Subject: RE: more microsoft policy issues? In-Reply-To: <6A05D00595BE644E9F435BE5947423F2FFC3E1@fifi.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 16 May 2000, William Dixon wrote: > Jan, posting this without context is just inflammatory. If it makes you > happy, send flame to me personally. The list isn't here to discuss > product bugs, postulate on what may be a bug, nor complain about the > wording on dialogs. > Sorry. That's all the context I had. Maybe I was a bit hasty (in view of the recent thread). If so, I apologize. Reading the rest below, though, it sounds like if the OS can override a local decision, then you again have a scenario where I click on a choice, and win2k overrides me without telling me. Bad. I mean, what would YOU expect, if you said: Don't do ipsec. *I* would expect that ipsec will not be performed. At all. Ever. And I wasn't venting about a product bug, either (although I was hoping it would turn out to be one). it's the gratuitous overriding of user-selected policy that was the issue I meant to address. jan > The news group for Windows 2000 networking functionality in general is: > microsoft.public.win2000.networking > > Or you can email NTBUGTRAQ to report verified problems or email > secure@microsoft.com to get a formal corporate response to a discovered > security weakness for any Microsoft product. > > This setting is in the advanced properties of the TCPIP properties and > allows a local admin to select a default IPSec policy. By default the > selection is says in text "Do not use IPSec". This is a local setting > which can be overridden by Win2k domain IPSec policy, and by OS > components such as L2TP which require IPSec for their operation. And > once again, the behavior is documented in online help and elsewhere. > The TCPIP properties UI is a quick and easy way for an admin to change > between different custom policies that have been created on the local > system. > > As one of our KB articles notes, we provide the default policies as an > example only, for initial testing only - real production use requires > your own custom designed IPSec policy. > > > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Tuesday, May 16, 2000 2:01 PM > To: ipsec@lists.tislabs.com > Cc: William Dixon > Subject: more microsoft policy issues? > > > >From an email I just saw going across my desk: > > > Even though the "do not use IPSec" is marked in the W2000 > configuration the > > W2000 client still uses IPSec. Please note in Windows 2000 build 2195 > > Microsoft have decided to use IPSec all the time. > > Come on, guys! Please tell me that THIS at least is a bug, and not > another one > of those design decisions... > > jan > P.S. Caveat: I don't have any idea of build numbers. Maybe 2195 is > really old > and this is already fixed... > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose (408) > 527-0847 > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue May 16 22:07:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28758; Tue, 16 May 2000 22:07:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17476 Tue, 16 May 2000 23:51:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 16 May 2000 23:55:47 -0400 To: "CHINNA N.R. PELLACURU" From: Stephen Kent Subject: RE: Windows 2000 and Cicsco router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chinna, >Frankly, I don't understand what Andrew is trying to tell me. His bottom >line was: > >"IMHO, the idea with the most technical merit is to remove packet >filtering from IPsec and make the firewalls IPsec aware. (No, I'm not >saying we should rewrite all the specs; that's just the *ideal* solution >in my mind.) > >All clear now?" !!! It's always a delight to see enthusiastic support for a position from someone new to this WG. Unfortunately, such enthusiasm is often unencumbered by knowledge of the WG history, or even technical depth, on the issue in question. This seems to be such a case. > >Anyway, regarding access control: > >How many people beleive that the IPSec access control mechanism, is going >to solve all our access control problems? That's not the question before us. No single security mechanism is a panacea. What we are discussing are the relative merits of two different approaches to effecting a particular type of access control. >If people beleived that IPSec access control mechanism solves all their >access control problems, then I guess we wouldn't have a need to leverage >the access control features that AAA provides. I have seen customers who >are so fond of their AAA infrastructure, that they by-pass IKE >authentication by using an equivalent of a global pre-shared key! and >totally base their authentication on AAA authentication(and if you do this >via xauth, that doesn't authenticate the DH exchange)! Let's face it, how >many implementations support some form of global pre-shared key? >Supposedly the customers wants this badly, and if we dont provide this, >there are implementations that already provide this! The "features that AAA provides?" AAA is a WG but there are no AAA standards yet. In fact, the WG drafts so far focusing only on requirements for the protocols that will be standardized, in the future. So a reference to what "AAA provides" or to "customers who are so fond of their AAA infrastructure" appears to be in the future, optimistic tense. AAA, when it exists, will encompass authentication as well as access control. We are focusing on the access control aspect of IPsec. Global pre-shared keys are an easy way to deploy IKE, but that does not make them a good idea. It is understandable that customers want to employ IPsec but also want to minimize the costs of deploying it. The desire to make use of an existing user authentication infrastructure is also understandable in this context, but is separable from the access control mechanisms we are discussing. >To investigate the cryptographic binding between a packet that has been >decapsulated, and to which the IPSec selector has to be applied, lets >start by how the binding took form at the encapsulation side in the first >place. At the encapsulation side, in the context on an IPSec >implementaion, we have a selector based on IP Addresses, protocol and >ports. Once a packet matches this selector, it is encapsulated, and that >is all IPSec can truly enforce. Are you saying that this is all we need to >enforce all kinds of access control requirements, and complex policies >that any corporation can have? You seem to have trouble distinguishing between access control enforcement mechanisms and access control policies. The policies that an IPsec implementation can enforce is limited to the inputs available to an IPsec implementation. The set of information differs in native host vs. security gateway implementations. I believe that we're discussing the latter here. The 5 primary selectors from the IP and TCP header are the only inputs available to the SG for enforcement, on a steady state basis. (I'm omitting the security labels, which are not required for most implementations, and the user/system IDs that are not employed on a steady state basis.) However, while RFC 2401 specifies a minimum access control policy capability for any IPsec implementation, there is no prohibition against more sophisticated policies being employed, subject to the constraint that the enforcement parameters can be translated into these selectors. For example, if one wants to include time of day as an input to an access control decision, e.g., limiting the times at which an SA can be established, one could do that external to the enforcement mechanism. Certainly one can usefully employ access control policies that are application specific, and which cannot be enforced at the Internet layer. However, that does not imply that Internet layer policies and enforcement mechanisms are irrelevant. Several folks have suggested that one might choose to enforce access control at the IP layer, but not in the context of IPsec, e.g., by passing SA info to a separate firewall for post IPsec checking. If the firewall is part of the same device as the IPsec module, the this can be effected in a local fashion that would be consistent with 2401, as the management interface for the combined firewall/SG would have the necessary properties. However, if the firewall is in a separate device, I think the required co-ordination would become very expensive. For example, for outbound traffic, the SG must map packets to SAs, or know when to create an SA for traffic. If the firewall does this mapping for the SG, we would need to define a way to pass the SPD entry info across a wire to the SG from the firewall. Also, the SG would have to provide a reverse channel to keep the firewall aware of the SA status, e.g., based on SA timeouts, IKE failures, etc. Conversely, if the SG maintains the SPD locally (as is the current practice), then there needs to be a new management mechanism to synchronize these databases. In the reverse direction, if the SG no longer performs the post processing access control checks required by 2401, then it was suggested that we need to define some means of passing SA data to the firewall. In fact, it appears that we need to pass quite a bit of data. Just passing the SPI is not sufficient, unless we introduce a reverse channel from the SG to the firewall so that the firewall can mirror the SAD (not just the SPD). Also, how do we pass the SPI or similar data for each packet? Is there a way to do this without breaking the stack on the firewall, and what will the performance impact be based on whatever way we find to pass this info? I'm not saying that one cannot split the access control checks between an SG and a firewall, but I do think that the complexity associated with such a split has been underestimated. >It's not just the access control folks that see IPSec as a nuance, but "Nuance" vs. "nuisance?" >there are the Intrution Detection (ID) folks. If we do end to end >security, IE from the client of some service to the server of that >service, the ID folks don't like that. This argument is irrelevant to the discussion, but I'll respond anyway. End-to-end encryption of any form (IPsec, SSL/TLS, SSH, or S/MIME) interferes with network-based ID, but the host-based ID still work. Since tests by Lincoln Labs show that network based ID is at best about 80% effective at detecting KNOWN attacks, whereas the best host-based systems are much better, I'm not too concerned by this limitation. >If we had an IPSec selector that >says all traffic from any TCP high port to port 21 needs to be secured >with a certain policy, it doesn't stop a legitimate user/a hacker who >gained control of the system to do a simple TCP SYN flood attack. If this >traffic was encrypted using IPSec, then there is no way that the Intrution >Detection System (IDS), is going to detect this. So, these guys have a >requirement that all IPSec tunnels should terminate on the perimeter of >the network, so that these guys can do their job. I guess, someone is >busy, out there trying to integrate ID into IPSec. xids? Then we can have >xauth, xauthr, xacc, xids, mode config etc... and we can update these >documents once every 6 months, to incorporate/support more and more >features of these protocols. There are supposedly 6 versions(revisions) of >the draft that we already have, and different vendors support different >versions. I leart today that we support version 3 on the cisco router. >I guess we are just waiting for some customer to bang on our heads, >demanding that they want version 6 because it has a feature x that version >3 cannot support. The threat model you cite re TCP SYN flooding is unduly constrained, and not very convincing. SYN flood attacks are effected by spoofing the source address; in the case you cite, we know precisely where the packets are coming from, and an analysis of the log at the targeted host would show that, assuming that the packets emerging from the SA were checked by IPsec to verify the source address consistency. Your fear of the letter "x" seems to be getting the better of you, i.e., it's distracting you from the argument at hand :-). There's nothing to comment on in this last paragraph. Steve From owner-ipsec@lists.tislabs.com Tue May 16 22:26:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29899; Tue, 16 May 2000 22:26:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17589 Wed, 17 May 2000 00:16:21 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3921B453.E9572D4E@cisco.com> References: <3921B453.E9572D4E@cisco.com> Date: Wed, 17 May 2000 00:23:13 -0400 To: "W. Mark Townsley" From: Stephen Kent Subject: Re: Windows 2000 and Cicsco router interoperability Cc: "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Mark, >Please allow me to dispose of this view with some facts. First, L2TP is >a standards track document that has support of many vendors, of which >cisco and Microsoft are only two. > >Further, the fact that L2TP exists and is supported by both companies >you single out is actually a tribute to support of IETF standards by >each in the face of significant opposing development efforts. Clearly, >if either were to try and capitalize on past development efforts as you >suggest, L2TP would not exist and the world would have to choose between >cisco's support of L2F and Microsoft's support of PPTP (each joint >development efforts in their own right). No IETF. No standard RFC. My understanding of the history, is that L2TP represents a detente agreement between MS and Cisco in this arena, which was then brought to the IETF for standardization. PPTP, and it's impressive security complement, MPPEP, make for a laughable combination. I don't know what Cisco envisioned as security for L2F, but it is clear that the IESG mandated that L2TP not progress without a credible security component, and so LT2P adopted IPsec, but in a fashion that is architectually questionable. >Creation of L2TP and support of it is precisely the opposite of what you >are claiming. Here Microsoft and cisco are both championing support of >an IETF standard protocol, in direct opposition to that which each >developed in-house and deployed first, and you are still being branding >both as evil? Calling MS evil would be stating the obvious, as so many recent events have illustrated :-). > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > then the extra headers introduced by L2TP are not only wasteful of > > bandwidth on a continuing basis, but they also interfere with the > >Let's talk facts again. On a highly scaled, high bandwidth system, >header size becomes increasingly less important. Over slow dialup lines, >of course, it is worthwhile to try and get the header as small as >possible. Negotiate PPP ACFC and PFC, and you get 1 byte of PPP header. >L2TP's typical header for a voluntary tunnel would be either 6 bytes, or >perhaps even 1 byte if you perform l2tphc. > >2 bytes (or even 7 bytes w/o l2tphc) of overhead for l2tp and ppp is >small potatoes compared to ESP tunnel mode on each packet. > >Also, you get all sorts of nifty things that PPP is working on to reduce >overhead. For instance, draft-ietf-pppext-pppmux-00.txt allows you to >frame small packets into a single PPP frame. Given IPsec's large header, >multiplexing small packets into a single frame before encrypting and >tunneling could result in a *significant* header overhead reduction. >Care to add that to IPsec's repertoire of features too? Reasonable points re my per packet overhead criticism, although the excess is still just wasted space, whereas the ESP header is essential for the function in question. Still, from a single, dialup host, it's not clear under what circumstances the multi-packet muxing will be invoked. Steve From owner-ipsec@lists.tislabs.com Tue May 16 22:27:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29956; Tue, 16 May 2000 22:27:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17460 Tue, 16 May 2000 23:45:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Tue, 16 May 2000 13:27:24 -0400 To: "CHINNA N.R. PELLACURU" From: Stephen Kent Subject: RE: Windows 2000 and Cicsco router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:47 PM -0700 5/15/00, CHINNA N.R. PELLACURU wrote: >And BTW, a global pre-shared key is the key technology that enables >centralized policy management, and the whole idea of the server >downloading policy to the dumb clients via modeconfig!!!!!!!!!!!! And this >supposedly also elimanates the overhead of double authentication, when >doing xauth!!!!!! So, if you think that you already know all the overheads >that these protocols eliminate, please think again. > > chinna The choice of user or host authentication mechanism is neither an enabler of nor an impediment to the use of centralized policy management. You seem to be confusing authentication with authorization. Perhaps that's the insidious influence of believing in the supremacy of AAA? Also, your exclamation point key seems to be sticky; have it fixed. Steve From owner-ipsec@lists.tislabs.com Tue May 16 22:40:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA00929; Tue, 16 May 2000 22:40:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17671 Wed, 17 May 2000 00:30:19 -0400 (EDT) Message-ID: <3922220C.6C99039A@cisco.com> Date: Wed, 17 May 2000 00:37:32 -0400 From: "W. Mark Townsley" Organization: cisco Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: <3921AB39.F854611@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > >Mark, > > >Ah, but the binding is not lost. As I have said to you and on this list > >before, there is a 1:1 correlation between the SA, the l2tp session, the > >"user-authorized" PPP session, and thus the access control and policy > >for that user. This is key to the way l2tp+ipsec is intended to operate. > >If you wish, we could even include a section in the l2tp-security draft > >that spells this out in a more direct manner. The omission of this > >specific text is only due to the fact that it so plainly obvious to > >those who have lived and worked in the traditional dialup space for > >years. Perhaps it is this kind of input we need, however, to ensure that > >we cover all points of reference. > > And, I have noted before, we have only the assurance of vendors on > this important security issue, because no RFCcs specify how this is > done. Personally, I'm more comfortable with a standards-specified > approach to such security critical issues, rather than the assurances > I have received from the L2TP community that "well, everybody does > the right thing in their products and we all know it ..." Point taken. We will make efforts to ensure that as much common knowledge as possible in this arena is documented for review and critique. > > Steve From owner-ipsec@lists.tislabs.com Tue May 16 22:41:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA00971; Tue, 16 May 2000 22:41:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17583 Wed, 17 May 2000 00:16:17 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3921AB39.F854611@cisco.com> References: <3921AB39.F854611@cisco.com> Date: Wed, 17 May 2000 00:14:28 -0400 To: "W. Mark Townsley" From: Stephen Kent Subject: Re: Windows 2000 and Cicsco router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Mark, >Ah, but the binding is not lost. As I have said to you and on this list >before, there is a 1:1 correlation between the SA, the l2tp session, the >"user-authorized" PPP session, and thus the access control and policy >for that user. This is key to the way l2tp+ipsec is intended to operate. >If you wish, we could even include a section in the l2tp-security draft >that spells this out in a more direct manner. The omission of this >specific text is only due to the fact that it so plainly obvious to >those who have lived and worked in the traditional dialup space for >years. Perhaps it is this kind of input we need, however, to ensure that >we cover all points of reference. And, I have noted before, we have only the assurance of vendors on this important security issue, because no RFCcs specify how this is done. Personally, I'm more comfortable with a standards-specified approach to such security critical issues, rather than the assurances I have received from the L2TP community that "well, everybody does the right thing in their products and we all know it ..." Steve From owner-ipsec@lists.tislabs.com Tue May 16 22:45:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA01150; Tue, 16 May 2000 22:45:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17713 Wed, 17 May 2000 00:38:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <39221E67.7C878389@cisco.com> References: <39221E67.7C878389@cisco.com> Date: Wed, 17 May 2000 00:39:54 -0400 To: "W. Mark Townsley" From: Stephen Kent Subject: Re: Windows 2000 and Cicsco router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, >So, we have all been dialing into our ISPs without any Authentication, >Authorization or Accounting? Wow, the IETF had better hurry up before >people catch on! > >Seriously, Stephen, Chinna was referring to current AAA practices. Yes, >they exist, and those who own and operate the networks are quite >concerned about them. > Then Chinna should not refer to such ad hoc mechanisms by the name of an IETF WG, as one might well make the assumption that such diverse practices have the status of an IETF standard. As the security advisor to our ISP (now Genuity), I don't recall use of the phrase AAA to refer to what we did for all these years. So, no, I make no apologies for pointing out that the terminology used by Chinna is inappropriate and misleading. The tenor of his messages over the last few days has been intimidating and often inaccurate. Are we now entering the tag team phase of this discussion? Steve From owner-ipsec@lists.tislabs.com Tue May 16 22:50:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA01553; Tue, 16 May 2000 22:50:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17565 Wed, 17 May 2000 00:14:46 -0400 (EDT) Message-ID: <39221E67.7C878389@cisco.com> Date: Wed, 17 May 2000 00:21:59 -0400 From: "W. Mark Townsley" Organization: cisco Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: [ snip ] > > The "features that AAA provides?" AAA is a WG but there are no AAA > standards yet. In fact, the WG drafts so far focusing only on > requirements for the protocols that will be standardized, in the > future. So a reference to what "AAA provides" or to "customers who > are so fond of their AAA infrastructure" appears to be in the future, > optimistic tense. > > AAA, when it exists, will encompass authentication as well as access > control. We are focusing on the access control aspect of IPsec. So, we have all been dialing into our ISPs without any Authentication, Authorization or Accounting? Wow, the IETF had better hurry up before people catch on! Seriously, Stephen, Chinna was referring to current AAA practices. Yes, they exist, and those who own and operate the networks are quite concerned about them. - Mark > Global pre-shared keys are an easy way to deploy IKE, but that does > not make them a good idea. It is understandable that customers want > to employ IPsec but also want to minimize the costs of deploying it. > The desire to make use of an existing user authentication > infrastructure is also understandable in this context, but is > separable from the access control mechanisms we are discussing. [ snip ] From owner-ipsec@lists.tislabs.com Tue May 16 22:51:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA01571; Tue, 16 May 2000 22:51:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17763 Wed, 17 May 2000 00:49:51 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Tue, 16 May 2000 21:56:15 -0700 (PDT) From: Jan Vilhuber To: Stephen Kent cc: "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 16 May 2000, Stephen Kent wrote: > The "features that AAA provides?" AAA is a WG but there are no AAA > standards yet. In fact, the WG drafts so far focusing only on > requirements for the protocols that will be standardized, in the > future. So a reference to what "AAA provides" or to "customers who > are so fond of their AAA infrastructure" appears to be in the future, > optimistic tense. > That's patently false, I fear. What chinna is referring to is the interaction (well defined) of Radius Authentication, Authorization and accounting (generally referred to as AAA) and PPP (and I expect you knew all that). That the AAA group is back to the drawing board is not the issue. The "customers who are so fond of their AAA infrastructure" obviously refers to the radius infrastructure. While chinna could have been more precise, I always equate them in my mind as well. I can tell you from personal experience that people want to shoehorn EVERYTHING into radius. They'll want this here as well (I've already gotten multiple requests about this). I guarantee it'll happen (or your money back). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue May 16 22:57:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA02114; Tue, 16 May 2000 22:57:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17806 Wed, 17 May 2000 00:58:04 -0400 (EDT) Message-ID: <3922288D.CD0132BD@cisco.com> Date: Wed, 17 May 2000 01:05:17 -0400 From: "W. Mark Townsley" Organization: cisco Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: <3921B453.E9572D4E@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > >Mark, > > >Please allow me to dispose of this view with some facts. First, L2TP is > >a standards track document that has support of many vendors, of which > >cisco and Microsoft are only two. > > > >Further, the fact that L2TP exists and is supported by both companies > >you single out is actually a tribute to support of IETF standards by > >each in the face of significant opposing development efforts. Clearly, > >if either were to try and capitalize on past development efforts as you > >suggest, L2TP would not exist and the world would have to choose between > >cisco's support of L2F and Microsoft's support of PPTP (each joint > >development efforts in their own right). No IETF. No standard RFC. > > My understanding of the history, is that L2TP represents a detente > agreement between MS and Cisco in this arena, which was then brought > to the IETF for standardization. PPTP, and it's impressive security Ultimately, MS and Cisco agreed to do what the IESG suggested. That is, create L2TP and let it go through the standards process for all to be a part of. MS and cisco were the initial driving force, but L2TP rapdily took on a life of its own. > complement, MPPEP, make for a laughable combination. I don't know > what Cisco envisioned as security for L2F, but it is clear that the > IESG mandated that L2TP not progress without a credible security > component, and so LT2P adopted IPsec, but in a fashion that is > architectually questionable. More than one proposal was presented for security, this was the one that was agreed upon at the time. Believe it or not, the the idea was to support IPsec in its efforts rather than duplicating security work within pppext. Too bad the reverse was not chapioned within IPsec early on (that is, letting IPsec rely upon pppext for remote access concerns). > > >Creation of L2TP and support of it is precisely the opposite of what you > >are claiming. Here Microsoft and cisco are both championing support of > >an IETF standard protocol, in direct opposition to that which each > >developed in-house and deployed first, and you are still being branding > >both as evil? > > Calling MS evil would be stating the obvious, as so many recent > events have illustrated :-). > > > > > > sending non-IP packets, L2TP is appropriate, but if I am sending IP, > > > then the extra headers introduced by L2TP are not only wasteful of > > > bandwidth on a continuing basis, but they also interfere with the > > > >Let's talk facts again. On a highly scaled, high bandwidth system, > >header size becomes increasingly less important. Over slow dialup lines, > >of course, it is worthwhile to try and get the header as small as > >possible. Negotiate PPP ACFC and PFC, and you get 1 byte of PPP header. > >L2TP's typical header for a voluntary tunnel would be either 6 bytes, or > >perhaps even 1 byte if you perform l2tphc. > > > >2 bytes (or even 7 bytes w/o l2tphc) of overhead for l2tp and ppp is > >small potatoes compared to ESP tunnel mode on each packet. > > > >Also, you get all sorts of nifty things that PPP is working on to reduce > >overhead. For instance, draft-ietf-pppext-pppmux-00.txt allows you to > >frame small packets into a single PPP frame. Given IPsec's large header, > >multiplexing small packets into a single frame before encrypting and > >tunneling could result in a *significant* header overhead reduction. > >Care to add that to IPsec's repertoire of features too? > > Reasonable points re my per packet overhead criticism, although the > excess is still just wasted space, whereas the ESP header is 2 bytes and you get multiprotocol capability. Heck, it would not be too difficult to even reduce this to 0 bytes if one is *that* concerned and does not mind limiting oneself to a single NCP within PPP. > essential for the function in question. Still, from a single, dialup > host, it's not clear under what circumstances the multi-packet muxing > will be invoked. The driving force for ppp mux as I remember is for voice packets at aggregation points in a wireless network. There could be others, but the point I was really making is that there are all sorts of things that the pppext WG has done for point to point remote access connections. What makes a secure tunnelled point to point connection so special? I see a VPN connection stepping in to replace what was traditionally a dialup or leased line. Utilizing the facilities that are in place and expanding upon them makes a great deal practical sense. > > Steve From owner-ipsec@lists.tislabs.com Tue May 16 23:11:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03244; Tue, 16 May 2000 23:11:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA17918 Wed, 17 May 2000 01:11:23 -0400 (EDT) Message-ID: <39222BAD.5A8C264F@cisco.com> Date: Wed, 17 May 2000 01:18:37 -0400 From: "W. Mark Townsley" Organization: cisco Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: <39221E67.7C878389@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > Mark, > > >So, we have all been dialing into our ISPs without any Authentication, > >Authorization or Accounting? Wow, the IETF had better hurry up before > >people catch on! > > > >Seriously, Stephen, Chinna was referring to current AAA practices. Yes, > >they exist, and those who own and operate the networks are quite > >concerned about them. > > > > Then Chinna should not refer to such ad hoc mechanisms by the name of > an IETF WG, as one might well make the assumption that such diverse > practices have the status of an IETF standard. As the security > advisor to our ISP (now Genuity), I don't recall use of the phrase > AAA to refer to what we did for all these years. Sorry. Check out the config on any cisco router. "aaa ..." has been a part of it for many years (way before the AAA WG first met), and a general part of the traditional remote access vocabulary for as long as I can remember... > > So, no, I make no apologies for pointing out that the terminology > used by Chinna is inappropriate and misleading. The tenor of his > messages over the last few days has been intimidating and often > inaccurate. Are we now entering the tag team phase of this > discussion? > > Steve From owner-ipsec@lists.tislabs.com Wed May 17 00:29:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA06569; Wed, 17 May 2000 00:29:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA18221 Wed, 17 May 2000 02:19:04 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Jan Vilhuber Cc: Stephen Kent , "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 May 2000 02:26:13 -0400 Message-Id: <20000517062617.C3FB935DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: >On Tue, 16 May 2000, Stephen Kent wrote: >> The "features that AAA provides?" AAA is a WG but there are no AAA >> standards yet. In fact, the WG drafts so far focusing only on >> requirements for the protocols that will be standardized, in the >> future. So a reference to what "AAA provides" or to "customers who >> are so fond of their AAA infrastructure" appears to be in the future, >> optimistic tense. >> >That's patently false, I fear. What chinna is referring to is the interaction >(well defined) of Radius Authentication, Authorization and accounting >(generally referred to as AAA) and PPP (and I expect you knew all that). > >That the AAA group is back to the drawing board is not the issue. The >"customers who are so fond of their AAA infrastructure" obviously refers to >the radius infrastructure. While chinna could have been more precise, I >always equate them in my mind as well. > >I can tell you from personal experience that people want to shoehorn >EVERYTHING into radius. They'll want this here as well (I've already gotten >multiple requests about this). I guarantee it'll happen (or your money back). "Back" to the drawing board? By intent of the IESG, they haven't left it yet. Up until now, AAA has been focused on requirements. The charter is at http://www.ietf.org/html.charters/aaa-charter.html; to save you the trouble, the actions for this group are to generate requirements, solicit candidate protocols, compare the candidates to the requirements, and then decide if a new working group is needed to finish development of the selected candidate. The primary requirements drafts were only published in late April (i.e., draft-irtf-aaaarch-generic-01.txt and draft-irtf-aaaarch-authorization-reqs-01.txt). Yes, RADIUS -- or, more precisely, DIAMETER, which is a next-generation version of RADIUS, in some ways -- is a strong contender. RADIUS per se just doesn't cut it. It's also an architectural nightmare, and the myriad requirements for new features are one reason that it's taken AAA this long to reach even this point. RADIUS as it exists today is inadequate. A new protocol is needed, but at a guess it's a year until it reaches Proposed Standard. And we have yet to figure out precisely how it will deal with IPsec, IPSRA, L2TP, etc. --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed May 17 00:29:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA06590; Wed, 17 May 2000 00:29:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA18179 Wed, 17 May 2000 02:11:10 -0400 (EDT) Date: Tue, 16 May 2000 23:18:24 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Several folks have suggested that one might choose to enforce access control at the IP layer, but not in the context of IPsec, e.g., by passing SA info to a separate firewall for post IPsec checking. If the firewall is part of the same device as the IPsec module, the this can be effected in a local fashion that would be consistent with 2401, as the management interface for the combined firewall/SG would have the necessary properties." That pretty much sums up, what I was trying to say. If you loose granularity of access control because you are tunneling traffic in L2TP and you are protecting L2TP with IPSec, we can still enforce access control outside of the context of IPSec, and let the trust/security flow from one module in the system to the other. The main benefit here is that we are leveraging services already provided by other modules in the system, and don't have to do everything in IPSec. I think that, this was the main point of contention when we started on this thread. If you feel that I am being paranoid of the letter x, I guess you are paranoid about the L2TP protocol, and the whole myth that L2TP=Microsoft+Cisco. chinna On Tue, 16 May 2000, Stephen Kent wrote: > Chinna, > > >Frankly, I don't understand what Andrew is trying to tell me. His bottom > >line was: > > > >"IMHO, the idea with the most technical merit is to remove packet > >filtering from IPsec and make the firewalls IPsec aware. (No, I'm not > >saying we should rewrite all the specs; that's just the *ideal* solution > >in my mind.) > > > >All clear now?" !!! > > It's always a delight to see enthusiastic support for a position from > someone new to this WG. Unfortunately, such enthusiasm is often > unencumbered by knowledge of the WG history, or even technical depth, > on the issue in question. This seems to be such a case. > > > > >Anyway, regarding access control: > > > >How many people beleive that the IPSec access control mechanism, is going > >to solve all our access control problems? > > That's not the question before us. No single security mechanism is a > panacea. What we are discussing are the relative merits of two > different approaches to effecting a particular type of access control. > > >If people beleived that IPSec access control mechanism solves all their > >access control problems, then I guess we wouldn't have a need to leverage > >the access control features that AAA provides. I have seen customers who > >are so fond of their AAA infrastructure, that they by-pass IKE > >authentication by using an equivalent of a global pre-shared key! and > >totally base their authentication on AAA authentication(and if you do this > >via xauth, that doesn't authenticate the DH exchange)! Let's face it, how > >many implementations support some form of global pre-shared key? > >Supposedly the customers wants this badly, and if we dont provide this, > >there are implementations that already provide this! > > The "features that AAA provides?" AAA is a WG but there are no AAA > standards yet. In fact, the WG drafts so far focusing only on > requirements for the protocols that will be standardized, in the > future. So a reference to what "AAA provides" or to "customers who > are so fond of their AAA infrastructure" appears to be in the future, > optimistic tense. > > AAA, when it exists, will encompass authentication as well as access > control. We are focusing on the access control aspect of IPsec. > Global pre-shared keys are an easy way to deploy IKE, but that does > not make them a good idea. It is understandable that customers want > to employ IPsec but also want to minimize the costs of deploying it. > The desire to make use of an existing user authentication > infrastructure is also understandable in this context, but is > separable from the access control mechanisms we are discussing. > > >To investigate the cryptographic binding between a packet that has been > >decapsulated, and to which the IPSec selector has to be applied, lets > >start by how the binding took form at the encapsulation side in the first > >place. At the encapsulation side, in the context on an IPSec > >implementaion, we have a selector based on IP Addresses, protocol and > >ports. Once a packet matches this selector, it is encapsulated, and that > >is all IPSec can truly enforce. Are you saying that this is all we need to > >enforce all kinds of access control requirements, and complex policies > >that any corporation can have? > > You seem to have trouble distinguishing between access control > enforcement mechanisms and access control policies. The policies > that an IPsec implementation can enforce is limited to the inputs > available to an IPsec implementation. The set of information differs > in native host vs. security gateway implementations. I believe that > we're discussing the latter here. > > The 5 primary selectors from the IP and TCP header are the only > inputs available to the SG for enforcement, on a steady state basis. > (I'm omitting the security labels, which are not required for most > implementations, and the user/system IDs that are not employed on a > steady state basis.) However, while RFC 2401 specifies a minimum > access control policy capability for any IPsec implementation, there > is no prohibition against more sophisticated policies being employed, > subject to the constraint that the enforcement parameters can be > translated into these selectors. For example, if one wants to include > time of day as an input to an access control decision, e.g., limiting > the times at which an SA can be established, one could do that > external to the enforcement mechanism. > > Certainly one can usefully employ access control policies that are > application specific, and which cannot be enforced at the Internet > layer. However, that does not imply that Internet layer policies and > enforcement mechanisms are irrelevant. > > Several folks have suggested that one might choose to enforce access > control at the IP layer, but not in the context of IPsec, e.g., by > passing SA info to a separate firewall for post IPsec checking. If > the firewall is part of the same device as the IPsec module, the this > can be effected in a local fashion that would be consistent with > 2401, as the management interface for the combined firewall/SG would > have the necessary properties. However, if the firewall is in a > separate device, I think the required co-ordination would become very > expensive. For example, for outbound traffic, the SG must map > packets to SAs, or know when to create an SA for traffic. If the > firewall does this mapping for the SG, we would need to define a way > to pass the SPD entry info across a wire to the SG from the firewall. > Also, the SG would have to provide a reverse channel to keep the > firewall aware of the SA status, e.g., based on SA timeouts, IKE > failures, etc. Conversely, if the SG maintains the SPD locally (as > is the current practice), then there needs to be a new management > mechanism to synchronize these databases. In the reverse direction, > if the SG no longer performs the post processing access control > checks required by 2401, then it was suggested that we need to define > some means of passing SA data to the firewall. In fact, it appears > that we need to pass quite a bit of data. Just passing the SPI is not > sufficient, unless we introduce a reverse channel from the SG to the > firewall so that the firewall can mirror the SAD (not just the SPD). > Also, how do we pass the SPI or similar data for each packet? Is > there a way to do this without breaking the stack on the firewall, > and what will the performance impact be based on whatever way we find > to pass this info? I'm not saying that one cannot split the access > control checks between an SG and a firewall, but I do think that the > complexity associated with such a split has been underestimated. > > > >It's not just the access control folks that see IPSec as a nuance, but > > "Nuance" vs. "nuisance?" > > >there are the Intrution Detection (ID) folks. If we do end to end > >security, IE from the client of some service to the server of that > >service, the ID folks don't like that. > > This argument is irrelevant to the discussion, but I'll respond > anyway. End-to-end encryption of any form (IPsec, SSL/TLS, SSH, or > S/MIME) interferes with network-based ID, but the host-based ID still > work. Since tests by Lincoln Labs show that network based ID is at > best about 80% effective at detecting KNOWN attacks, whereas the best > host-based systems are much better, I'm not too concerned by this > limitation. > > >If we had an IPSec selector that > >says all traffic from any TCP high port to port 21 needs to be secured > >with a certain policy, it doesn't stop a legitimate user/a hacker who > >gained control of the system to do a simple TCP SYN flood attack. If this > >traffic was encrypted using IPSec, then there is no way that the Intrution > >Detection System (IDS), is going to detect this. So, these guys have a > >requirement that all IPSec tunnels should terminate on the perimeter of > >the network, so that these guys can do their job. I guess, someone is > >busy, out there trying to integrate ID into IPSec. xids? Then we can have > >xauth, xauthr, xacc, xids, mode config etc... and we can update these > >documents once every 6 months, to incorporate/support more and more > >features of these protocols. There are supposedly 6 versions(revisions) of > >the draft that we already have, and different vendors support different > >versions. I leart today that we support version 3 on the cisco router. > >I guess we are just waiting for some customer to bang on our heads, > >demanding that they want version 6 because it has a feature x that version > >3 cannot support. > > The threat model you cite re TCP SYN flooding is unduly constrained, > and not very convincing. SYN flood attacks are effected by spoofing > the source address; in the case you cite, we know precisely where the > packets are coming from, and an analysis of the log at the targeted > host would show that, assuming that the packets emerging from the SA > were checked by IPsec to verify the source address consistency. > > Your fear of the letter "x" seems to be getting the better of you, > i.e., it's distracting you from the argument at hand :-). There's > nothing to comment on in this last paragraph. > > Steve > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed May 17 01:34:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA12227; Wed, 17 May 2000 01:34:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18534 Wed, 17 May 2000 03:23:30 -0400 (EDT) Message-ID: <39224AA6.CAB925FF@F-Secure.com> Date: Wed, 17 May 2000 10:30:46 +0300 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "W. Mark Townsley" CC: Stephen Kent , "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Subject: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) References: <3921B453.E9572D4E@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "W. Mark Townsley" wrote: > > Let's talk facts again. On a highly scaled, high bandwidth system, > header size becomes increasingly less important. Over slow dialup lines, > of course, it is worthwhile to try and get the header as small as > possible. Negotiate PPP ACFC and PFC, and you get 1 byte of PPP header. > L2TP's typical header for a voluntary tunnel would be either 6 bytes, or > perhaps even 1 byte if you perform l2tphc. > > 2 bytes (or even 7 bytes w/o l2tphc) of overhead for l2tp and ppp is > small potatoes compared to ESP tunnel mode on each packet. > > Also, you get all sorts of nifty things that PPP is working on to reduce > overhead. For instance, draft-ietf-pppext-pppmux-00.txt allows you to > frame small packets into a single PPP frame. Given IPsec's large header, > multiplexing small packets into a single frame before encrypting and > tunneling could result in a *significant* header overhead reduction. > Care to add that to IPsec's repertoire of features too? > I agree fully that having PPP for remote access provides with tangible benefits. Something like IPX transport would even be useful in a gateway to gateway case. It would be very inefficient for IETF to respecify everything for IPSec without PPP. (This is not to say that some non-PPP, non-L2TP remote access solution should not be created.) What I disagree with is putting L2TP between PPP and IPSec. So far the only reason I've been offered for doing so is that PPP breaks if the packets are re-ordered during transit. L2TP has a lot of functionality, but it's all irrelevant if you just want to have a link where the IPSec and PPP endpoints coincide. (Anyone wanting to do compulsory tunneling would of course be free to use PPP/L2TP/IPSec.) I would be very happy to see a standards track RFC that describes a lightweight method for running PPP over IPSec, usable in a voluntary tunneling case. The PPP over IPSec combination should be negotiable through IKE, IKE access controls should apply to whatever traffic comes out of / goes into PPP, i.e. actual customer traffic. -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Wed May 17 06:49:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA29009; Wed, 17 May 2000 06:49:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19573 Wed, 17 May 2000 08:25:49 -0400 (EDT) Date: Tue, 16 May 2000 14:37:44 -0300 (EST) From: "Antonio Pires Castro Jr." To: ipsec@lists.tislabs.com Subject: DNSsec Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Friends, I would like to learn how DNSsec work. Where I can find some doc about it? Bind 8 has DNSsec ??? []'s _________ Antonio Pires de Castro Junior apcastro@dcc.unicamp.br From owner-ipsec@lists.tislabs.com Wed May 17 08:20:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01057; Wed, 17 May 2000 08:20:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20227 Wed, 17 May 2000 10:06:44 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A38B@baltimore.com> From: Chris Trobridge To: "CHINNA N.R. PELLACURU" Cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Wed, 17 May 2000 15:14:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > When we use L2TP to provide a VPN link to a user into the > private network, > it is just emulating as if the user is on the private > network. When a user > requests for VPN access, he has to authenticate and prove his > credentials > before he can gain access to private network. > > Once the user has gained access, he is virtually on the private network. > He can do whatever he would be normally allowed to do when he is > physically on the private network. So, if your private network allows one > user to easily spoof other users, then that is _not_ a failure of the VPN > technology, but your security infrastructure in the private network. This assumes that policy does treat 'dial-in' users as the same as networks physically on the network. I think this is an invalid assumption. I am sure that certain organsisations would regard remote access as being less secure and would want to restrict the resources that could be accessed remotely. This doesn't even have to mean that the VPN technology itself is inadequate, merely that the environment that the remote user is operating in may not be regarded to be secure enough. Chris From owner-ipsec@lists.tislabs.com Wed May 17 08:43:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01538; Wed, 17 May 2000 08:43:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20676 Wed, 17 May 2000 10:47:10 -0400 (EDT) Message-ID: <3922B299.33F066FE@cisco.com> Date: Wed, 17 May 2000 10:54:17 -0400 From: "W. Mark Townsley" Organization: cisco Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ari Huttunen CC: Stephen Kent , "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) References: <3921B453.E9572D4E@cisco.com> <39224AA6.CAB925FF@F-Secure.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari Huttunen wrote: > > "W. Mark Townsley" wrote: > > > > Let's talk facts again. On a highly scaled, high bandwidth system, > > header size becomes increasingly less important. Over slow dialup lines, > > of course, it is worthwhile to try and get the header as small as > > possible. Negotiate PPP ACFC and PFC, and you get 1 byte of PPP header. > > L2TP's typical header for a voluntary tunnel would be either 6 bytes, or > > perhaps even 1 byte if you perform l2tphc. > > > > 2 bytes (or even 7 bytes w/o l2tphc) of overhead for l2tp and ppp is > > small potatoes compared to ESP tunnel mode on each packet. > > > > Also, you get all sorts of nifty things that PPP is working on to reduce > > overhead. For instance, draft-ietf-pppext-pppmux-00.txt allows you to > > frame small packets into a single PPP frame. Given IPsec's large header, > > multiplexing small packets into a single frame before encrypting and > > tunneling could result in a *significant* header overhead reduction. > > Care to add that to IPsec's repertoire of features too? > > > > I agree fully that having PPP for remote access provides with > tangible benefits. Something like IPX transport would even be useful > in a gateway to gateway case. It would be very inefficient for IETF > to respecify everything for IPSec without PPP. (This is not to say > that some non-PPP, non-L2TP remote access solution should not be created.) > > What I disagree with is putting L2TP between PPP and IPSec. So far > the only reason I've been offered for doing so is that PPP breaks if > the packets are re-ordered during transit. Not sure who offered that one to you. (1) L2TP sequencing is optional, and will likely run disabled in the voluntary case with IPsec, (2) While order is specified in RFC1661 as a basic assumption, in practice we have seen little to no problems with current PPP stacks running without L2TP sequencing. In fact, I personally have seen more problems when L2TP tries to drop packets received out of order. This has been hashed out many, many, times on the l2tp list (as he scrambles to grab the worms and stuff them back into the can before anyone notices). > L2TP has a lot of functionality, > but it's all irrelevant if you just want to have a link where the IPSec > and PPP endpoints coincide. True, a good portion of what L2TP offers is not applicable in the voluntary case (largely the Proxy LCP/Auth features, Tunnel authentication, and perhaps some of the calling number/id etc. AVPs). Most of these are optional, so there is no need to implement them for the voluntary case. > (Anyone wanting to do compulsory tunneling > would of course be free to use PPP/L2TP/IPSec.) > > I would be very happy to see a standards track RFC that describes > a lightweight method for running PPP over IPSec, usable in a voluntary > tunneling case. The PPP over IPSec combination should be negotiable > through IKE, IKE access controls should apply to whatever traffic comes > out of / goes into PPP, i.e. actual customer traffic. So IPSec now carries a Layer 2 protocol directly? I thought we were interested in making IPSec *less* complex, not more. I don't see why adding 1 byte of header via l2tphc (which runs directly over IP) is such a stumbling block. As for the L2TP signaling. I think it makes more sense to have one protocol which, at the Gateway (LNS in L2TP terminology), there is no significant distinction as to whether you are terminating a compulsory session or a voluntary session. Why create a new protocol for every deployment model when a subset of one you have will work fine as is? > > -- > Ari Huttunen phone: +358 9 859 900 > Senior Software Engineer fax : +358 9 8599 0452 > > F-Secure Corporation http://www.F-Secure.com > > F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Wed May 17 08:43:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01551; Wed, 17 May 2000 08:43:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20616 Wed, 17 May 2000 10:38:31 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A38C@baltimore.com> From: Chris Trobridge To: "W. Mark Townsley" Cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Wed, 17 May 2000 15:46:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: W. Mark Townsley [mailto:townsley@cisco.com] > Chris Trobridge wrote: > > > > The point is that with an IPSEC SA traffic is only allowed > that matches the > > selector for that SA. In the access control case this > means you can enforce > > that anyone who connects via an IPSEC tunnel can only send > or receive > > datagrams associated with his client address. This > prevents him from > > spoofing other clients or hosts and from receiving traffic > not addressed to > > him. > > > > The moment you tunnel L2TP through an SA IPSEC loses its > ability to perform > > this filtering. Depending on the whether 'extra' work has > been done, once > > IPSEC processing has been completed the L2TP layer will not > know via which > > SA a datagram was received, allowing a client to spoof > other addresses. > > Why not? > > An SA protects an l2tp tunnel, which carries a PPP session, which > performed user authentication and authorization. Such authorization is > the basis for access control lists that can do a number of L3 > checks on > the traffic which PPP framed. Here, a direct correlation > between a given > SA, the authenticated user, and finally her authorization for the > network. I suppose this all hangs on the binding between the SA, L2TP tunnel and the PPP session. I can't claim to be particularly familiar with L2TP, but comments made much earlier on list suggested that L2TP tunnels aren't tightly bound to IPSEC SAs. At the time no one countered this view. This was seen to be a weakness that might allow datagrams from one SA to delivered to an L2TP tunnel end point associated with a different SA. > ISPs and enterprises have been doing filter checks on incoming PPP > encapsulated data for years. The requirements for such have evolved > considerably over this time. I doubt that they want to toss this > functionality out the door and I cannot blame them. Given that PPP wasn't required or even present in the first place, I can't see how you can make comments about throwing functionality out of the door! The basis this list has been working on is that IP datagrams are tunnelled from the client to the private network using tunnelling IPSEC-ESP. Chris From owner-ipsec@lists.tislabs.com Wed May 17 09:18:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02210; Wed, 17 May 2000 09:18:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21036 Wed, 17 May 2000 11:11:57 -0400 (EDT) Message-ID: <3922B86D.6E077D4@cisco.com> Date: Wed, 17 May 2000 11:19:09 -0400 From: "W. Mark Townsley" Organization: cisco Systems X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Trobridge CC: ipsec@lists.tislabs.com Subject: Re: Windows 2000 and Cicsco router interoperability References: <1FD60AE4DB6CD2118C420008C74C27B854A38C@baltimore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Chris Trobridge wrote: > > > From: W. Mark Townsley [mailto:townsley@cisco.com] > > > Chris Trobridge wrote: > > > > > > The point is that with an IPSEC SA traffic is only allowed > > that matches the > > > selector for that SA. In the access control case this > > means you can enforce > > > that anyone who connects via an IPSEC tunnel can only send > > or receive > > > datagrams associated with his client address. This > > prevents him from > > > spoofing other clients or hosts and from receiving traffic > > not addressed to > > > him. > > > > > > The moment you tunnel L2TP through an SA IPSEC loses its > > ability to perform > > > this filtering. Depending on the whether 'extra' work has > > been done, once > > > IPSEC processing has been completed the L2TP layer will not > > know via which > > > SA a datagram was received, allowing a client to spoof > > other addresses. > > > > Why not? > > > > An SA protects an l2tp tunnel, which carries a PPP session, which > > performed user authentication and authorization. Such authorization is > > the basis for access control lists that can do a number of L3 > > checks on > > the traffic which PPP framed. Here, a direct correlation > > between a given > > SA, the authenticated user, and finally her authorization for the > > network. > > I suppose this all hangs on the binding between the SA, L2TP tunnel and the > PPP session. I can't claim to be particularly familiar with L2TP, but > comments made much earlier on list suggested that L2TP tunnels aren't > tightly bound to IPSEC SAs. At the time no one countered this view. This > was seen to be a weakness that might allow datagrams from one SA to > delivered to an L2TP tunnel end point associated with a different SA. Sorry I missed it. I believe a basic assumption with L2TP and IPsec operating together would be a tight coupling between the L2TP tunnel and IPsec SA. There is an entire document whose purpose in life is to describe this coupling. We will be sure to address this even more in the next version. What is common sense to one person, is not to another. This is why we have peer review. > > > ISPs and enterprises have been doing filter checks on incoming PPP > > encapsulated data for years. The requirements for such have evolved > > considerably over this time. I doubt that they want to toss this > > functionality out the door and I cannot blame them. > > Given that PPP wasn't required or even present in the first place, I can't Perhaps that has been one of the problems. > see how you can make comments about throwing functionality out of the door! > The basis this list has been working on is that IP datagrams are tunnelled > from the client to the private network using tunnelling IPSEC-ESP. The lines blur between IPsec and IPsra here. As you say, what we are really talking about is the case where a client is accessing a home network. Loosely adopted as the "secure remote access" case. We have two choices. (1) Take a security protocol and try to make it meet the myriad of remote access needs customers have today. Or, (2) create a secure pipe over the Internet, treat that pipe as new point to point media, and hook into the existing remote access infrastructure that we already have. I have not been convinced that #2 is not the most viable option. > > Chris From owner-ipsec@lists.tislabs.com Wed May 17 09:40:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02593; Wed, 17 May 2000 09:40:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21184 Wed, 17 May 2000 11:32:01 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A38D@baltimore.com> From: Chris Trobridge To: "W. Mark Townsley" , Stephen Kent Cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability Date: Wed, 17 May 2000 16:39:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: W. Mark Townsley [mailto:townsley@cisco.com] > More than one proposal was presented for security, this was > the one that > was agreed upon at the time. Believe it or not, the the idea was to > support IPsec in its efforts rather than duplicating security work > within pppext. Too bad the reverse was not chapioned within > IPsec early on (that is, letting IPsec rely upon pppext for remote > access concerns). IMO, L2TP hasn't really had much of a profile on the IPSEC WG at all. I just looked looked back over the last 6 months and it is mostly yourself, or another cisco employee championing it. Most of the discussion surrounded the aftermath of Schneier's paper on IPSEC complexity. It cannot be said that LT2P was received at all warmly by the group. I think it still looked like a protocol of marginal interest to IPSEC by the time the discussion fizzled out inconclusively (as seems to be the way with this WG). This isn't to disparage L2TP itself, just a reflection on how the WG appears to have valued its importance to IPSEC. Perhaps L2TP does merit a greater place - and with cisco and ms backing it it probably will anyway! - but it doesn't look like thats the way things have been heading with this group. Chris From owner-ipsec@lists.tislabs.com Wed May 17 10:26:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03543; Wed, 17 May 2000 10:26:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21338 Wed, 17 May 2000 12:18:29 -0400 (EDT) Message-ID: <3922C8E6.D94902D4@redcreek.com> Date: Wed, 17 May 2000 09:29:26 -0700 From: "Scott G. Kelly" 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 To: "W. Mark Townsley" CC: Ari Huttunen , Stephen Kent , "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) References: <3921B453.E9572D4E@cisco.com> <39224AA6.CAB925FF@F-Secure.com> <3922B299.33F066FE@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've been asking this question elsewhere, but all the action seems to be here. That being the case, I'll jump threads. I'm trying to objectively determine the benefits (and drawbacks) of accepting l2tp/ipsec as a remote access solution. I'm also interested in whether there are any other non-rmt-access benefits. Clearly, folks who have been working on l2tp (and ppp) for years feel quite strongly about this, but strongly-held views are only helpful here when backed up with objective reasoning. That's what I'm after. The point has been made that some sort of aaa infrastructure has been deployed for dial-up users, and that customers should not be asked to discard this. Please clarify what components would be discarded if we do not use l2tp. For example, I know of several ipsec vendors who implement some sort of radius interaction without using either ppp or l2tp, so it seems that radius investments are not necessarily in jeopardy here. Please address this. Secondly, in response to overhead concerns, the point has been made that there are various header compression schemes available in ppp/l2tp which mitigate this. While this response addresses the on-the-wire overhead to some extent, it ignores the additional packet processing overhead and complexity that wrapping the packets in 2 more protocols (all the while doing header compression) entails. Please address this. Finally, in response to the security issues raised by obscuring the transit selectors from the ipsec machinery, the argument has been made that ppp provides all the necessary protections. However, this is not all that reassuring, and conjures up images of the left hand not knowing what the right hand is doing. Please elaborate a bit on how this mechanism provides comparable assurance to one where ipsec is employed alone. Scott From owner-ipsec@lists.tislabs.com Wed May 17 11:07:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04544; Wed, 17 May 2000 11:07:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21450 Wed, 17 May 2000 12:54:17 -0400 (EDT) From: Barney Wolff To: ipsec@lists.tislabs.com Date: Wed, 17 May 2000 12:10 EDT Subject: RE: Windows 2000 and Cicsco router interoperability Content-Type: text/plain Message-ID: <3922c5d60.4e3f@databus.databus.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As a non-Cisco, non-MS L2TP developer, let me say that benign neglect of L2TP by the IPsec group would be a welcome advance. What we've seen has been active disparagement by certain IPsec'ers, apparently based on assumptions that do not match how anybody's L2TP or PPP implementations really work. Barney Wolff > From: Chris Trobridge > Date: Wed, 17 May 2000 16:39:39 +0100 > > IMO, L2TP hasn't really had much of a profile on the IPSEC WG at all. From owner-ipsec@lists.tislabs.com Wed May 17 11:46:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05449; Wed, 17 May 2000 11:46:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23690 Wed, 17 May 2000 13:44:50 -0400 (EDT) Date: Wed, 17 May 2000 10:52:32 -0700 From: Paul Krumviede Subject: Re: Windows 2000 and Cicsco router interoperability In-reply-to: <20000517062617.C3FB935DC2@smb.research.att.com> To: "Steven M. Bellovin" , Jan Vilhuber Cc: Stephen Kent , "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Message-id: <783045522.958560752@sjo-dhcp0406.mcit.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --On Wednesday, 17 May, 2000 02:26 -0400 "Steven M. Bellovin" wrote: > In message > , Jan > Vilhuber writes: >> On Tue, 16 May 2000, Stephen Kent wrote: >>> The "features that AAA provides?" AAA is a WG but there are no AAA >>> standards yet. In fact, the WG drafts so far focusing only on >>> requirements for the protocols that will be standardized, in the >>> future. So a reference to what "AAA provides" or to "customers who >>> are so fond of their AAA infrastructure" appears to be in the future, >>> optimistic tense. >>> >> That's patently false, I fear. What chinna is referring to is the >> interaction (well defined) of Radius Authentication, Authorization and >> accounting (generally referred to as AAA) and PPP (and I expect you >> knew all that). >> >> That the AAA group is back to the drawing board is not the issue. The >> "customers who are so fond of their AAA infrastructure" obviously >> refers to the radius infrastructure. While chinna could have been more >> precise, I always equate them in my mind as well. >> >> I can tell you from personal experience that people want to shoehorn >> EVERYTHING into radius. They'll want this here as well (I've already >> gotten multiple requests about this). I guarantee it'll happen (or your >> money back). > > "Back" to the drawing board? By intent of the IESG, they haven't left > it yet. Up until now, AAA has been focused on requirements. The > charter is at http://www.ietf.org/html.charters/aaa-charter.html; to > save you the trouble, the actions for this group are to generate > requirements, solicit candidate protocols, compare the candidates to > the requirements, and then decide if a new working group is needed to > finish development of the selected candidate. The primary requirements > drafts were only published in late April (i.e., > draft-irtf-aaaarch-generic-01.txt and > draft-irtf-aaaarch-authorization-reqs-01.txt). Please don't confuse the IRTF group, which produced the drafts Steve mentioned, and the IETF working group, which has a different set of drafts. Given that there was little input into the requirements process for things other than network access (e.g. dial-up and mobileIP), the scope of the evaluation is limited. > Yes, RADIUS -- or, more precisely, DIAMETER, which is a next-generation > version of RADIUS, in some ways -- is a strong contender. RADIUS per > se just doesn't cut it. It's also an architectural nightmare, and the > myriad requirements for new features are one reason that it's taken AAA > this long to reach even this point. > > RADIUS as it exists today is inadequate. A new protocol is needed, but > at a guess it's a year until it reaches Proposed Standard. And we have > yet to figure out precisely how it will deal with IPsec, IPSRA, L2TP, > etc. Suggestions on all of this would be welcomed. But the various working groups and the IESG would have to figure out where this fits. But we seem to be a long way away from IPsec itself in such discussions of AAA (whether the WG, the current infrastructure, or combinations of them). -paul From owner-ipsec@lists.tislabs.com Wed May 17 12:58:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07568; Wed, 17 May 2000 12:58:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27704 Wed, 17 May 2000 14:49:37 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: Wired query on Windows 2000 and DES/3DES Date: Wed, 17 May 2000 10:23:30 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC024.9E865E68" Message-ID: <6A05D00595BE644E9F435BE5947423F2A21DF1@fifi.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4368.4 Thread-Topic: Wired query on Windows 2000 and DES/3DES Thread-Index: Ab+/OSMHwqUhlzElTrOXN/mLwlSi/QA61F2g From: "William Dixon" To: "Declan McCullagh" , X-OriginalArrivalTime: 17 May 2000 17:25:40.0007 (UTC) FILETIME=[EBFA5370:01BFC024] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFC024.9E865E68 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was out of town for Thurs eve-Sun, heads down for Wed & Thurs to get free, otherwise I could have replied to the list earlier. We essentially had 6 hours to reply from when I saw it Monday morning, so I spent all day Monday explaining & doing the process. Ron Cully & I had a detailed discussion with Declan Monday evening about why this functionality exists - he knew far more than he printed and I assume chose his words for the popularity of the anti-MS position. It is unfortunate that others on the list reacted the way they did on initial information and were quoted verbatim. The other Microsoft engineers who replied assumed they were talking to the IPSec developer audience - who are very familiar with the protocol and the real administrator issues for deployment using centralized policy for both client & server side IPSec transport configuration on hundreds or thousands of systems in a non-geographically, but administratively defined group vs. local configuration of a box. I will post an explanation as soon as I can, but as you might expect I'm completely slammed with fire fighting, probably for the rest of the week. It has been in Win2k's IPSec implementation since beta1 and constantly briefed to customers, and documented everywhere we describe setting security levels, not to mention logged in two places, the application log always and the security audit log when auditing is enabled. I would consider not installing the strong crypto pack a much more serious issue for the platform in general - since it limits all cryptographic services & protections in the operating system. The strong crypto pack should be on a floppy in every Win2k box shipped according to the new more-open US export rules, subject to Microsoft having received import allowance & sale to public allowances in the end-user political jurisdiction. That said, I understand the views of the people on the list and will get back to you. -Wm -----Original Message----- From: Declan McCullagh [mailto:declan@wired.com] Sent: Tuesday, May 16, 2000 6:02 AM To: ipsec@lists.tislabs.com Subject: Re: Wired query on Windows 2000 and DES/3DES My article is here: http://www.wired.com/news/technology/0,1282,36336,00.html Thanks, all for the help. -Declan ------_=_NextPart_001_01BFC024.9E865E68 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Wired query on Windows 2000 and DES/3DES

I was out of town for Thurs eve-Sun, heads down for = Wed & Thurs to get free, otherwise I could have replied to the list = earlier.  We essentially had 6 hours to reply from when I saw it = Monday morning, so I spent all day Monday explaining & doing the = process.  Ron Cully & I had a detailed discussion with Declan = Monday evening about why this functionality exists - he knew far more = than he printed and I assume chose his words for the popularity of the = anti-MS position.  It is unfortunate that others on the list = reacted the way they did on initial information and were quoted = verbatim.  The other Microsoft engineers who replied assumed they = were talking to the IPSec developer audience - who are very familiar = with the protocol and the real administrator issues for deployment using = centralized policy for both client & server side IPSec transport = configuration on hundreds or thousands of systems in a = non-geographically, but administratively defined group vs. local = configuration of a box.

I will post an explanation as soon as I can, but as = you might expect I'm completely slammed with fire fighting, probably for = the rest of the week.  It has been in Win2k's IPSec implementation = since beta1 and constantly briefed to customers, and documented = everywhere we describe setting security levels, not to mention logged in = two places, the application log always and the security audit log when = auditing is enabled.

I would consider not installing the strong crypto pack = a much more serious issue for the platform in general - since it limits = all cryptographic services & protections in the operating = system.  The strong crypto pack should be on a floppy in every = Win2k box shipped according to the new more-open US export rules, = subject to Microsoft having received import allowance & sale to = public allowances in the end-user political jurisdiction.  That = said, I understand the views of the people on the list and will get back = to you.  -Wm

-----Original Message-----
From: Declan McCullagh [mailto:declan@wired.com]
Sent: Tuesday, May 16, 2000 6:02 AM
To: ipsec@lists.tislabs.com
Subject: Re: Wired query on Windows 2000 and = DES/3DES


My article is here:

http:/= /www.wired.com/news/technology/0,1282,36336,00.html

Thanks, all for the help.

-Declan

------_=_NextPart_001_01BFC024.9E865E68-- From owner-ipsec@lists.tislabs.com Wed May 17 13:13:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07939; Wed, 17 May 2000 13:13:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28831 Wed, 17 May 2000 15:12:43 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: more microsoft policy issues? Date: Wed, 17 May 2000 10:03:45 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC021.DC9C3D06" Message-ID: <6A05D00595BE644E9F435BE5947423F2FFC3E3@fifi.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4368.4 Thread-Topic: more microsoft policy issues? Thread-Index: Ab+/phNrWZX7UFsZR9+zrbYJfzMMZQAeMSHg From: "William Dixon" To: "Jan Vilhuber" Cc: X-OriginalArrivalTime: 17 May 2000 17:05:58.0757 (UTC) FILETIME=[2BE5E150:01BFC022] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFC021.DC9C3D06 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you don't want IPSec ever & don't want L2TP/IPSec VPN connections, the local admin can shutdown the IPSec Policy Agent service, and/or disable the service entirely. The roles of "users" in general in Win2k, be they domain admins, local admins, backup operators, local users, guests, etc and associated security configurations & activities by those users are defined by the OS security team for the entire OS, and IPSec as a service is consistent as possible with that model and the rest of the components in the OS which provide manageability of the platform. =20 This is why taking any particular IPSec functionality on it's own, out of context, elevating it to philosophical levels, just isn't going to be a productive discussion. Win2k IPSec is designed to be a centrally administrated tool to increase the protection of OS & application traffic. We have had many smart & knowledgeable people working on this, and many more external to the product team looking at it to ensure quality of design and implementation, not to mention worldwide beta testing, for literally 3 years. The UI was revised 3 times throughout the beta cycles - at some point we had to stop and ship it. =20 So I actually do appreciate the feedback from those on the list. Though preferably, please send it to me directly. I am not able to stay current on the list as much as I would like. -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Tuesday, May 16, 2000 7:18 PM To: William Dixon Cc: ipsec@lists.tislabs.com Subject: RE: more microsoft policy issues? On Tue, 16 May 2000, William Dixon wrote: > Jan, posting this without context is just inflammatory. If it makes you > happy, send flame to me personally. The list isn't here to discuss > product bugs, postulate on what may be a bug, nor complain about the > wording on dialogs. >=20 Sorry. That's all the context I had. Maybe I was a bit hasty (in view of the recent thread). If so, I apologize. Reading the rest below, though, it sounds like if the OS can override a local decision, then you again have a scenario where I click on a choice, and win2k overrides me without telling me. Bad. I mean, what would YOU expect, if you said: Don't do ipsec. *I* would expect that ipsec will not be performed. At all. Ever. And I wasn't venting about a product bug, either (although I was hoping it would turn out to be one). it's the gratuitous overriding of user-selected policy that was the issue I meant to address. jan > The news group for Windows 2000 networking functionality in general is: > microsoft.public.win2000.networking >=20 > Or you can email NTBUGTRAQ to report verified problems or email > secure@microsoft.com to get a formal corporate response to a discovered > security weakness for any Microsoft product. >=20 > This setting is in the advanced properties of the TCPIP properties and > allows a local admin to select a default IPSec policy. By default the > selection is says in text "Do not use IPSec". This is a local setting > which can be overridden by Win2k domain IPSec policy, and by OS > components such as L2TP which require IPSec for their operation. And > once again, the behavior is documented in online help and elsewhere. > The TCPIP properties UI is a quick and easy way for an admin to change > between different custom policies that have been created on the local > system. >=20 > As one of our KB articles notes, we provide the default policies as an > example only, for initial testing only - real production use requires > your own custom designed IPSec policy. =20 >=20 >=20 > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Tuesday, May 16, 2000 2:01 PM > To: ipsec@lists.tislabs.com > Cc: William Dixon > Subject: more microsoft policy issues? >=20 >=20 > >From an email I just saw going across my desk: >=20 > > Even though the "do not use IPSec" is marked in the W2000 > configuration the > > W2000 client still uses IPSec. Please note in Windows 2000 build 2195 > > Microsoft have decided to use IPSec all the time. >=20 > Come on, guys! Please tell me that THIS at least is a bug, and not > another one > of those design decisions... >=20 > jan > P.S. Caveat: I don't have any idea of build numbers. Maybe 2195 is > really old > and this is already fixed... > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose (408) > 527-0847 >=20 >=20 -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 ------_=_NextPart_001_01BFC021.DC9C3D06 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: more microsoft policy issues?

If you don't want IPSec ever & don't want = L2TP/IPSec VPN connections, the local admin can shutdown the IPSec = Policy Agent service, and/or disable the service entirely.  The = roles of "users" in general in Win2k, be they domain admins, = local admins, backup operators, local users, guests, etc and associated = security configurations & activities by those users are defined by = the OS security team for the entire OS, and IPSec as a service is = consistent as possible with that model and the rest of the components in = the OS which provide manageability of the platform. 

This is why taking any particular IPSec functionality = on it's own, out of context, elevating it to philosophical levels, just = isn't going to be a productive discussion.  Win2k IPSec is designed = to be a centrally administrated tool to increase the protection of OS = & application traffic.  We have had many smart & = knowledgeable people working on this, and many more external to the = product team looking at it to ensure quality of design and = implementation, not to mention worldwide beta testing, for literally 3 = years.  The UI was revised 3 times throughout the beta cycles - at = some point we had to stop and ship it. 

So I actually do appreciate the feedback from those on = the list.  Though preferably, please send it to me directly.  = I am not able to stay current on the list as much as I would = like.

-----Original Message-----
From: Jan Vilhuber [mailto:vilhuber@cisco.com]
Sent: Tuesday, May 16, 2000 7:18 PM
To: William Dixon
Cc: ipsec@lists.tislabs.com
Subject: RE: more microsoft policy issues?


On Tue, 16 May 2000, William Dixon wrote:
> Jan, posting this without context is just = inflammatory.  If it makes you
> happy, send flame to me personally.  The = list isn't here to discuss
> product bugs, postulate on what may be a bug, = nor complain about the
> wording on dialogs.
>
Sorry. That's all the context I had. Maybe I was a = bit hasty (in view of the
recent thread). If so, I apologize.

Reading the rest below, though, it sounds like if the = OS can override a local
decision, then you again have a scenario where I = click on a choice, and win2k
overrides me without telling me. Bad. I mean, what = would YOU expect, if you
said: Don't do ipsec. *I* would expect that ipsec = will not be performed. At
all. Ever.

And I wasn't venting about a product bug, either = (although I was hoping it
would turn out to be one). it's the gratuitous = overriding of user-selected
policy that was the issue I meant to address.

jan



> The news group for Windows 2000 networking = functionality in general is:
> microsoft.public.win2000.networking
>
> Or you can email NTBUGTRAQ to report verified = problems or email
> secure@microsoft.com to get a formal corporate = response to a discovered
> security weakness for any Microsoft = product.
>
> This setting is in the advanced properties of = the TCPIP properties and
> allows a local admin to select a default IPSec = policy.  By default the
> selection is says in text "Do not use = IPSec".  This is a local setting
> which can be overridden by Win2k domain IPSec = policy, and by OS
> components such as L2TP which require IPSec for = their operation.  And
> once again, the behavior is documented in online = help and elsewhere.
> The TCPIP properties UI is a quick and easy way = for an admin to change
> between different custom policies that have been = created on the local
> system.
>
> As one of our KB articles notes, we provide the = default policies as an
> example only, for initial testing only - real = production use requires
> your own custom designed IPSec policy.  =
>
>
> -----Original Message-----
> From: Jan Vilhuber [mailto:vilhuber@cisco.com]
> Sent: Tuesday, May 16, 2000 2:01 PM
> To: ipsec@lists.tislabs.com
> Cc: William Dixon
> Subject: more microsoft policy issues?
>
>
> >From an email I just saw going across my = desk:
>
> > Even though the "do not use = IPSec" is marked in the W2000
> configuration the
> > W2000 client still uses IPSec.  Please = note in Windows 2000 build 2195
> > Microsoft have decided to use IPSec all the = time.
>
> Come on, guys! Please tell me that THIS at least = is a bug, and not
> another one
> of those design decisions...
>
> jan
> P.S. Caveat: I don't have any idea of build = numbers. Maybe 2195 is
> really old
> and this is already fixed...
>  --
> Jan Vilhuber
> vilhuber@cisco.com
> Cisco Systems, San = Jose           &nb= sp;           &nbs= p;            = ; (408)
> 527-0847
>
>

 --
Jan = Vilhuber           = ;            =             &= nbsp;        = vilhuber@cisco.com
Cisco Systems, San = Jose           &nb= sp;           &nbs= p;            = ; (408) 527-0847

------_=_NextPart_001_01BFC021.DC9C3D06-- From owner-ipsec@lists.tislabs.com Wed May 17 14:47:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10082; Wed, 17 May 2000 14:47:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29160 Wed, 17 May 2000 16:39:18 -0400 (EDT) Date: Wed, 17 May 2000 13:46:28 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Chris Trobridge cc: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: <1FD60AE4DB6CD2118C420008C74C27B854A38B@baltimore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This would be the Authorization piece of the Authentication, Authorization, and Accounting infrastructure. chinna On Wed, 17 May 2000, Chris Trobridge wrote: > > From: CHINNA N.R. PELLACURU [mailto:pcn@cisco.com] > > > When we use L2TP to provide a VPN link to a user into the > > private network, > > it is just emulating as if the user is on the private > > network. When a user > > requests for VPN access, he has to authenticate and prove his > > credentials > > before he can gain access to private network. > > > > Once the user has gained access, he is virtually on the private network. > > He can do whatever he would be normally allowed to do when he is > > physically on the private network. So, if your private network allows one > > user to easily spoof other users, then that is _not_ a failure of the VPN > > technology, but your security infrastructure in the private network. > > This assumes that policy does treat 'dial-in' users as the same as networks > physically on the network. I think this is an invalid assumption. I am > sure that certain organsisations would regard remote access as being less > secure and would want to restrict the resources that could be accessed > remotely. This doesn't even have to mean that the VPN technology itself is > inadequate, merely that the environment that the remote user is operating in > may not be regarded to be secure enough. > > Chris > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed May 17 16:17:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11937; Wed, 17 May 2000 16:17:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04614 Wed, 17 May 2000 18:10:38 -0400 (EDT) Date: Wed, 17 May 2000 18:18:26 -0400 Message-Id: <200005172218.SAA22950@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: ipsec@lists.tislabs.com In-reply-to: Chris Trobridge's message of Wed, 10 May 2000 11:20:43 +0100, <1FD60AE4DB6CD2118C420008C74C27B854A310@baltimore.com> Subject: A Gentle Reminder.... Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just as a gentle reminder, the ipsec list's main purpose is to discsuss work items of the IPSEC working group. That is, issues relating to the standardization of IPSEC. While some off-topic comments are fine, this list should not be used: *) To make public denounciations of a particular company's IPSEC implementation. (Discussions of whether something behaviour is compliant with the standard is one thing; name calling, whether or not you think the company deserves it, is quite another.) *) As a support channel for a particular IPSEC implementation. Let's try to stay on topic here..... - Ted From owner-ipsec@lists.tislabs.com Wed May 17 16:41:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12491; Wed, 17 May 2000 16:41:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04689 Wed, 17 May 2000 18:51:05 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 17 May 2000 15:57:28 -0700 (PDT) From: Jan Vilhuber To: "Scott G. Kelly" cc: "W. Mark Townsley" , Ari Huttunen , Stephen Kent , "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) In-Reply-To: <3922C8E6.D94902D4@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 17 May 2000, Scott G. Kelly wrote: > The point has been made that some sort of aaa infrastructure has been > deployed for dial-up users, and that customers should not be asked to > discard this. Please clarify what components would be discarded if we do > not use l2tp. For example, I know of several ipsec vendors who implement > some sort of radius interaction without using either ppp or l2tp, so it > seems that radius investments are not necessarily in jeopardy here. > Please address this. > That's exactly my point though: There's certainly people that have implemented this, but what they had to do was essentially *re-implement* the radius interaction (if not define it from scratch), whereas PPP has hashed all this out over the years, and there would not have to be any re-inventing and/or re-implementing. Example: Config-mode does address-assignment, dns and wins assignment, and so forth. PPP already does all this. PPP also does more (look at some fairly complex radius profile for PPP; I can't find any in my radius directory off-hand), which you'd have to define and implement in config-mode (or some other mechanism). Why bother? it's been done. it's solved. Let's use it. Another example: xauth and all the different authentication types. While radius isn't a stellar example in this case (tacacs+ handles things like EAP better, I think; but let's please not get into a flame-war about which is better.. it's an example), do you really want to reinvent all the different authentication type (token card, next pin mode, chap, PAP, EAP, skey, etc etc) in xauth when it's already been done in PPP? The code exists, is well-seasoned and well-tested. L2tp gives you all those for free via PPP. I see no reason to reinvent them in IKE/IPSEC and clutter the rfc's and the already complex code. jan > Secondly, in response to overhead concerns, the point has been made that > there are various header compression schemes available in ppp/l2tp which > mitigate this. While this response addresses the on-the-wire overhead to > some extent, it ignores the additional packet processing overhead and > complexity that wrapping the packets in 2 more protocols (all the while > doing header compression) entails. Please address this. > > Finally, in response to the security issues raised by obscuring the > transit selectors from the ipsec machinery, the argument has been made > that ppp provides all the necessary protections. However, this is not > all that reassuring, and conjures up images of the left hand not knowing > what the right hand is doing. Please elaborate a bit on how this > mechanism provides comparable assurance to one where ipsec is employed > alone. > > Scott > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed May 17 18:20:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20170; Wed, 17 May 2000 18:20:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04964 Wed, 17 May 2000 20:24:45 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 17 May 2000 17:31:07 -0700 (PDT) From: Jan Vilhuber To: "Scott G. Kelly" cc: "W. Mark Townsley" , Ari Huttunen , Stephen Kent , "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) In-Reply-To: <39233781.ED3C41A4@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 17 May 2000, Scott G. Kelly wrote: > > L2tp gives you all those for free via PPP. I see no reason to reinvent them > > in IKE/IPSEC and clutter the rfc's and the already complex code. > > Free? It seems like implementing ppp and l2tp, and then encapsulating > transit traffic in this, and then encapsulating all that in udp prior to > encapsulating *that* in ipsec is far from free. > I suppose. I'm looking at it from the perspective of one who simply leverages what the l2tp and PPP groups have written. Hooking it in is mostly free for me (guilty as charged ;). As I mentioned in private email, I'm sure there are implementations for l2tp and PPP out there, either freeware or something you can buy from some company and intergrate into your code. I doubt you'd write it from scratch. Hooking the two together isn't hard, although some of the 'l2tp needs to know about the SA' issues need to be addressed, which are part of the 'glue to put the two together (and part of the l2tp security draft which Mark mentioned). I'm also looking at it from the point of view of someone who used to work in the AAA group, so I have a fair amount of experience trying to fit the AAA framework into yet another application (not painless at all, and I don't think it's because of our implementation; it's mostly to do with semantics of the radius attributes). I also wrote our xauth implementation, which was a hairy experience, and I know PPP somewhat (not too well, though). So much for my resume ;) Based on all that, I hate xauth, and I like PPP for this stuff. I'm sorry I can't make a better argument than that. I guess some of it is gut-feel. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed May 17 18:20:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20174; Wed, 17 May 2000 18:20:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04930 Wed, 17 May 2000 20:10:25 -0400 (EDT) Message-ID: <39233781.ED3C41A4@redcreek.com> Date: Wed, 17 May 2000 17:21:21 -0700 From: "Scott G. Kelly" 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 To: Jan Vilhuber CC: "W. Mark Townsley" , Ari Huttunen , Stephen Kent , "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jan, Jan Vilhuber wrote: > > On Wed, 17 May 2000, Scott G. Kelly wrote: > > The point has been made that some sort of aaa infrastructure has been > > deployed for dial-up users, and that customers should not be asked to > > discard this. Please clarify what components would be discarded if we do > > not use l2tp. For example, I know of several ipsec vendors who implement > > some sort of radius interaction without using either ppp or l2tp, so it > > seems that radius investments are not necessarily in jeopardy here. > > Please address this. > > > That's exactly my point though: There's certainly people that have > implemented this, but what they had to do was essentially *re-implement* the > radius interaction (if not define it from scratch), whereas PPP has hashed > all this out over the years, and there would not have to be any re-inventing > and/or re-implementing. While I see some merit in this, I think it ignores that fact that this "reimplementing" may be as simple as cutting and pasting code, and adding calls to it from the appropriate place. It also seems to ignore the large amount of additional functionality (and complexity) the 2 additional protocol layers (or is it 3 once you encap l2tp in udp?) bring to the table compared to this cutting and pasting. > Example: Config-mode does address-assignment, dns and wins assignment, and so > forth. PPP already does all this. PPP also does more (look at some fairly > complex radius profile for PPP; I can't find any in my radius directory > off-hand), which you'd have to define and implement in config-mode (or some > other mechanism). Why bother? it's been done. it's solved. Let's use it. Yes, but dhcp also provides all of this config functionality, and it did so before such functionality was replicated in ppp (and config-mode). Also, there is dhcp functionality which ppp _does not_ provide, and so you would still have to implement dhcp either way (or lose the functionality). That being the case, I don't think ppp adds anything useful in this regard. > Another example: xauth and all the different authentication types. While > radius isn't a stellar example in this case (tacacs+ handles things like EAP > better, I think; but let's please not get into a flame-war about which is > better.. it's an example), do you really want to reinvent all the different > authentication type (token card, next pin mode, chap, PAP, EAP, skey, etc > etc) in xauth when it's already been done in PPP? The code exists, is > well-seasoned and well-tested. An earlier draft on this topic pointed out that eap could be encap'd in udp to fulfill this functionality. Since eap ostensibly encompasses all of the other mechanisms named, this mechanism would be far simpler than l2tp. No matter what, the sgw at the headend has to have some sort of authentication server application running if you intend to support these legacy mechanisms. If you run ppp/l2tp, your ppp code will somehow call into this code, which will interact with the backend {radius,tacacs,what-have-you} server. If you run eap-in-udp over ipsec you get the legacy auth mechanism, but you've jettisoned all of the encapsulation contortions required by the l2tp/ppp solution in favor of something much simpler, I think. > L2tp gives you all those for free via PPP. I see no reason to reinvent them > in IKE/IPSEC and clutter the rfc's and the already complex code. Free? It seems like implementing ppp and l2tp, and then encapsulating transit traffic in this, and then encapsulating all that in udp prior to encapsulating *that* in ipsec is far from free. Scott From owner-ipsec@lists.tislabs.com Wed May 17 20:13:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA05625; Wed, 17 May 2000 20:13:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA05170 Wed, 17 May 2000 22:08:00 -0400 (EDT) Date: Wed, 17 May 2000 19:14:35 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: "Scott G. Kelly" cc: Jan Vilhuber , "W. Mark Townsley" , Ari Huttunen , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) In-Reply-To: <39233781.ED3C41A4@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I had brought this up before: Isn't securing EAP within an IKE exchange, considered to be an overhead? chinna On Wed, 17 May 2000, Scott G. Kelly wrote: > Hi Jan, > > Jan Vilhuber wrote: > > > > On Wed, 17 May 2000, Scott G. Kelly wrote: > > > The point has been made that some sort of aaa infrastructure has been > > > deployed for dial-up users, and that customers should not be asked to > > > discard this. Please clarify what components would be discarded if we do > > > not use l2tp. For example, I know of several ipsec vendors who implement > > > some sort of radius interaction without using either ppp or l2tp, so it > > > seems that radius investments are not necessarily in jeopardy here. > > > Please address this. > > > > > That's exactly my point though: There's certainly people that have > > implemented this, but what they had to do was essentially *re-implement* the > > radius interaction (if not define it from scratch), whereas PPP has hashed > > all this out over the years, and there would not have to be any re-inventing > > and/or re-implementing. > > While I see some merit in this, I think it ignores that fact that this > "reimplementing" may be as simple as cutting and pasting code, and > adding calls to it from the appropriate place. It also seems to ignore > the large amount of additional functionality (and complexity) the 2 > additional protocol layers (or is it 3 once you encap l2tp in udp?) > bring to the table compared to this cutting and pasting. > > > Example: Config-mode does address-assignment, dns and wins assignment, and so > > forth. PPP already does all this. PPP also does more (look at some fairly > > complex radius profile for PPP; I can't find any in my radius directory > > off-hand), which you'd have to define and implement in config-mode (or some > > other mechanism). Why bother? it's been done. it's solved. Let's use it. > > Yes, but dhcp also provides all of this config functionality, and it did > so before such functionality was replicated in ppp (and config-mode). > Also, there is dhcp functionality which ppp _does not_ provide, and so > you would still have to implement dhcp either way (or lose the > functionality). That being the case, I don't think ppp adds anything > useful in this regard. > > > Another example: xauth and all the different authentication types. While > > radius isn't a stellar example in this case (tacacs+ handles things like EAP > > better, I think; but let's please not get into a flame-war about which is > > better.. it's an example), do you really want to reinvent all the different > > authentication type (token card, next pin mode, chap, PAP, EAP, skey, etc > > etc) in xauth when it's already been done in PPP? The code exists, is > > well-seasoned and well-tested. > > An earlier draft on this topic pointed out that eap could be encap'd in > udp to fulfill this functionality. Since eap ostensibly encompasses all > of the other mechanisms named, this mechanism would be far simpler than > l2tp. No matter what, the sgw at the headend has to have some sort of > authentication server application running if you intend to support these > legacy mechanisms. If you run ppp/l2tp, your ppp code will somehow call > into this code, which will interact with the backend > {radius,tacacs,what-have-you} server. If you run eap-in-udp over ipsec > you get the legacy auth mechanism, but you've jettisoned all of the > encapsulation contortions required by the l2tp/ppp solution in favor of > something much simpler, I think. > > > L2tp gives you all those for free via PPP. I see no reason to reinvent them > > in IKE/IPSEC and clutter the rfc's and the already complex code. > > Free? It seems like implementing ppp and l2tp, and then encapsulating > transit traffic in this, and then encapsulating all that in udp prior to > encapsulating *that* in ipsec is far from free. > > Scott > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Wed May 17 21:55:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA15277; Wed, 17 May 2000 21:55:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA05385 Wed, 17 May 2000 23:45:25 -0400 (EDT) Date: Wed, 17 May 2000 23:52:27 -0400 (EDT) From: Skip Booth To: "Scott G. Kelly" cc: "W. Mark Townsley" , Ari Huttunen , Stephen Kent , "CHINNA N.R. PELLACURU" , ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) In-Reply-To: <3922C8E6.D94902D4@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 17 May 2000, Scott G. Kelly wrote: > I've been asking this question elsewhere, but all the action seems to be > here. That being the case, I'll jump threads. I'm trying to objectively > determine the benefits (and drawbacks) of accepting l2tp/ipsec as a > remote access solution. I'm also interested in whether there are any > other non-rmt-access benefits. Scott, thank you for trying to add some process/sanity to this discussion. Sorry for the long response. BTW, I thought there was an effort by a few people to try and capture the pros/cons of each proposal in terms of meeting the stated requirements of IPSRA charter and put this information into the form of a draft. Is this happening? > > Clearly, folks who have been working on l2tp (and ppp) for years feel > quite strongly about this, but strongly-held views are only helpful here > when backed up with objective reasoning. That's what I'm after. > > The point has been made that some sort of aaa infrastructure has been > deployed for dial-up users, and that customers should not be asked to > discard this. Please clarify what components would be discarded if we do > not use l2tp. For example, I know of several ipsec vendors who implement > some sort of radius interaction without using either ppp or l2tp, so it > seems that radius investments are not necessarily in jeopardy here. > Please address this. Certainly you don't need PPP or L2TP to interact with a AAA server. However PPP and it's interaction with AAA has been deployed for a long time and is very mature. Over time customers have asked for fairly nifty features relating to their PPP and AAA deployment, some of which have become standardized and some of which are vendor specific. PPP does have well defined mechanisms for when to start authentication, how to apply authorization, and when to start and stop accounting. Accounting in particular is of some concern to me when dealing with IPsec by itself, since there is no well defined, robust mechanism to determine when the user logs off and thus stop accounting. Both PPP and L2TP have well defined mechanisms for both controlled teardowns (ie, LCP TermReq/TermAck and StopCCN) and keepalives for detecting a non-graceful teardown. Additionally, applying authorization information such as filters, allowed connection time, idle timeouts, login banners, etc to IPsec seems to require more invention than just reusing a protocol which already knows how to do this. Maybe there are some vendors which don't have all this PPP and L2TP code and it's easier for them to just design this into IPsec and IKE. I for one don't like this approach since I don't think its good design practice to try and make one protocol satify all requirements for different spaces since it will inevitably fail to do any one well. I also don't like the fact that our customers will have to go through all the trials and tribulations over again as we rewrite this code just to give them what they already have with traditional dial-up PPP connections. > > Secondly, in response to overhead concerns, the point has been made that > there are various header compression schemes available in ppp/l2tp which > mitigate this. While this response addresses the on-the-wire overhead to > some extent, it ignores the additional packet processing overhead and > complexity that wrapping the packets in 2 more protocols (all the while > doing header compression) entails. Please address this. For PPP, the header compression details are a no-op, at least for our implementation. PPP is really just a few extra lines of code in our switching path, regardless of whether it is doing AFC and/or PFC. L2TP certainly adds some additionally switching overhead since there are tunnel/session lookups on a per packet basis, similar to what IPsec must perform on inbound and outbound SA lookups, except obviously less expensive since no filtering is involved. Although we have not implemented the L2TP Header compression draft yet, in looking at it, it should be a no-op in terms of per-packet overhead. If you employ L2TP HC and PPP AFC/PFC, then the overhead for running PPP over IPsec is only 2 bytes. If you run IPsec in transport mode, then I believe this actually is less header overhead than running IPsec in tunnel mode. You also get the benefit of multi-protocol support through PPP. > > Finally, in response to the security issues raised by obscuring the > transit selectors from the ipsec machinery, the argument has been made > that ppp provides all the necessary protections. However, this is not > all that reassuring, and conjures up images of the left hand not knowing > what the right hand is doing. Please elaborate a bit on how this > mechanism provides comparable assurance to one where ipsec is employed > alone. There are certainly two camps here and it almost becomes a religous discussion. My argument has always been that protecting L2TP with IPsec provides the same level of security which our customers have today with their traditional networks. If I have an IPsec SA set up between two peers (A and B), and the traffic which is protected between us is A <-> B, UDP, port 1701, 1701 than the only traffic which L2TP should *ever* see is traffic which arrived from that SA. Otherwise it should have been dropped when performing the inbound filtering checks by IPsec. This statement requires no binding between L2TP and IPsec! Now if I want to limit the type of traffic I allow my peer to send into my network, I can apply filters to the PPP interface as has been traditionally done by our customers. They understand how this should be done and how to audit this as well. Additionally, at least for Cisco, they can get this filters on a per user basis as part of their authorization information obtained from the AAA server. The additional point which can be made is that the traditional firewall filters which can be applied to a PPP interface are much more robust than what typically can be applied to IPsec packet filter statements. In addition to the points which you brought up above, running PPP/L2TP over IPsec by definition makes this a routeable interface with all the characteristics of an interface. We have discussed this before on this list and again there are several camps which say this is just an implementation issue for IPsec. I maintain that implementation issues lead to interoperability issues and ultimately customer dissatisfaction. I think in a previous email you asked for a laundry list of what PPP/L2TP provides in this space. Well here's my list: 1) IP/DNS/WINs assignment through IPCP 2) User authentication 3) AAA integration 4) multi-protocol support 5) Link layer negotiation for MRU (this may help in the fragmentation arena) 6) Keepalives for both PPP and L2TP 7) Multilink PPP for bundling bandwidth 8) Routeable interface Note that most of these are really PPP centric. I would argue that the main reason you need L2TP in this space is that it provides a well defined, well deployed mechanism to transport PPP over IP which allows it to be protected by IPsec. If most people agree that PPP is an adequate solution to this problem but L2TP is the problem, then I am certainly open for the discussion of a better mechanism to tunnel PPP. Although I think will we be hard pressed to do so without reinventing L2TP. My biggest point about this whole discussion is that I think it would be a real shame to reinvent protocols defined by the IETF and features requested by our customers within the IPsec working group unless there is a very compelling reason why those protocols fall short of the requirements needed by the IPsec and IPSRA working groups. -Skip > > Scott > > From owner-ipsec@lists.tislabs.com Thu May 18 03:23:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08541; Thu, 18 May 2000 03:23:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA06722 Thu, 18 May 2000 04:55:21 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D28110@new-exc1.ctron.com> From: "Waters, Stephen" To: Jan Vilhuber Cc: ipsec@lists.tislabs.com Subject: RE: PPP over IPSec (Re: Windows 2000 and Cicsco router interopera bility) Date: Thu, 18 May 2000 10:02:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry, but this 'why reinvent' call seems too late - it's been done and plenty of vendors have implemented it. Keeping faith with installed Remote Access tools is common practice for IPSEC-only remote access products using a combination of the new tunnel RADIUS attributes (sometimes), and most of the old ones (except stuff like 'call-back'). I know of at least 6 shipping IPSEC client/server products that do just this, and I would not be surprised to find the actual number is much higher. So, is the path of least resistance really to implement IPSEC/L2TP/PPP as well? Steve. -----Original Message----- From: Jan Vilhuber [mailto:vilhuber@cisco.com] Sent: Wednesday, May 17, 2000 11:57 PM To: Scott G. Kelly Cc: W. Mark Townsley; Ari Huttunen; Stephen Kent; CHINNA N.R. PELLACURU; ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) On Wed, 17 May 2000, Scott G. Kelly wrote: > The point has been made that some sort of aaa infrastructure has been > deployed for dial-up users, and that customers should not be asked to > discard this. Please clarify what components would be discarded if we do > not use l2tp. For example, I know of several ipsec vendors who implement > some sort of radius interaction without using either ppp or l2tp, so it > seems that radius investments are not necessarily in jeopardy here. > Please address this. > That's exactly my point though: There's certainly people that have implemented this, but what they had to do was essentially *re-implement* the radius interaction (if not define it from scratch), whereas PPP has hashed all this out over the years, and there would not have to be any re-inventing and/or re-implementing. Example: Config-mode does address-assignment, dns and wins assignment, and so forth. PPP already does all this. PPP also does more (look at some fairly complex radius profile for PPP; I can't find any in my radius directory off-hand), which you'd have to define and implement in config-mode (or some other mechanism). Why bother? it's been done. it's solved. Let's use it. Another example: xauth and all the different authentication types. While radius isn't a stellar example in this case (tacacs+ handles things like EAP better, I think; but let's please not get into a flame-war about which is better.. it's an example), do you really want to reinvent all the different authentication type (token card, next pin mode, chap, PAP, EAP, skey, etc etc) in xauth when it's already been done in PPP? The code exists, is well-seasoned and well-tested. L2tp gives you all those for free via PPP. I see no reason to reinvent them in IKE/IPSEC and clutter the rfc's and the already complex code. jan > Secondly, in response to overhead concerns, the point has been made that > there are various header compression schemes available in ppp/l2tp which > mitigate this. While this response addresses the on-the-wire overhead to > some extent, it ignores the additional packet processing overhead and > complexity that wrapping the packets in 2 more protocols (all the while > doing header compression) entails. Please address this. > > Finally, in response to the security issues raised by obscuring the > transit selectors from the ipsec machinery, the argument has been made > that ppp provides all the necessary protections. However, this is not > all that reassuring, and conjures up images of the left hand not knowing > what the right hand is doing. Please elaborate a bit on how this > mechanism provides comparable assurance to one where ipsec is employed > alone. > > Scott > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu May 18 06:40:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA16591; Thu, 18 May 2000 06:40:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07570 Thu, 18 May 2000 08:25:26 -0400 (EDT) Message-Id: <200005171804.OAA00372@pzero.sandelman.ottawa.on.ca> To: Declan McCullagh CC: ipsec@lists.tislabs.com Subject: Re: Wired query on Windows 2000 and DES/3DES In-reply-to: Your message of "Mon, 15 May 2000 19:46:14 EDT." <4.3.0.20000515194606.01f67f00@pop.webcom.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 May 2000 14:02:52 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Declan" == Declan McCullagh writes: Declan> * They say it's for remote ease-of-maintenance: "if i misconfigured a Declan> system, rather than having to travel out to that machine to fix If the policy statements were signed authorization certificates, then this would be irrelevant. The only reason that this is necessary for maintenance is presumeably because certificate based authorizations are not yet integrated into Why2K. Management functions do not need privacy (although that is certainly desirable), they need authentication. Turning 3DES on or off should be done explicitely via sign policy certificates. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |The Internet Packet Processing Company. Hanging in SFO Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: mcr@solidum.com. From owner-ipsec@lists.tislabs.com Thu May 18 08:00:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19829; Thu, 18 May 2000 08:00:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07839 Thu, 18 May 2000 09:36:04 -0400 (EDT) Message-Id: <3.0.1.32.20000518192341.00a0a9a8@172.16.1.10> X-Sender: raghava@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 18 May 2000 19:23:41 +0500 To: ipsec@lists.tislabs.com From: raghava Subject: X86 tuned DES and 3DES Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Could anyone help me to get the free souce code of DES and 3DES that is tuned for X86? Thanks -raghava From owner-ipsec@lists.tislabs.com Thu May 18 09:58:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22970; Thu, 18 May 2000 09:58:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08374 Thu, 18 May 2000 11:41:33 -0400 (EDT) Date: Thu, 18 May 2000 10:47:54 -0400 From: "Michael H. Warfield" To: raghava Cc: ipsec@lists.tislabs.com Subject: Re: X86 tuned DES and 3DES Message-ID: <20000518104754.E1879@alcove.wittsend.com> References: <3.0.1.32.20000518192341.00a0a9a8@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.5i In-Reply-To: <3.0.1.32.20000518192341.00a0a9a8@172.16.1.10>; from raghava@trinc.com on Thu, May 18, 2000 at 07:23:41PM +0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, May 18, 2000 at 07:23:41PM +0500, raghava wrote: > Hi, > Could anyone help me to get the free souce code of DES and 3DES that is > tuned for X86? Look in the OpenSSL libraries. www.openssl.org. > Thanks > -raghava Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ipsec@lists.tislabs.com Thu May 18 10:12:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23333; Thu, 18 May 2000 10:12:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08472 Thu, 18 May 2000 12:03:59 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 18 May 2000 09:10:24 -0700 (PDT) From: Jan Vilhuber To: "Waters, Stephen" cc: ipsec@lists.tislabs.com Subject: RE: PPP over IPSec (Re: Windows 2000 and Cicsco router interopera bility) In-Reply-To: <29752A74B6C5D211A4920090273CA3DC01D28110@new-exc1.ctron.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 18 May 2000, Waters, Stephen wrote: > Sorry, but this 'why reinvent' call seems too late - it's been done > and plenty of vendors have implemented it. > > Keeping faith with installed Remote Access tools is common practice > for IPSEC-only remote access products using a combination of the new > tunnel RADIUS attributes (sometimes), and most of the old ones (except > stuff like 'call-back'). > > I know of at least 6 shipping IPSEC client/server products that do > just this, and I would not be surprised to find the actual number is > much higher. > > So, is the path of least resistance really to implement IPSEC/L2TP/PPP > as well? > Speaking for a vendor that has BOTH (yes, I've also implemented some (limited) RADIUS interaction), I'd say yes. jan > Steve. > > > > > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Wednesday, May 17, 2000 11:57 PM > To: Scott G. Kelly > Cc: W. Mark Townsley; Ari Huttunen; Stephen Kent; CHINNA N.R. PELLACURU; > ipsec@lists.tislabs.com > Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router > interoperability) > > > On Wed, 17 May 2000, Scott G. Kelly wrote: > > The point has been made that some sort of aaa infrastructure has been > > deployed for dial-up users, and that customers should not be asked to > > discard this. Please clarify what components would be discarded if we do > > not use l2tp. For example, I know of several ipsec vendors who implement > > some sort of radius interaction without using either ppp or l2tp, so it > > seems that radius investments are not necessarily in jeopardy here. > > Please address this. > > > That's exactly my point though: There's certainly people that have > implemented this, but what they had to do was essentially *re-implement* the > radius interaction (if not define it from scratch), whereas PPP has hashed > all this out over the years, and there would not have to be any re-inventing > and/or re-implementing. > > Example: Config-mode does address-assignment, dns and wins assignment, and > so > forth. PPP already does all this. PPP also does more (look at some fairly > complex radius profile for PPP; I can't find any in my radius directory > off-hand), which you'd have to define and implement in config-mode (or some > other mechanism). Why bother? it's been done. it's solved. Let's use it. > > Another example: xauth and all the different authentication types. While > radius isn't a stellar example in this case (tacacs+ handles things like EAP > better, I think; but let's please not get into a flame-war about which is > better.. it's an example), do you really want to reinvent all the different > authentication type (token card, next pin mode, chap, PAP, EAP, skey, etc > etc) in xauth when it's already been done in PPP? The code exists, is > well-seasoned and well-tested. > > L2tp gives you all those for free via PPP. I see no reason to reinvent them > in IKE/IPSEC and clutter the rfc's and the already complex code. > > jan > > > Secondly, in response to overhead concerns, the point has been made that > > there are various header compression schemes available in ppp/l2tp which > > mitigate this. While this response addresses the on-the-wire overhead to > > some extent, it ignores the additional packet processing overhead and > > complexity that wrapping the packets in 2 more protocols (all the while > > doing header compression) entails. Please address this. > > > > Finally, in response to the security issues raised by obscuring the > > transit selectors from the ipsec machinery, the argument has been made > > that ppp provides all the necessary protections. However, this is not > > all that reassuring, and conjures up images of the left hand not knowing > > what the right hand is doing. Please elaborate a bit on how this > > mechanism provides comparable assurance to one where ipsec is employed > > alone. > > > > Scott > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu May 18 12:13:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26224; Thu, 18 May 2000 12:13:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08783 Thu, 18 May 2000 13:52:38 -0400 (EDT) Message-ID: <39243077.E0C42244@redcreek.com> Date: Thu, 18 May 2000 11:03:35 -0700 From: "Scott G. Kelly" 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 To: "CHINNA N.R. PELLACURU" CC: Jan Vilhuber , "W. Mark Townsley" , Ari Huttunen , Stephen Kent , ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Chinna, "CHINNA N.R. PELLACURU" wrote: > > I had brought this up before: Isn't securing EAP within an IKE exchange, > considered to be an overhead? > > chinna I don't want to go off on this tangent right now, as it was incidental to the discussion, but I will point out 2 things: first, the proposal was not to secure the eap within an ike exchange. Second, I don't think we can avoid adding overhead if we add functionality, but I think we should strive to minimize that added overhead. Scott From owner-ipsec@lists.tislabs.com Thu May 18 13:31:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28141; Thu, 18 May 2000 13:31:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09093 Thu, 18 May 2000 15:29:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Thu, 18 May 2000 12:35:42 -0400 To: Jan Vilhuber From: Stephen Kent Subject: RE: Windows 2000 and Cicsco router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan, >On Tue, 16 May 2000, Stephen Kent wrote: > > The "features that AAA provides?" AAA is a WG but there are no AAA > > standards yet. In fact, the WG drafts so far focusing only on > > requirements for the protocols that will be standardized, in the > > future. So a reference to what "AAA provides" or to "customers who > > are so fond of their AAA infrastructure" appears to be in the future, > > optimistic tense. > > >That's patently false, I fear. What chinna is referring to is the interaction >(well defined) of Radius Authentication, Authorization and accounting >(generally referred to as AAA) and PPP (and I expect you knew all that). No, I did not infer that from Cinna's message. If that was the intent, it was a very inarticulate way to communicate that notion. >That the AAA group is back to the drawing board is not the issue. The >"customers who are so fond of their AAA infrastructure" obviously refers to >the radius infrastructure. While chinna could have been more precise, I >always equate them in my mind as well. > >I can tell you from personal experience that people want to shoehorn >EVERYTHING into radius. They'll want this here as well (I've already gotten >multiple requests about this). I guarantee it'll happen (or your money back). I don't doubt that, but that does not make it the right thing to do. Marketing folks should say yes to everything a customer asks for; engineers should put more thought into solutions, anticipating long term implications. NAT is representative of what one gets by catering to customer's near term "needs." Steve From owner-ipsec@lists.tislabs.com Thu May 18 13:33:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28202; Thu, 18 May 2000 13:33:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09105 Thu, 18 May 2000 15:30:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Thu, 18 May 2000 13:02:11 -0400 To: Skip Booth From: Stephen Kent Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Skip, > > Finally, in response to the security issues raised by obscuring the > > transit selectors from the ipsec machinery, the argument has been made > > that ppp provides all the necessary protections. However, this is not > > all that reassuring, and conjures up images of the left hand not knowing > > what the right hand is doing. Please elaborate a bit on how this > > mechanism provides comparable assurance to one where ipsec is employed > > alone. > >There are certainly two camps here and it almost becomes a religous >discussion. >My argument has always been that protecting L2TP with IPsec provides the same >level of security which our customers have today with their traditional >networks. If I have an IPsec SA set up between two peers (A and B), and the >traffic which is protected between us is A <-> B, UDP, port 1701, >1701 than the >only traffic which L2TP should *ever* see is traffic which arrived >from that SA. >Otherwise it should have been dropped when performing the inbound filtering >checks by IPsec. This statement requires no binding between L2TP and IPsec! I'm confused by this explanation. IPsec used with L2TP operates in transport mode, and it is the inner IP header (carried above L2TP) that determines the ultimate destination for the received packet. IPsec at the receiver does not see that header, because it is operating in transport mode. So, what IPsec filtering at which end do you assert is providing the check you cite above? >Now if I want to limit the type of traffic I allow my peer to send into my >network, I can apply filters to the PPP interface as has been >traditionally done >by our customers. They understand how this should be done and how >to audit this >as well. Additionally, at least for Cisco, they can get this filters on a per >user basis as part of their authorization information obtained from the AAA >server. The additional point which can be made is that the >traditional firewall >filters which can be applied to a PPP interface are much more robust than what >typically can be applied to IPsec packet filter statements. In what ways are the filters applied at the PPP interface "more robust?" For example, do these filters examine other parts of the packet? Steve From owner-ipsec@lists.tislabs.com Thu May 18 13:37:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28296; Thu, 18 May 2000 13:37:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09099 Thu, 18 May 2000 15:30:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3922c5d60.4e3f@databus.databus.com> References: <3922c5d60.4e3f@databus.databus.com> Date: Thu, 18 May 2000 12:40:54 -0400 To: Barney Wolff From: Stephen Kent Subject: RE: Windows 2000 and Cicsco router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:10 PM -0400 5/17/00, Barney Wolff wrote: >As a non-Cisco, non-MS L2TP developer, let me say that benign neglect >of L2TP by the IPsec group would be a welcome advance. What we've >seen has been active disparagement by certain IPsec'ers, apparently >based on assumptions that do not match how anybody's L2TP or PPP >implementations really work. As one of the folks you to whom you are undoubtedly referring, let me just note that the IETF creates standards and we evaluate the merits of WG efforts based on what the standards documents say, not by what vendors may choose to implement irrespective of the standards. steve From owner-ipsec@lists.tislabs.com Thu May 18 13:42:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28446; Thu, 18 May 2000 13:42:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09117 Thu, 18 May 2000 15:30:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Thu, 18 May 2000 13:25:13 -0400 To: "CHINNA N.R. PELLACURU" From: Stephen Kent Subject: RE: Windows 2000 and Cicsco router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:18 PM -0700 5/16/00, CHINNA N.R. PELLACURU wrote: >"Several folks have suggested that one might choose to enforce access >control at the IP layer, but not in the context of IPsec, e.g., by >passing SA info to a separate firewall for post IPsec checking. If >the firewall is part of the same device as the IPsec module, the this >can be effected in a local fashion that would be consistent with >2401, as the management interface for the combined firewall/SG would >have the necessary properties." > >That pretty much sums up, what I was trying to say. Then you did so in a very inarticulate fashion. > If you loose >granularity of access control because you are tunneling traffic in L2TP >and you are protecting L2TP with IPSec, we can still enforce access >control outside of the context of IPSec, and let the trust/security flow >from one module in the system to the other. The main benefit here is that >we are leveraging services already provided by other modules in the >system, and don't have to do everything in IPSec. if the set of access control services is identical, or a superset, and if the internal bindings are correctly maintained, then I have no objection. >I think that, this was the main point of contention when we started on >this thread. > >If you feel that I am being paranoid of the letter x, I guess you are >paranoid about the L2TP protocol, and the whole myth that >L2TP=Microsoft+Cisco. Myths almost always have a basis in fact :-). Steve From owner-ipsec@lists.tislabs.com Thu May 18 13:44:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28509; Thu, 18 May 2000 13:44:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09111 Thu, 18 May 2000 15:30:24 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3922288D.CD0132BD@cisco.com> References: <3921B453.E9572D4E@cisco.com> <3922288D.CD0132BD@cisco.com> Date: Thu, 18 May 2000 13:22:24 -0400 To: "W. Mark Townsley" From: Stephen Kent Subject: Re: Windows 2000 and Cicsco router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, >2 bytes and you get multiprotocol capability. Heck, it would not be too >difficult to even reduce this to 0 bytes if one is *that* concerned and >does not mind limiting oneself to a single NCP within PPP. If one were using these tunnels for carrying protocols other than IP, I would agree completely. But, tunneling IP in this fashion is a layering anomaly and I always object to such anomalies. > > > essential for the function in question. Still, from a single, dialup > > host, it's not clear under what circumstances the multi-packet muxing > > will be invoked. > >The driving force for ppp mux as I remember is for voice packets at >aggregation points in a wireless network. There could be others, but the >point I was really making is that there are all sorts of things that the >pppext WG has done for point to point remote access connections. What >makes a secure tunnelled point to point connection so special? I see a >VPN connection stepping in to replace what was traditionally a dialup or >leased line. Utilizing the facilities that are in place and expanding >upon them makes a great deal practical sense. I do see a basis for disagreement here as well. IPsec is a mechanism that does more that create a crypto-protected path. Access control is integral to IPsec because of the need to bind crypto-authenticated identity and a set of policy-based security parameters to the path, so as to provide better security. The problems we're seeing here is that there are multiple points at which to effect the access control, based on the context in which IPsec is used. However, most of these have the property that they were not articulated in IETF standards at the time IPsec was developed, certainly not at the time we initiated the IPsec work, and not even at the time the IPsec RFCs were issued. Moerover, stand alone, native IPsec devices are common and represent the only (current?) means to achieve high speed IPsec service. When such devices are used, one cannot achieve the same level of access control via external devices (e.g., firewalls), so it seems to make sense to retain these features as part of the IPsec spec. As noted before, if a single device implements multiple functions, e.g., IPsec and a firewall) then it can be IPsec-compliant if the black box functioning of the device is consistent with (or is a superset of) what is reuqired soley for an IPsec module. Steve From owner-ipsec@lists.tislabs.com Thu May 18 13:52:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA28689; Thu, 18 May 2000 13:52:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09358 Thu, 18 May 2000 15:52:20 -0400 (EDT) Date: Thu, 18 May 2000 15:59:29 -0400 (EDT) From: Skip Booth To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Responses inline... On Thu, 18 May 2000, Stephen Kent wrote: > Skip, > > > > Finally, in response to the security issues raised by obscuring the > > > transit selectors from the ipsec machinery, the argument has been made > > > that ppp provides all the necessary protections. However, this is not > > > all that reassuring, and conjures up images of the left hand not knowing > > > what the right hand is doing. Please elaborate a bit on how this > > > mechanism provides comparable assurance to one where ipsec is employed > > > alone. > > > >There are certainly two camps here and it almost becomes a religous > >discussion. > >My argument has always been that protecting L2TP with IPsec provides the same > >level of security which our customers have today with their traditional > >networks. If I have an IPsec SA set up between two peers (A and B), and the > >traffic which is protected between us is A <-> B, UDP, port 1701, > >1701 than the > >only traffic which L2TP should *ever* see is traffic which arrived > >from that SA. > >Otherwise it should have been dropped when performing the inbound filtering > >checks by IPsec. This statement requires no binding between L2TP and IPsec! > > I'm confused by this explanation. IPsec used with L2TP operates in > transport mode, and it is the inner IP header (carried above L2TP) > that determines the ultimate destination for the received packet. > IPsec at the receiver does not see that header, because it is > operating in transport mode. So, what IPsec filtering at which end do > you assert is providing the check you cite above? My point here was that PPP will only see traffic which was sent through the L2TP tunnel and thus protected by IPsec. You are indeed correct that the inner IP address obtained through IPCP is not looked at by IPsec. However once the L2TP/PPP header has been removed, any inbound access lists tied to the PPP interface may be applied to the IP packet. This effectively provides the same level of security our customers have today with their leased lines and dial-up connections, which they seem to be pretty happy with. > > > >Now if I want to limit the type of traffic I allow my peer to send into my > >network, I can apply filters to the PPP interface as has been > >traditionally done > >by our customers. They understand how this should be done and how > >to audit this > >as well. Additionally, at least for Cisco, they can get this filters on a per > >user basis as part of their authorization information obtained from the AAA > >server. The additional point which can be made is that the > >traditional firewall > >filters which can be applied to a PPP interface are much more robust than what > >typically can be applied to IPsec packet filter statements. > > In what ways are the filters applied at the PPP interface "more > robust?" For example, do these filters examine other parts of the > packet? Exactly. For instance, dscp, TCP syn, ack or fin, rst, psh, precedence/tos are common filter fields in addition to src/dst addr, protocol, src/dst port. There are some firewalls which can even look into the application information and filter at that granularity. -Skip > > Steve > > > From owner-ipsec@lists.tislabs.com Thu May 18 14:39:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29837; Thu, 18 May 2000 14:39:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09604 Thu, 18 May 2000 16:40:05 -0400 (EDT) From: Barney Wolff To: ipsec@lists.tislabs.com Date: Thu, 18 May 2000 16:10 EDT Subject: RE: Windows 2000 and Cicsco (sic) router interoperability Content-Type: text/plain Message-ID: <3924522d0.6386@databus.databus.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So, you have communicated to the PPPEXT WG that PPP is worthless without detailed specification of the filtering behavior of a PPP device? I truly do not understand why L2TP is the single target of your scorn. It is my strong impression, from years of reading RFCs and drafts, that the primary concern is bits on the wire, with internal operation specified only when it is required to ensure interoperability. Yes, a PPP/L2TP device should not forget what it knows about where a packet came from when deciding what filter rules to apply, just as an IPsec gateway should not echo decrypted packets out to random addresses, and guns should not be fired at one's feet. Duh. Barney > Stephen Kent wrote: > > > > At 12:10 PM -0400 5/17/00, Barney Wolff wrote: > > >As a non-Cisco, non-MS L2TP developer, let me say that benign neglect > > >of L2TP by the IPsec group would be a welcome advance. What we've > > >seen has been active disparagement by certain IPsec'ers, apparently > > >based on assumptions that do not match how anybody's L2TP or PPP > > >implementations really work. > > > > As one of the folks you to whom you are undoubtedly referring, let me > > just note that the IETF creates standards and we evaluate the merits > > of WG efforts based on what the standards documents say, not by what > > vendors may choose to implement irrespective of the standards. > > > > steve > From owner-ipsec@lists.tislabs.com Thu May 18 18:10:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA08499; Thu, 18 May 2000 18:10:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10229 Thu, 18 May 2000 20:02:38 -0400 (EDT) content-class: urn:content-classes:message Subject: L2TP-IPSec features list MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC125.D71C2F44" Date: Thu, 18 May 2000 17:04:45 -0700 Message-ID: <6A05D00595BE644E9F435BE5947423F2FFC3EE@fifi.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4368.4 Thread-Topic: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) Thread-Index: Ab/BBYStIbbGCtXCQ7q6jszJlG6KZAAE+lFg From: "William Dixon" To: "William Dixon" X-OriginalArrivalTime: 19 May 2000 00:06:56.0351 (UTC) FILETIME=[25029EF0:01BFC126] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFC125.D71C2F44 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is an expansion of the features Skip noted earlier in a deep thread for L2TP/IPSec from a protocol design view, not what any particular one vendor implements. No particular order. Not a comparison with IPSec tunnel mode except for a couple of points. (bcc'ed to ipsec and ipsra WG lists to avoid reply-all) L2TP benefits --------- 1) L2TP supports 4 VPN scenarios a.) legacy client PPP dial to NAS - NAS PPP user auth, NAS forwards PPP through L2TP tunnel to L2TP gateway=20 b.) L2TP/IPSec capable client PPP dial to NAS - voluntary L2TP/IPSec to L2TP gateway c.) L2TP/IPSec capable client directly on IP network - user voluntary L2TP/IPSec tunnel to L2TP gateway d.) L2TP/IPSec gateway to gateway (2) PPP options can be varied depending on capabilities of IPSec SA, since the SA is established first - e.g. encryption & IPCOMP compression on SA means no PPP compression needed (1) idea of a user for tunnel helps scalable management of remote tunnel end-points via radius. 2) can have multiple L2TP tunnel sessions inside 1 IPSec SA pair for efficiency 3) can have single L2TP tunnel session (choose UDP source port) mapping to single IPSec SA pair - preserves binding of SA to tunnel to user - to the extent you can control what user traffic goes into tunnel to start with. 4) keep alives for L2TP 5) don't have to use L2TP sequence numbers (can't with L2TP header compression) because IPSec seq numbers can detect packet loss & estimate path latency 6) new spec for L2TP MUX of PPP packets inside a single L2TP UDP datagram - popular to reduce overhead for tunneling small IP packets, like VoIP 7) new L2TP header compression draft gets [UDP][L2TP] header overhead down to 1 or 2 bytes for majority of the tunnel. This is 1-2 bytes per packet more than pure IPSec tunnel mode - using PPPMUX mode of L2TP means several PPP frames per tunnel IP packet 8) extensibility of L2TP with Attrib Value (AV) pairs, avoid extending, complicating IKE key management protocol a.) AV delivered dynamic redirection of gateway dest IP for global load balancing b.) AV delivered QOS values 9) can use IPSec tunnel and transport filters which apply to assigned tunnel IP address above L2TP/PPP interface a.) enables tunnel within a tunnel with full interface support b.) enables static filtering & routes applied via Radius policy to tunnel interfaces 10) basic L2TP is most interoperable - even before IKE & IPSec, RFC solution designed specifically for remote access, dial remote access in particular - which estimates show to be 60-70% of the worldwide Internet connection method (PPP in general by all platforms, not L2TP/IPSec) in 2003. 11) more vendors testing L2TP/IPSec interop (14) at last bakeoff than testing XAUTH/IKECFG (7) 12) use of MM/QM in transport mode makes IPSec policy consistently transport - just an ease of maintenance thing. So IKE negotiation for L2TP (UDP port 1701) protections are just another port QM, as are QMs for other things like connections to application proxies that run on the same box. Your transport packet filters for permit & block & secure are easy to see and evaluate. You don't have to worry about a tunnel policy for access from any Client IP to an internal subnet in conflict with transport filters to block a specific type of traffic regardless of addresses.=20 13) Some vendors implement IPSec tunnels as routable interfaces, some implement as strictly filter driven - don't have to worry about this for L2TP - they are all interfaces. a.) can run routing protocols across tunnel interoperable with other vendors b.) can carry standard, routable IP across tunnel, e.g. multicast, broadcast, unicast IP 14) L2TP can be used in clear text mode without IPSec and get all of the tunneling benefits when security is not a problem. 15) Without IPSec, L2TP over IP can go through NATs because it uses UDP 1701. 16) L2TP/IPSec=20 17) L2TP/IPSec VPN clients are becoming widely available by their inclusion in Windows 2000 and future releases. Their availability for VPN has been announced since August 1998 when the L2TP/IPSec client was included in Beta2 of Windows 2000. 18) Most remote access implementations support both machine auth first with either preshared key, or much stronger certificate auth, then user auth 19) L2TP/IPSec fully replaces and is a superset of PPTP functionality and is much more secure 20) L2TP/IPSec today offers more features as RFC standard than IPSec tunnel mode does currently 21) L2TP is defined to run over ATM, frame relay and X.25 non-IP transports 22) IPSec encryption & integrity protection and IPCOMP can be hardware accelerated PPP Benefits ---------- all RFC standard methods, I believe 1) IP/DNS/WINs assignment through IPCP 2) User authentication a.) userid/password b.) EAP and EAP/TLS - for certificate, smartcard, SecurID, token card, biometric 3) AAA integration - with existing AAA servers, RADIUS TACACS 4) multi-protocol support 5) Link layer negotiation for MRU (this may help in the fragmentation arena) 6) Keepalives for both PPP 7) Multilink PPP for bundling bandwidth 8) Routable interface 9) PPP compression 10) supports idea of demand dial, so you can have demand dial filters that kick off the PPP dial activity, and different filters which apply above the interface=20 11) supports idea of persistent and autostart connections, so links can come up automatically and be maintained Wm ------_=_NextPart_001_01BFC125.D71C2F44 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable L2TP-IPSec features list

Here is an expansion of the features Skip noted = earlier in a deep thread for L2TP/IPSec from a protocol design view, not = what any particular one vendor implements.  No particular = order.  Not a comparison with IPSec tunnel mode except for a couple = of points. (bcc'ed to ipsec and ipsra WG lists to avoid = reply-all)

L2TP benefits ---------
1) L2TP supports 4 VPN scenarios
  a.) legacy client PPP dial to NAS - NAS PPP = user auth, NAS forwards PPP through L2TP tunnel to L2TP gateway
  b.) L2TP/IPSec capable client PPP dial to NAS = - voluntary L2TP/IPSec to L2TP gateway
  c.) L2TP/IPSec capable client directly on IP = network - user voluntary L2TP/IPSec tunnel to L2TP gateway
  d.) L2TP/IPSec gateway to gateway
     (2) PPP options can be = varied depending on capabilities of IPSec SA, since the SA is = established first - e.g. encryption & IPCOMP compression on SA means = no PPP compression needed

     (1) idea of a user for tunnel = helps scalable management of remote tunnel end-points via radius.
2) can have multiple L2TP tunnel sessions inside 1 = IPSec SA pair for efficiency
3) can have single L2TP tunnel session (choose UDP = source port) mapping to single IPSec SA pair - preserves binding of SA = to tunnel to user - to the extent you can control what user traffic goes = into tunnel to start with.

4) keep alives for L2TP
5) don't have to use L2TP sequence numbers (can't = with L2TP header compression) because IPSec seq numbers can detect = packet loss & estimate path latency

6) new spec for L2TP MUX of PPP packets inside a = single L2TP UDP datagram - popular to reduce overhead for tunneling = small IP packets, like VoIP

7) new L2TP header compression draft gets [UDP][L2TP] = header overhead down to 1 or 2 bytes for majority of the tunnel.  = This is 1-2 bytes per packet more than pure IPSec tunnel mode - using = PPPMUX mode of L2TP means several PPP frames per tunnel IP = packet

8) extensibility of L2TP with Attrib Value (AV) pairs, = avoid extending, complicating IKE key management protocol
  a.) AV delivered dynamic redirection of = gateway dest IP for global load balancing
  b.) AV delivered QOS values
9) can use IPSec tunnel and transport filters which = apply to assigned tunnel IP address above L2TP/PPP interface
  a.) enables tunnel within a tunnel with full = interface support
  b.) enables static filtering & routes = applied via Radius policy to tunnel interfaces
10) basic L2TP is most interoperable - even before = IKE & IPSec, RFC solution designed specifically for remote access, = dial remote access in particular - which estimates show to be 60-70% of = the worldwide Internet connection method (PPP in general by all = platforms, not L2TP/IPSec) in 2003.

11) more vendors testing L2TP/IPSec interop (14) at = last bakeoff than testing XAUTH/IKECFG (7)
12) use of MM/QM in transport mode makes IPSec policy = consistently transport - just an ease of maintenance thing.  So IKE = negotiation for L2TP (UDP port 1701) protections are just another port = QM, as are QMs for other things like connections to application proxies = that run on the same box.  Your transport packet filters for permit = & block & secure are easy to see and evaluate.  You don't = have to worry about a tunnel policy for access from any Client IP to an = internal subnet in conflict with transport filters to block a specific = type of traffic regardless of addresses.

13) Some vendors implement IPSec tunnels as routable = interfaces, some implement as strictly filter driven - don't have to = worry about this for L2TP - they are all interfaces.

  a.) can run routing protocols across tunnel = interoperable with other vendors
  b.) can carry standard, routable IP across = tunnel, e.g. multicast, broadcast, unicast IP
14) L2TP can be used in clear text mode without IPSec = and get all of the tunneling benefits when security is not a = problem.

15) Without IPSec, L2TP over IP can go through NATs = because it uses UDP 1701.
16) L2TP/IPSec
17) L2TP/IPSec VPN clients are becoming widely = available by their inclusion in Windows 2000 and future releases.  = Their availability for VPN has been announced since August 1998 when the = L2TP/IPSec client was included in Beta2 of Windows 2000.

18) Most remote access implementations support both = machine auth first with either preshared key, or much stronger = certificate auth, then user auth

19) L2TP/IPSec fully replaces and is a superset of = PPTP functionality and is much more secure
20) L2TP/IPSec today offers more features as RFC = standard than IPSec tunnel mode does currently
21) L2TP is defined to run over ATM, frame relay and = X.25 non-IP transports
22) IPSec encryption & integrity protection and = IPCOMP can be hardware accelerated


PPP Benefits ---------- all RFC standard methods, I = believe
1) IP/DNS/WINs assignment through IPCP
2) User authentication
  a.) userid/password
  b.) EAP and EAP/TLS - for certificate, = smartcard, SecurID, token card, biometric
3) AAA integration - with existing AAA servers, = RADIUS TACACS
4) multi-protocol support
5) Link layer negotiation for MRU (this may help in = the fragmentation arena)
6) Keepalives for both PPP
7) Multilink PPP for bundling bandwidth
8) Routable interface
9) PPP compression
10) supports idea of demand dial, so you can have = demand dial filters that kick off the PPP dial activity, and different = filters which apply above the interface

11) supports idea of persistent and autostart = connections, so links can come up automatically and be maintained

Wm

------_=_NextPart_001_01BFC125.D71C2F44-- From owner-ipsec@lists.tislabs.com Thu May 18 18:48:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA15787; Thu, 18 May 2000 18:48:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10353 Thu, 18 May 2000 20:53:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 18 May 2000 20:45:33 -0400 To: Skip Booth From: Stephen Kent Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Skip, Thanks for the clarification. Two observations: - The fact that clients are happy with a current level of security is not a criteria for what we should be doing. These same clients are regularly the victims of a variety of attacks and complain about them, but often fail to see the connection between the "best practices" they employ and the residual vulnerabilities that are exploited. In the early 90s folks insisted that what was needed to prevent unauthorized access was better password management, e.g., longer passwords and more frequent changes. I pointed out that passive wiretapping was a viable attack, but the response was "but attackers don't do that, they just guess bad passwords" and and thus the use of encryption is overkill. Then, when snifffers became widely available, there was a push to adopt one-time passwords. I pointed out the ability to engage in active wiretaps, including session hijacking, but the refrain was "but attacker aren't doing that, they're just sniffing" and thus the proposed use of encryption was still overkill. Now we have encrypted sessions via SSL and SSH, and people are back to using guessable passwords over these paths. When I suggest use of client certs to counter such attacks and more subtle DoS attacks, the response is, well, you cam guess. The pattern is all too familiar. - The set of filters you describe (without going into application layer proxies) sounds appropriate and more powerful than the stateless ones required by IPsec. So, IF there were an IETF standard that defined this set of filters and mandated support for them in PPP implementations, and IF the L2TP RFCs mandated integration of these filters with IKE SA negotiations and mandated local binding of SA info to inbound traffic to control these checks, THEN the result would seem to be an equivalent (or better) alternative to what IPsec provides in tunnel mode, WHEN the L2TP modules and the IPsec modules are contained in the same device. But, that's several IF's away from what we have now, and I think that justifies the criticisms I have leveled at claims that L2TP over IPsec provides equivalent security to native IPsec. Steve From owner-ipsec@lists.tislabs.com Thu May 18 18:50:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA15837; Thu, 18 May 2000 18:50:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA10359 Thu, 18 May 2000 20:53:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3924522d0.6386@databus.databus.com> References: <3924522d0.6386@databus.databus.com> Date: Thu, 18 May 2000 20:54:02 -0400 To: Barney Wolff From: Stephen Kent Subject: RE: Windows 2000 and Cicsco (sic) router interoperability Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Barney, >So, you have communicated to the PPPEXT WG that PPP is worthless >without detailed specification of the filtering behavior of a PPP >device? I truly do not understand why L2TP is the single target >of your scorn. PPP existed before IPsec and is used independent of IPsec. Only when L2TP made use of IPsec, in a fashion that is not consistent with the model developed by the IPsec WG, did this become an issue. > >It is my strong impression, from years of reading RFCs and drafts, >that the primary concern is bits on the wire, with internal operation >specified only when it is required to ensure interoperability. That impression is wrong, but it is a common one. A protocol is NOT just the bits on the wire, it is also the processing (e.g., state machine) at each end of the wire. Such "internal operation" is often necessary to ensure interoperability and to provide a well-defined semantics so that when a vendor says it implements the foo protocol, customers know what that means. >Yes, a PPP/L2TP device should not forget what it knows about where >a packet came from when deciding what filter rules to apply, just >as an IPsec gateway should not echo decrypted packets out to random >addresses, and guns should not be fired at one's feet. Duh. The difference is that the IPsec spec mandates what is to be done re access control, and thus provides a well-defined security semantics. The L2TP specs do not do this, but nonetheless claim equivalence. That's the difference. Steve From owner-ipsec@lists.tislabs.com Fri May 19 09:04:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13408; Fri, 19 May 2000 09:04:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12997 Fri, 19 May 2000 10:06:34 -0400 (EDT) From: tcosenza@us.ibm.com X-Lotus-FromDomain: IBMUS To: ipsec@lists.tislabs.com Message-ID: <852568E4.004E3527.00@d54mta07.raleigh.ibm.com> Date: Fri, 19 May 2000 10:14:11 -0400 Subject: RE: Windows 2000 and Cicsco router interoperability Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I apologise for sending this to the list but I need to find how I can contact Microsoft for some technical help with the Windows 2000 IPSec and how to request and install Certificates from Third Party CA? I know from the last couple of days that there are some Microsoft Techs that read the forum. Thanks Thomas Mr. Thomas Cosenza Software Eng. IBM T/L 441-8782 Outside Line 919-543-8782 "Everyone Fights, No one Quits! If you Quit I will shoot you myself!" Michael Irons in Starship Troopers From owner-ipsec@lists.tislabs.com Fri May 19 09:14:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13594; Fri, 19 May 2000 09:14:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13101 Fri, 19 May 2000 10:50:37 -0400 (EDT) Message-ID: <53D69AD06EFAD311842300A0C99B4F0811EA06@ticsmtp2.innovation.siemens.ca> From: Claudio Lordello To: Skip Booth Cc: ipsec@lists.tislabs.com, Stephen Kent Subject: RE: PPP over IPSec (Re: Windows 2000 and Cicsco router interopera bility) Date: Fri, 19 May 2000 10:04:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Comment below. > -----Original Message----- > From: Skip Booth [SMTP:ebooth@cisco.com] > Sent: Thursday, May 18, 2000 3:59 PM > To: Stephen Kent > Cc: ipsec@lists.tislabs.com > Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router > interoperability) > > > I'm confused by this explanation. IPsec used with L2TP operates in > > transport mode, and it is the inner IP header (carried above L2TP) > > that determines the ultimate destination for the received packet. > > IPsec at the receiver does not see that header, because it is > > operating in transport mode. So, what IPsec filtering at which end do > > you assert is providing the check you cite above? > > My point here was that PPP will only see traffic which was sent through > the L2TP > tunnel and thus protected by IPsec. You are indeed correct that the inner > IP > address obtained through IPCP is not looked at by IPsec. However once the > L2TP/PPP header has been removed, any inbound access lists tied to the PPP > interface may be applied to the IP packet. This effectively provides the > same > level of security our customers have today with their leased lines and > dial-up > connections, which they seem to be pretty happy with. > Just a comment on scalability here. I see access control is happening twice in this model. One being the IPSec SA access control (i.e., only traffic between the client's public IP address and the SGW/LNS IP address, for protocol 1701 is allowed) and then the real access control (the inner IP packet access control, associated with the PPP interface). While this may be a non-issue for software-based filtering on the client side, for a high-end SGW/LNS implementing thousands of access interfaces and making use of hardware-based packet filtering devices, this potentially implies in either double filter resources or half number of interfaces. Granted, because the IPSec SA filter is so simple in this case, it could potentially be done in the SW side of the switching path. However, there would be some issues with that as well. Claudio. From owner-ipsec@lists.tislabs.com Fri May 19 10:56:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16034; Fri, 19 May 2000 10:56:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13401 Fri, 19 May 2000 12:44:38 -0400 (EDT) Subject: RE: Windows 2000 and Cicsco router interoperability MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC1B1.BB9ECA42" Date: Fri, 19 May 2000 09:46:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4368.4 content-class: urn:content-classes:message Message-ID: <19398D273324D3118A2B0008C7E9A5690AEC3352@SIT.platinum.corp.microsoft.com> Thread-Topic: Windows 2000 and Cicsco router interoperability Thread-Index: Ab/BsINsNArHpfdbTfm/Hl9TWctAtwAAYJlA From: "Rob Trace" To: , X-OriginalArrivalTime: 19 May 2000 16:52:29.0788 (UTC) FILETIME=[9E8A81C0:01BFC1B2] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFC1B1.BB9ECA42 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thomas, You might want to check out http://www.microsoft.com/windows2000/library/planning/walkthroughs/defau lt.asp. There are guides there on how to install certificates and to configure IPSEC in Windows 2000 under the security services section. Thanks!! Rob Trace -----Original Message----- From: tcosenza@us.ibm.com [mailto:tcosenza@us.ibm.com] Sent: Friday, May 19, 2000 7:14 AM To: ipsec@lists.tislabs.com Subject: RE: Windows 2000 and Cicsco router interoperability I apologise for sending this to the list but I need to find how I can contact Microsoft for some technical help with the Windows 2000 IPSec and how to request and install Certificates from Third Party CA? I know from the last couple of days that there are some Microsoft Techs that read the forum. Thanks Thomas Mr. Thomas Cosenza Software Eng. IBM T/L 441-8782 Outside Line 919-543-8782 "Everyone Fights, No one Quits! If you Quit I will shoot you myself!" Michael Irons in Starship Troopers ------_=_NextPart_001_01BFC1B1.BB9ECA42 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Windows 2000 and Cicsco router interoperability

Hi Thomas,

You might want to check out http://www.microsoft.com/windows2000/library/planning/walk= throughs/default.asp.  There are guides there on how to install = certificates and to configure IPSEC in Windows 2000 under the security = services section.

Thanks!!

Rob Trace

-----Original Message-----
From: tcosenza@us.ibm.com [mailto:tcosenza@us.ibm.com]
Sent: Friday, May 19, 2000 7:14 AM
To: ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router = interoperability





I apologise for sending this to the list but I need to = find how  I can
contact Microsoft for some technical help with the = Windows 2000 IPSec and
how to request and install Certificates from Third = Party CA?  I know from
the last couple of days that there are some Microsoft = Techs that read the
forum.

Thanks
Thomas


Mr. Thomas Cosenza
Software Eng. IBM
T/L 441-8782
Outside Line 919-543-8782
"Everyone Fights, No one Quits!  If you = Quit I will shoot you myself!"
Michael Irons in Starship Troopers



------_=_NextPart_001_01BFC1B1.BB9ECA42-- From owner-ipsec@lists.tislabs.com Mon May 22 05:29:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA19414; Mon, 22 May 2000 05:29:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA22113 Mon, 22 May 2000 05:41:07 -0400 (EDT) Reply-To: From: "Vinod Porwal" To: Subject: How to communicate PKCS#10 requests to CA Date: Mon, 22 May 2000 15:25:43 +0530 Message-ID: <000001bfc3d3$e5c5bb40$4c01a8c0@vinod> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, How does an end-entity enroll to a CA ? What protocol is used to communicate the PKCS#10 certificate request to the CA ? I have read LDAPv2, in which I can ask for a particular certificate or a CRL from a CA. But it does not talk on how a end-entity will communicate a certificate generation request to the CA. Am I missing something ? Regards, Vinod From owner-ipsec@lists.tislabs.com Mon May 22 09:21:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25299; Mon, 22 May 2000 09:21:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23988 Mon, 22 May 2000 10:33:44 -0400 (EDT) Message-ID: <01E1D01C12D7D211AFC70090273D20B102A1D0A4@sothmxs06.entrust.com> From: Greg Carter To: "'vinod.porwal@ishoni.com'" , ipsec@lists.tislabs.com Subject: RE: How to communicate PKCS#10 requests to CA Date: Mon, 22 May 2000 10:41:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, see http://www.ietf.org/html.charters/pkix-charter.html You are interested in RFC 2510, and perhaps draft-ietf-pkix-cmc-05.txt and rfc 2511. Greg Carter Entrust Technologies - http://www.entrust.com Project EatPorsche 1968 Twin Turbo Mustang http://eatporsche.stangnet.com/ http://www.ford-trucks.com/articles/buildup/dana60.html -----Original Message----- From: Vinod Porwal [mailto:vinod.porwal@ishoni.com] Sent: Monday, May 22, 2000 5:56 AM To: ipsec@lists.tislabs.com Subject: How to communicate PKCS#10 requests to CA Hi, How does an end-entity enroll to a CA ? What protocol is used to communicate the PKCS#10 certificate request to the CA ? I have read LDAPv2, in which I can ask for a particular certificate or a CRL from a CA. But it does not talk on how a end-entity will communicate a certificate generation request to the CA. Am I missing something ? From owner-ipsec@lists.tislabs.com Mon May 22 11:58:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28798; Mon, 22 May 2000 11:58:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25013 Mon, 22 May 2000 13:52:21 -0400 (EDT) Reply-To: From: "Glen Zorn" To: "Stephen Kent" , "W. Mark Townsley" Cc: Subject: RE: Windows 2000 and Cicsco router interoperability Date: Mon, 22 May 2000 10:43:41 -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-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent [mailto://kent@bbn.com] writes: > >Mark, > > > > >Ah, but the binding is not lost. As I have said to you and on this list > >before, there is a 1:1 correlation between the SA, the l2tp session, the > >"user-authorized" PPP session, and thus the access control and policy > >for that user. This is key to the way l2tp+ipsec is intended to operate. > >If you wish, we could even include a section in the l2tp-security draft > >that spells this out in a more direct manner. The omission of this > >specific text is only due to the fact that it so plainly obvious to > >those who have lived and worked in the traditional dialup space for > >years. Perhaps it is this kind of input we need, however, to ensure that > >we cover all points of reference. > > And, I have noted before, we have only the assurance of vendors on > this important security issue, because no RFCcs specify how this is > done. Personally, I'm more comfortable with a standards-specified > approach to such security critical issues, rather than the assurances > I have received from the L2TP community that "well, everybody does > the right thing in their products and we all know it ..." Such assurances are unnecessary. In the final analysis, if security is important to customers, they will buy secure products and configure them correctly. If security isn't important to customers, no number of 'standards-specified approaches' will have any effect. > > Steve > > > From owner-ipsec@lists.tislabs.com Mon May 22 16:26:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03693; Mon, 22 May 2000 16:26:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25900 Mon, 22 May 2000 16:32:19 -0400 (EDT) Date: Mon, 22 May 2000 16:39:24 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: Windows 2000 and Cicsco router interoperability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 22 May 2000, Glen Zorn wrote: > Such assurances are unnecessary. In the final analysis, if security is > important to customers, they will buy secure products and configure them > correctly. If security isn't important to customers, no number of > 'standards-specified approaches' will have any effect. Real life is not so Boolean in nature. Granted, if security isn't important to the customer, their security is likely to be weak. But careful design by specifiers and suppliers can have a big effect on *how* weak it is, both by avoiding gratuitous holes and by influencing customer behavior in the right direction. Such measures can considerably improve the odds that a cracker will pick on somebody else. (Flu vaccination will not guarantee that you don't get the flu, but it considerably improves the odds of getting only a mild case.) On the flip side, as witness various recent DoS attacks, poor security on one site can be harmful to others as well. So just because a customer cares about security and has done things right at his site, that doesn't mean his security can't be improved further by good hygiene elsewhere. (The reason you are unlikely to catch smallpox today has little to do with your being vaccinated 20-30 years ago -- it's unlikely that you have any major lingering immunity after so long -- and a lot to do with everybody *else* having been vaccinated then too.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue May 23 10:40:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19682; Tue, 23 May 2000 10:40:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29712 Tue, 23 May 2000 12:06:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 23 May 2000 12:12:13 -0400 To: From: Stephen Kent Subject: RE: Windows 2000 and Cicsco router interoperability Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Glen, >Stephen Kent [mailto://kent@bbn.com] writes: > > > >Mark, > > > > > > > > >Ah, but the binding is not lost. As I have said to you and on this list > > >before, there is a 1:1 correlation between the SA, the l2tp session, the > > >"user-authorized" PPP session, and thus the access control and policy > > >for that user. This is key to the way l2tp+ipsec is intended to operate. > > >If you wish, we could even include a section in the l2tp-security draft > > >that spells this out in a more direct manner. The omission of this > > >specific text is only due to the fact that it so plainly obvious to > > >those who have lived and worked in the traditional dialup space for > > >years. Perhaps it is this kind of input we need, however, to ensure that > > >we cover all points of reference. > > > > And, I have noted before, we have only the assurance of vendors on > > this important security issue, because no RFCcs specify how this is > > done. Personally, I'm more comfortable with a standards-specified > > approach to such security critical issues, rather than the assurances > > I have received from the L2TP community that "well, everybody does > > the right thing in their products and we all know it ..." > >Such assurances are unnecessary. In the final analysis, if security is >important to customers, they will buy secure products and configure them >correctly. If security isn't important to customers, no number of >'standards-specified approaches' will have any effect. We owe it to customers to create standards which, if met by vendors, provide better security. I realize that this may not be the mind set of some vendors, but I think it the IETF's approach to security standards. Steve From owner-ipsec@lists.tislabs.com Tue May 23 11:36:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21187; Tue, 23 May 2000 11:36:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00167 Tue, 23 May 2000 13:23:49 -0400 (EDT) Message-ID: From: "Gallagher, Mick" To: "'aboba@internaut.com'" , "'Stephane Beaulieu'" , "'Waters, Stephen'" Cc: "'ietf-ipsra@vpnc.org'" , "'ipsec@lists.tislabs.com'" Subject: RE: NAT and IPSEC issues:- Question Date: Tue, 23 May 2000 18:31:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Also forwarded to IPsec list] Thanks for your replies. My original question (IPsec over L2TP thru NAT) was aimed at squeezing IPsec through a NAT; I was interested to see whether L2TP was a reasonable way of doing this. If I may forget L2TP altogether, please consider the following scenario: - IRAC using tunnel mode ESP to SGW (no AH protection of 'outer' IP addresses) - IRAC 'virtual' IP address assigned by DHCP via SGW (and so no UDP checksum problems) - No Pre-Shared key authentication in IKE MM (and so no IP addresses used as identifiers) In this scenario, so far as the IPsec user plane is concerned, the main problem is how to reliably route incoming IPsec traffic from the SGWs to the stub-domain private IP addresses of the IRACs. (I appreciate that this may be a crass simplification. Please let me know if it is!) Couldn't the SPIs be used for the public->private address mapping? Of course, the problem here is that the NAT box doesn't assign SPIs, and so a collision situation may exist if two IRACs choose the same SPI for incoming IPsec sessions. (And just for clarification, I'm thinking IPsec-customised-NAT, not traditional NAT). If the IRAC could be persuaded to request an available SPI from the 'NAT' box, wouldn't this resolve the problem? What other problems remain to be tackled in this IRAC tunnel mode ESP scenario? There's got to be a way... Mick (now on vacation for a week - my responses to any replies won't be speedy!) > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: 16 May 2000 10:13 > To: 'Stephane Beaulieu'; Gallagher, Mick; ietf-ipsra@vpnc.org > Subject: RE: NAT and IPSEC issues:- Question > > > > Looking at the problems mentioned, would it be fair for me > to assume that > > running IKE/IPsec over L2TP is a feasible solution? > > There are several issues with making L2TP/IPSEC NAT friendly. One > is UDP checksums. These need to be turned off on the sender and/or > ignored on the receiver, or the incoming L2TP packets will be > discarded. > > Another issue is IKE. The source port needs to be floated in order > to permit the NAT to properly de-multiplex a re-key. It will also > be necessary not use IP addresses as identifiers > in IKE MM. Similarly, there are issues in IKE QM (see the > IPSEC/L2TP security draft for a description of the filters). > > Finally, there is the issue of floating the server L2TP port. > This is necessary in case there is more than one L2TP client > behind a given NAT. Otherwise, there will be two IKE MMs up > with the same filters and addresses and so the L2TP server > could send the packets down the wrong IKE QM SA. > > The next revision of the L2TP/IPSEC security draft will discuss > these issues in more detail. > From owner-ipsec@lists.tislabs.com Tue May 23 14:19:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25593; Tue, 23 May 2000 14:19:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01285 Tue, 23 May 2000 16:17:17 -0400 (EDT) Message-Id: <4.3.1.2.20000523161304.00e83100@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 23 May 2000 16:24:51 -0400 To: , From: Robert Moskowitz Subject: Re: How to communicate PKCS#10 requests to CA In-Reply-To: <000001bfc3d3$e5c5bb40$4c01a8c0@vinod> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:25 PM 5/22/2000 +0530, Vinod Porwal wrote: >How does an end-entity enroll to a CA ? What protocol is used to >communicate the PKCS#10 certificate request to the CA ? You have 4 options: The web method, which is pretty inconsistant. SCEP -- draft-nourse-scep-02.txt This enrolls, recommends out-of-band revocation, and does not support certificate overlap for rekeying or reissueing. It is supported in some CA products. RFC 2510 - 2511 (CMP) Full certificate life-cycle management protocol. It uses CMRF instead of PKCS 10. It is supported in some CA products. I am running workshops to move from compliance to interoperablity. RFC 2797 (CMC) Similar to CMP, in that it is a certificate management protocol, but it uses PKCS 10 and 7 for the most part rather than CRMF (RFC 2511). The only important certificate management transaction that seems to be missing from CMC is cross-certification. There are no know implementations of CMC (at least no one has said so in any of the places I frequent) Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Wed May 24 01:04:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA07795; Wed, 24 May 2000 01:04:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA03052 Wed, 24 May 2000 02:32:24 -0400 (EDT) content-class: urn:content-classes:message Subject: L2TP-IPSec feature list MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC546.CE5475CC" Date: Tue, 23 May 2000 23:10:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4368.4 Message-ID: <6A05D00595BE644E9F435BE5947423F2A21E80@fifi.platinum.corp.microsoft.com> Thread-Topic: L2TP-IPSec feature list Thread-Index: Ab/FRvx96ZBYcDQaTaqBwfOrfr7I9w== From: "William Dixon" To: X-OriginalArrivalTime: 24 May 2000 06:13:03.0451 (UTC) FILETIME=[1E7CD2B0:01BFC547] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFC546.CE5475CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is an expansion of the features Skip noted earlier in a deep thread for L2TP/IPSec from a protocol design view, not what any particular one vendor implements. No particular order. Not a comparison with IPSec tunnel mode except for a couple of points.=20 L2TP benefits --------- 1) L2TP supports 4 VPN scenarios a.) legacy client PPP dial to NAS - NAS PPP user auth, NAS forwards PPP through L2TP tunnel to L2TP gateway=20 b.) L2TP/IPSec capable client PPP dial to NAS - voluntary L2TP/IPSec to L2TP gateway c.) L2TP/IPSec capable client directly on IP network - user voluntary L2TP/IPSec tunnel to L2TP gateway d.) L2TP/IPSec gateway to gateway (2) PPP options can be varied depending on capabilities of IPSec SA, since the SA is established first - e.g. encryption & IPCOMP compression on SA means no PPP compression needed (1) idea of a user for tunnel helps scalable management of remote tunnel end-points via radius. 2) can have multiple L2TP tunnel sessions inside 1 IPSec SA pair for efficiency 3) can have single L2TP tunnel session (choose UDP source port) mapping to single IPSec SA pair - preserves binding of SA to tunnel to user - to the extent you can control what user traffic goes into tunnel to start with. 4) keep alives for L2TP 5) don't have to use L2TP sequence numbers (can't with L2TP header compression) because IPSec seq numbers can detect packet loss & estimate path latency 6) new spec for L2TP MUX of PPP packets inside a single L2TP UDP datagram - popular to reduce overhead for tunneling small IP packets, like VoIP 7) new L2TP header compression draft gets [UDP][L2TP] header overhead down to 1 or 2 bytes for majority of the tunnel. This is 1-2 bytes per packet more than pure IPSec tunnel mode - using PPPMUX mode of L2TP means several PPP frames per tunnel IP packet 8) extensibility of L2TP with Attrib Value (AV) pairs, avoid extending, complicating IKE key management protocol a.) AV delivered dynamic redirection of gateway dest IP for global load balancing b.) AV delivered QOS values 9) can use IPSec tunnel and transport filters which apply to assigned tunnel IP address above L2TP/PPP interface a.) enables tunnel within a tunnel with full interface support b.) enables static filtering & routes applied via Radius policy to tunnel interfaces 10) basic L2TP is most interoperable - even before IKE & IPSec, RFC solution designed specifically for remote access, dial remote access in particular - which estimates show to be 60-70% of the worldwide Internet connection method (PPP in general by all platforms, not L2TP/IPSec) in 2003. 11) more vendors testing L2TP/IPSec interop (14) at last bakeoff than testing XAUTH/IKECFG (7) 12) use of MM/QM in transport mode makes IPSec policy consistently transport - just an ease of maintenance thing. So IKE negotiation for L2TP (UDP port 1701) protections are just another port QM, as are QMs for other things like connections to application proxies that run on the same box. Your transport packet filters for permit & block & secure are easy to see and evaluate. You don't have to worry about a tunnel policy for access from any Client IP to an internal subnet in conflict with transport filters to block a specific type of traffic regardless of addresses.=20 13) Some vendors implement IPSec tunnels as routable interfaces, some implement as strictly filter driven - don't have to worry about this for L2TP - they are all interfaces. a.) can run routing protocols across tunnel interoperable with other vendors b.) can carry standard, routable IP across tunnel, e.g. multicast, broadcast, unicast IP 14) L2TP can be used in clear text mode without IPSec and get all of the tunneling benefits when security is not a problem. 15) Without IPSec, L2TP over IP can go through NATs because it uses UDP 1701. 16) L2TP/IPSec=20 17) L2TP/IPSec VPN clients are becoming widely available by their inclusion in Windows 2000 and future releases. Their availability for VPN has been announced since August 1998 when the L2TP/IPSec client was included in Beta2 of Windows 2000. 18) Most remote access implementations support both machine auth first with either preshared key, or much stronger certificate auth, then user auth 19) L2TP/IPSec fully replaces and is a superset of PPTP functionality and is much more secure 20) L2TP/IPSec today offers more features as RFC standard than IPSec tunnel mode does currently 21) L2TP is defined to run over ATM, frame relay and X.25 non-IP transports 22) IPSec encryption & integrity protection and IPCOMP can be hardware accelerated PPP Benefits ---------- all RFC standard methods, I believe 1) IP/DNS/WINs assignment through IPCP 2) User authentication a.) userid/password b.) EAP and EAP/TLS - for certificate, smartcard, SecurID, token card, biometric 3) AAA integration - with existing AAA servers, RADIUS TACACS 4) multi-protocol support 5) Link layer negotiation for MRU (this may help in the fragmentation arena) 6) Keepalives for both PPP 7) Multilink PPP for bundling bandwidth 8) Routable interface 9) PPP compression 10) supports idea of demand dial, so you can have demand dial filters that kick off the PPP dial activity, and different filters which apply above the interface=20 11) supports idea of persistent and autostart connections, so links can come up automatically and be maintained Wm William Dixon Program Manager - Internet Protocol Security Windows Operating Systems Division Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: WDixon@microsoft.com (preferred), Work: 425-703-8729 Newly updated Windows 2000 IPSec end-to-end walkthrough & mini-whitepaper (which covers IKE's use of certificates): http://www.microsoft.com/windows2000/library/technologies/security/defau lt.asp=20 ------_=_NextPart_001_01BFC546.CE5475CC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable L2TP-IPSec feature list

Here is an expansion of the = features Skip noted earlier in a deep thread for L2TP/IPSec from a = protocol design view, not what any particular one vendor = implements.  No particular order.  Not a comparison with IPSec = tunnel mode except for a couple of points.

L2TP benefits ---------
1) L2TP supports 4 VPN = scenarios
  a.) legacy client PPP = dial to NAS - NAS PPP user auth, NAS forwards PPP through L2TP tunnel to = L2TP gateway
  b.) L2TP/IPSec capable = client PPP dial to NAS - voluntary L2TP/IPSec to L2TP gateway
  c.) L2TP/IPSec capable = client directly on IP network - user voluntary L2TP/IPSec tunnel to L2TP = gateway
  d.) L2TP/IPSec gateway to = gateway
     (2) PPP = options can be varied depending on capabilities of IPSec SA, since the = SA is established first - e.g. encryption & IPCOMP compression on SA = means no PPP compression needed

     (1) idea = of a user for tunnel helps scalable management of remote tunnel = end-points via radius.
2) can have multiple L2TP tunnel = sessions inside 1 IPSec SA pair for efficiency
3) can have single L2TP tunnel = session (choose UDP source port) mapping to single IPSec SA pair - = preserves binding of SA to tunnel to user - to the extent you can = control what user traffic goes into tunnel to start with.

4) keep alives for L2TP
5) don't have to use L2TP = sequence numbers (can't with L2TP header compression) because IPSec seq = numbers can detect packet loss & estimate path latency

6) new spec for L2TP MUX of PPP = packets inside a single L2TP UDP datagram - popular to reduce overhead = for tunneling small IP packets, like VoIP

7) new L2TP header compression = draft gets [UDP][L2TP] header overhead down to 1 or 2 bytes for majority = of the tunnel.  This is 1-2 bytes per packet more than pure IPSec = tunnel mode - using PPPMUX mode of L2TP means several PPP frames per = tunnel IP packet

8) extensibility of L2TP with = Attrib Value (AV) pairs, avoid extending, complicating IKE key = management protocol
  a.) AV delivered dynamic = redirection of gateway dest IP for global load balancing
  b.) AV delivered QOS = values
9) can use IPSec tunnel and = transport filters which apply to assigned tunnel IP address above = L2TP/PPP interface
  a.) enables tunnel within = a tunnel with full interface support
  b.) enables static = filtering & routes applied via Radius policy to tunnel = interfaces
10) basic L2TP is most = interoperable - even before IKE & IPSec, RFC solution designed = specifically for remote access, dial remote access in particular - which = estimates show to be 60-70% of the worldwide Internet connection method = (PPP in general by all platforms, not L2TP/IPSec) in 2003.

11) more vendors testing = L2TP/IPSec interop (14) at last bakeoff than testing XAUTH/IKECFG = (7)
12) use of MM/QM in transport = mode makes IPSec policy consistently transport - just an ease of = maintenance thing.  So IKE negotiation for L2TP (UDP port 1701) = protections are just another port QM, as are QMs for other things like = connections to application proxies that run on the same box.  Your = transport packet filters for permit & block & secure are easy to = see and evaluate.  You don't have to worry about a tunnel policy = for access from any Client IP to an internal subnet in conflict with = transport filters to block a specific type of traffic regardless of = addresses.

13) Some vendors implement IPSec = tunnels as routable interfaces, some implement as strictly filter driven = - don't have to worry about this for L2TP - they are all = interfaces.

  a.) can run routing = protocols across tunnel interoperable with other vendors
  b.) can carry standard, = routable IP across tunnel, e.g. multicast, broadcast, unicast IP
14) L2TP can be used in clear = text mode without IPSec and get all of the tunneling benefits when = security is not a problem.

15) Without IPSec, L2TP over IP = can go through NATs because it uses UDP 1701.
16) L2TP/IPSec
17) L2TP/IPSec VPN clients are = becoming widely available by their inclusion in Windows 2000 and future = releases.  Their availability for VPN has been announced since = August 1998 when the L2TP/IPSec client was included in Beta2 of Windows = 2000.

18) Most remote access = implementations support both machine auth first with either preshared = key, or much stronger certificate auth, then user auth

19) L2TP/IPSec fully replaces and = is a superset of PPTP functionality and is much more secure
20) L2TP/IPSec today offers more = features as RFC standard than IPSec tunnel mode does currently
21) L2TP is defined to run over = ATM, frame relay and X.25 non-IP transports
22) IPSec encryption & = integrity protection and IPCOMP can be hardware accelerated


PPP Benefits ---------- all RFC = standard methods, I believe
1) IP/DNS/WINs assignment = through IPCP
2) User authentication
  a.) = userid/password
  b.) EAP and EAP/TLS - for = certificate, smartcard, SecurID, token card, biometric
3) AAA integration - with = existing AAA servers, RADIUS TACACS
4) multi-protocol support
5) Link layer negotiation for = MRU (this may help in the fragmentation arena)
6) Keepalives for both = PPP
7) Multilink PPP for bundling = bandwidth
8) Routable interface
9) PPP compression
10) supports idea of demand = dial, so you can have demand dial filters that kick off the PPP dial = activity, and different filters which apply above the interface =

11) supports idea of persistent = and autostart connections, so links can come up automatically and be = maintained

Wm


William Dixon
Program Manager - Internet Protocol = Security
Windows Operating Systems = Division
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email: WDixon@microsoft.com = (preferred), Work: 425-703-8729

Newly updated Windows 2000 IPSec = end-to-end walkthrough & mini-whitepaper (which covers IKE's use of = certificates): http://www.microsoft.com/windows2000/library/technologies/= security/default.asp


------_=_NextPart_001_01BFC546.CE5475CC-- From owner-ipsec@lists.tislabs.com Wed May 24 02:04:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12414; Wed, 24 May 2000 02:04:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA03351 Wed, 24 May 2000 03:50:58 -0400 (EDT) Message-Id: <392B97DE.50B0FEEC@radguard.com> Date: Wed, 24 May 2000 10:50:38 +0200 From: Yael Dayan Organization: Radguard X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,hebrew Mime-Version: 1.0 To: ipsra Cc: ipsec@lists.tislabs.com Subject: L2TP+IPsec and IKE authentication Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems as though no one is paying attention to an issue that dominated these mailing lists in the not so far past, concerning the validity of the authentication procedure imposed by XAUTH. L2TP+IPsec requires IKE. IKE is an authenticated key exchange and yet people clearly state that the user authentication will take place in the PPP authentication. This means one of these is true: 1. Users have certificates. In this case why do we need the PPP authentication? 2. Each user has a pre-shared secret with the SGW. Again, why do we need the PPP authentication? 3. The user does not authenticate to the SGW and Phase I, Phase II and IPsec traffic happen prior to authentication of the user. To support this, IKE requires changes and the architecture in "security architecture" becomes somewhat questionable. Yael From owner-ipsec@lists.tislabs.com Wed May 24 03:30:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA19629; Wed, 24 May 2000 03:30:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA03572 Wed, 24 May 2000 05:18:00 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D28178@new-exc1.ctron.com> From: "Waters, Stephen" To: Yael Dayan Cc: ipsec@lists.tislabs.com Subject: RE: L2TP+IPsec and IKE authentication Date: Wed, 24 May 2000 10:24:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="x-user-defined" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My take on this is that secondary authentication is needed, be it at the PPP level, XAUTH or other (e.g. CRACK proposal) to allow for a 'challenge'. If we relied solely on a device-loaded certificate or pre-shared secret to authenticate the user, that is not a 'secure' situation in the event of the device being 'borrowed'. In time, when certificate smartcards and native laptop smartcard readers are readily available (smartcards that request a user challenge - pin/signature/biometrics), then we may be able to dispense with 'device+user' authentication. On the up-side, having a root trust in a device, as well as a user of that device does provide extra security. On the down-side, it is restrictive - e.g. connecting from shared/public equipment such as from a cyber cafe. Steve. -----Original Message----- From: Yael Dayan [ mailto:yael@radguard.com ] Sent: Wednesday, May 24, 2000 9:51 AM To: ipsra Cc: ipsec@lists.tislabs.com Subject: L2TP+IPsec and IKE authentication It seems as though no one is paying attention to an issue that dominated these mailing lists in the not so far past, concerning the validity of the authentication procedure imposed by XAUTH. L2TP+IPsec requires IKE. IKE is an authenticated key exchange and yet people clearly state that the user authentication will take place in the PPP authentication. This means one of these is true: 1. Users have certificates. In this case why do we need the PPP authentication? 2. Each user has a pre-shared secret with the SGW. Again, why do we need the PPP authentication? 3. The user does not authenticate to the SGW and Phase I, Phase II and IPsec traffic happen prior to authentication of the user. To support this, IKE requires changes and the architecture in "security architecture" becomes somewhat questionable. Yael From owner-ipsec@lists.tislabs.com Wed May 24 04:45:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22020; Wed, 24 May 2000 04:45:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA03722 Wed, 24 May 2000 06:21:50 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D2817A@new-exc1.ctron.com> From: "Waters, Stephen" To: William Dixon Cc: ipsec@lists.tislabs.com Subject: RE: L2TP-IPSec feature list Date: Wed, 24 May 2000 11:28:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't see anything here that has not already been achieved or is achievable without using L2TP. IPSEC or IPIP tunnels+IPSEC implementations can and do support all of there features - with the exception of the L2TP specific things like L2TP header compression). The number of vendors testing L2TP+IPSEC at the last bake-off may be a reflection of the need to support a certain client (point 17) that will no doubt become widely used. I can assure you that L2TP Head-ends are unlikely to model L2TP client connections as 'interfaces'! The divide between interfaces and tunnels is an architectural one specific to each implementation. Many vendors support both models as appropriate - Interfaces for LAN-LAN, 'dynamic-static' routes for clients. L2TP may go through NAT (has a port), but this is at the expense of UDP check-sums. IPSEC is fine for most 'useful' cases (LSNAT/anonymity for head-end). This 'to L2TP, or not to L2TP' debate could run and run. Personally, as an engineer involved in 'head-end' design, IPSEC+L2TP+PPP is a nightmare! 'Third generation' head-end devices are just getting their teeth into ASIC support for IPSEC transform/tunnel processing, and now they have to deal with L2TP+PPP as well! It may be O.K. for a 600/700Mhz PC to keep itself warm that way, but for a scaleable head-end, being able to focus on IPSEC tunnels is a major plus. Steve. -----Original Message----- From: William Dixon [mailto:wdixon@Exchange.Microsoft.com] Sent: Wednesday, May 24, 2000 7:11 AM To: ipsec@lists.tislabs.com Subject: L2TP-IPSec feature list Here is an expansion of the features Skip noted earlier in a deep thread for L2TP/IPSec from a protocol design view, not what any particular one vendor implements. No particular order. Not a comparison with IPSec tunnel mode except for a couple of points. L2TP benefits --------- 1) L2TP supports 4 VPN scenarios a.) legacy client PPP dial to NAS - NAS PPP user auth, NAS forwards PPP through L2TP tunnel to L2TP gateway b.) L2TP/IPSec capable client PPP dial to NAS - voluntary L2TP/IPSec to L2TP gateway c.) L2TP/IPSec capable client directly on IP network - user voluntary L2TP/IPSec tunnel to L2TP gateway d.) L2TP/IPSec gateway to gateway (2) PPP options can be varied depending on capabilities of IPSec SA, since the SA is established first - e.g. encryption & IPCOMP compression on SA means no PPP compression needed (1) idea of a user for tunnel helps scalable management of remote tunnel end-points via radius. 2) can have multiple L2TP tunnel sessions inside 1 IPSec SA pair for efficiency 3) can have single L2TP tunnel session (choose UDP source port) mapping to single IPSec SA pair - preserves binding of SA to tunnel to user - to the extent you can control what user traffic goes into tunnel to start with. 4) keep alives for L2TP 5) don't have to use L2TP sequence numbers (can't with L2TP header compression) because IPSec seq numbers can detect packet loss & estimate path latency 6) new spec for L2TP MUX of PPP packets inside a single L2TP UDP datagram - popular to reduce overhead for tunneling small IP packets, like VoIP 7) new L2TP header compression draft gets [UDP][L2TP] header overhead down to 1 or 2 bytes for majority of the tunnel. This is 1-2 bytes per packet more than pure IPSec tunnel mode - using PPPMUX mode of L2TP means several PPP frames per tunnel IP packet 8) extensibility of L2TP with Attrib Value (AV) pairs, avoid extending, complicating IKE key management protocol a.) AV delivered dynamic redirection of gateway dest IP for global load balancing b.) AV delivered QOS values 9) can use IPSec tunnel and transport filters which apply to assigned tunnel IP address above L2TP/PPP interface a.) enables tunnel within a tunnel with full interface support b.) enables static filtering & routes applied via Radius policy to tunnel interfaces 10) basic L2TP is most interoperable - even before IKE & IPSec, RFC solution designed specifically for remote access, dial remote access in particular - which estimates show to be 60-70% of the worldwide Internet connection method (PPP in general by all platforms, not L2TP/IPSec) in 2003. 11) more vendors testing L2TP/IPSec interop (14) at last bakeoff than testing XAUTH/IKECFG (7) 12) use of MM/QM in transport mode makes IPSec policy consistently transport - just an ease of maintenance thing. So IKE negotiation for L2TP (UDP port 1701) protections are just another port QM, as are QMs for other things like connections to application proxies that run on the same box. Your transport packet filters for permit & block & secure are easy to see and evaluate. You don't have to worry about a tunnel policy for access from any Client IP to an internal subnet in conflict with transport filters to block a specific type of traffic regardless of addresses. 13) Some vendors implement IPSec tunnels as routable interfaces, some implement as strictly filter driven - don't have to worry about this for L2TP - they are all interfaces. a.) can run routing protocols across tunnel interoperable with other vendors b.) can carry standard, routable IP across tunnel, e.g. multicast, broadcast, unicast IP 14) L2TP can be used in clear text mode without IPSec and get all of the tunneling benefits when security is not a problem. 15) Without IPSec, L2TP over IP can go through NATs because it uses UDP 1701. 16) L2TP/IPSec 17) L2TP/IPSec VPN clients are becoming widely available by their inclusion in Windows 2000 and future releases. Their availability for VPN has been announced since August 1998 when the L2TP/IPSec client was included in Beta2 of Windows 2000. 18) Most remote access implementations support both machine auth first with either preshared key, or much stronger certificate auth, then user auth 19) L2TP/IPSec fully replaces and is a superset of PPTP functionality and is much more secure 20) L2TP/IPSec today offers more features as RFC standard than IPSec tunnel mode does currently 21) L2TP is defined to run over ATM, frame relay and X.25 non-IP transports 22) IPSec encryption & integrity protection and IPCOMP can be hardware accelerated PPP Benefits ---------- all RFC standard methods, I believe 1) IP/DNS/WINs assignment through IPCP 2) User authentication a.) userid/password b.) EAP and EAP/TLS - for certificate, smartcard, SecurID, token card, biometric 3) AAA integration - with existing AAA servers, RADIUS TACACS 4) multi-protocol support 5) Link layer negotiation for MRU (this may help in the fragmentation arena) 6) Keepalives for both PPP 7) Multilink PPP for bundling bandwidth 8) Routable interface 9) PPP compression 10) supports idea of demand dial, so you can have demand dial filters that kick off the PPP dial activity, and different filters which apply above the interface 11) supports idea of persistent and autostart connections, so links can come up automatically and be maintained Wm William Dixon Program Manager - Internet Protocol Security Windows Operating Systems Division Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: WDixon@microsoft.com (preferred), Work: 425-703-8729 Newly updated Windows 2000 IPSec end-to-end walkthrough & mini-whitepaper (which covers IKE's use of certificates): http://www.microsoft.com/windows2000/library/technologies/security/default.a sp From owner-ipsec@lists.tislabs.com Wed May 24 07:57:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28727; Wed, 24 May 2000 07:57:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04394 Wed, 24 May 2000 09:26:54 -0400 (EDT) Reply-To: From: "Bernard Aboba" To: "'Gallagher, Mick'" , "'Stephane Beaulieu'" , "'Waters, Stephen'" Cc: , Subject: RE: NAT and IPSEC issues:- Question Date: Wed, 24 May 2000 06:38:36 -0700 Message-ID: <006701bfc585$5d72cc70$428939cc@ntdev.microsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4131.1600 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >If I may forget L2TP altogether, please consider the following scenario: L2TP is only relevant in how it influences the negotiated filters. >In this scenario, so far as the IPsec user plane is concerned, the main >problem is how to reliably route incoming IPsec traffic from the SGWs to the >stub-domain private IP addresses of the IRACs. (I appreciate that this may >be a crass simplification. Please let me know if it is!) I believe that this issue is covered in draft-ietf-ipsec-dhcp-05.txt. The SGW (which acts as a DHCP Relay) needs to track which IP addresses have been assigned to which tunnels, and plumb routes for them. >Couldn't the SPIs be used for the public->private address mapping? On the NAT side, the NAT needs to figure out how to de-multiplex the incoming IPSEC traffic, which all has the same IP Protocol (ESP) and outer source address (the SGW). It uses SPIs for this. The NAT also needs to de-multiplex the incoming IKE traffic (rekeys). In NAT WG we discussed use of IKE cookies for this but concluded that to handle rekeys we needed to float the IKE source port. >Of course, the problem here is that the NAT box doesn't assign SPIs, and so >a collision situation may exist if two IRACs choose the same SPI for >incoming IPsec sessions. Yup. This is why the RSIP/IPSEC specification allows the RSIP server to inspect the chosen SPIs to check for conflicts. >If the IRAC could be persuaded to request an available SPI from the 'NAT' >box, wouldn't this resolve the problem? No, because the SPI is chosen by the responder. But the NAT could check the SPI and inform the client if it was in conflict. That is what RSIP does. >There's got to be a way... This is working in shipping software today, so indeed there must be :) From owner-ipsec@lists.tislabs.com Wed May 24 09:21:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01841; Wed, 24 May 2000 09:21:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04816 Wed, 24 May 2000 11:10:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <29752A74B6C5D211A4920090273CA3DC01D28178@new-exc1.ctron.com> References: <29752A74B6C5D211A4920090273CA3DC01D28178@new-exc1.ctron.com> Date: Wed, 24 May 2000 11:18:08 -0400 To: "Waters, Stephen" From: Stephen Kent Subject: RE: L2TP+IPsec and IKE authentication Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen, >My take on this is that secondary authentication is needed, be it at the PPP >level, XAUTH or other (e.g. CRACK proposal) to allow for a 'challenge'. > >If we relied solely on a device-loaded certificate or pre-shared secret to >authenticate the user, that is not a 'secure' situation in the event of the >device being 'borrowed'. > >In time, when certificate smartcards and native laptop smartcard readers are >readily available (smartcards that request a user challenge - >pin/signature/biometrics), then we may be able to dispense with >'device+user' authentication. As you note here, if one uses a smart card with a PIN or a biometric to activate it, then it is arguably as secure as using a SecurID card. From an interoperability perspective, how the private key is made available for use in IKE the two are indistinguishable, i.e., the means by which the private key (not the certificate, as suggested above) is protected is purely a local matter. So, what is disturbing about this argument is that we're making architectural accommodations for what would normally not be subject to an IETF standard. This is even more surprising because in most (if not all) of the other security standards I can think of, we are amazingly silent about these sorts of assurance issues. Thus I am forced to conclude that the departure from this precedent is driven more by market(ing) forces than by technology or security concerns. Steve From owner-ipsec@lists.tislabs.com Wed May 24 09:23:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01886; Wed, 24 May 2000 09:23:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04854 Wed, 24 May 2000 11:23:15 -0400 (EDT) Message-ID: <53D69AD06EFAD311842300A0C99B4F0811EAC9@ticsmtp2.innovation.siemens.ca> From: Claudio Lordello To: aboba@internaut.com, "'Gallagher, Mick'" , "'Stephane Beaulieu'" , "'Waters, Stephen'" Cc: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: RE: NAT and IPSEC issues:- Question Date: Wed, 24 May 2000 11:26:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >If the IRAC could be persuaded to request an available SPI from the 'NAT' > >box, wouldn't this resolve the problem? > > No, because the SPI is chosen by the responder. But the NAT could check > the SPI and inform the client if it was in conflict. That is what RSIP > does. > I believe that when A negotiates an IPSec SA with B, A chooses the SPI that B will use to send encapsulated packets to A and B chooses the SPI that A will use to send encapsulated packets to B. This is independent of who's the initiator or the responder. So if the IRAC creates a proposal where all SPI values are guaranteed to be unique for the NAT-ed domain (under control of the NAT box as suggested in the original question) then I do not see why that SPI could not later be used by the NAT box to route inbound traffic to the appropriate client. Claudio. From owner-ipsec@lists.tislabs.com Wed May 24 09:56:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02590; Wed, 24 May 2000 09:56:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04931 Wed, 24 May 2000 11:39:14 -0400 (EDT) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: aboba@internaut.com cc: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Message-ID: <862568E9.00569A47.00@mwgate02.mw.3com.com> Date: Wed, 24 May 2000 10:46:14 -0500 Subject: RE: NAT and IPSEC issues:- Question Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, the SPI that the responder uses is chosen by the initiator, which is what allows RSIP to allocate disjoint SPIs to clients. -Mike "Bernard Aboba" on 05/24/2000 08:38:36 AM Please respond to aboba@internaut.com Sent by: "Bernard Aboba" To: "'Gallagher, Mick'" , "'Stephane Beaulieu'" , "'Waters, Stephen'" cc: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com (Mike Borella/MW/US/3Com) Subject: RE: NAT and IPSEC issues:- Question >If I may forget L2TP altogether, please consider the following scenario: L2TP is only relevant in how it influences the negotiated filters. >In this scenario, so far as the IPsec user plane is concerned, the main >problem is how to reliably route incoming IPsec traffic from the SGWs to the >stub-domain private IP addresses of the IRACs. (I appreciate that this may >be a crass simplification. Please let me know if it is!) I believe that this issue is covered in draft-ietf-ipsec-dhcp-05.txt. The SGW (which acts as a DHCP Relay) needs to track which IP addresses have been assigned to which tunnels, and plumb routes for them. >Couldn't the SPIs be used for the public->private address mapping? On the NAT side, the NAT needs to figure out how to de-multiplex the incoming IPSEC traffic, which all has the same IP Protocol (ESP) and outer source address (the SGW). It uses SPIs for this. The NAT also needs to de-multiplex the incoming IKE traffic (rekeys). In NAT WG we discussed use of IKE cookies for this but concluded that to handle rekeys we needed to float the IKE source port. >Of course, the problem here is that the NAT box doesn't assign SPIs, and so >a collision situation may exist if two IRACs choose the same SPI for >incoming IPsec sessions. Yup. This is why the RSIP/IPSEC specification allows the RSIP server to inspect the chosen SPIs to check for conflicts. >If the IRAC could be persuaded to request an available SPI from the 'NAT' >box, wouldn't this resolve the problem? No, because the SPI is chosen by the responder. But the NAT could check the SPI and inform the client if it was in conflict. That is what RSIP does. >There's got to be a way... This is working in shipping software today, so indeed there must be :) From owner-ipsec@lists.tislabs.com Wed May 24 11:14:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05176; Wed, 24 May 2000 11:14:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05462 Wed, 24 May 2000 13:11:23 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A407@baltimore.com> From: Chris Trobridge To: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: FW: NAT and IPSEC issues:- Question Date: Wed, 24 May 2000 18:19:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > -----Original Message----- > From: Mike Borella [mailto:Mike_Borella@mw.3com.com] > Sent: 24 May 2000 16:46 > To: aboba@internaut.com > Cc: ietf-ipsra@vpnc.org; ipsec@lists.tislabs.com > Subject: RE: NAT and IPSEC issues:- Question > > > > > Actually, the SPI that the responder uses is chosen by the initiator, > which is what allows RSIP to allocate disjoint SPIs to clients. > > -Mike But the SPI that the initiator uses to transmit is chosen by the responder. Chris From owner-ipsec@lists.tislabs.com Wed May 24 14:09:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10100; Wed, 24 May 2000 14:09:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06061 Wed, 24 May 2000 15:48:07 -0400 (EDT) Reply-To: From: "Glen Zorn" To: "Henry Spencer" , "IP Security List" Subject: RE: Windows 2000 and Cicsco router interoperability Date: Wed, 24 May 2000 12:38:59 -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-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer [mailto://henry@spsystems.net] writes: > On Mon, 22 May 2000, Glen Zorn wrote: > > Such assurances are unnecessary. In the final analysis, if security is > > important to customers, they will buy secure products and configure them > > correctly. If security isn't important to customers, no number of > > 'standards-specified approaches' will have any effect. > > Real life is not so Boolean in nature. Of course not. Perhaps I should have spent several thousand pages describing the shades of gray between the poles but that approach is less than effective as a rhetorical device. > > Granted, if security isn't important to the customer, their security is > likely to be weak. But careful design by specifiers and suppliers can > have a big effect on *how* weak it is, both by avoiding gratuitous holes > and by influencing customer behavior in the right direction. Such > measures can considerably improve the odds that a cracker will pick on > somebody else. (Flu vaccination will not guarantee that you don't get the > flu, but it considerably improves the odds of getting only a mild case.) To continue your medical analogy (though I'm not sure how appropriate it is), if flu shots were as painful as rabies treatment, how many people would just take their chances w/the flu? My point here is that the entire purpose of xuth/mode config/etc. seems to be to create precisely the functionality already present in PPP (and by extension, L2TP). From owner-ipsec@lists.tislabs.com Wed May 24 15:54:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11308; Wed, 24 May 2000 15:54:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06489 Wed, 24 May 2000 17:40:33 -0400 (EDT) Message-ID: <392C4DF4.D6EEA3AA@redcreek.com> Date: Wed, 24 May 2000 14:47:32 -0700 From: "Scott G. Kelly" 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 To: gwz@cisco.com CC: Henry Spencer , IP Security List Subject: Re: Windows 2000 and Cicsco router interoperability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Glen Zorn wrote: > Henry Spencer wrote: > > > Granted, if security isn't important to the customer, their security is > > likely to be weak. But careful design by specifiers and suppliers can > > have a big effect on *how* weak it is, both by avoiding gratuitous holes > > and by influencing customer behavior in the right direction. Such > > measures can considerably improve the odds that a cracker will pick on > > somebody else. (Flu vaccination will not guarantee that you don't get the > > flu, but it considerably improves the odds of getting only a mild case.) > > To continue your medical analogy (though I'm not sure how appropriate it > is), if flu shots were as painful as rabies treatment, how many people would > just take their chances w/the flu? My point here is that the entire purpose > of xuth/mode config/etc. seems to be to create precisely the functionality > already present in PPP (and by extension, L2TP). > Actually, I think the entire point of the various user auth proposals are to create the minimal necessary and sufficient *subset* of the functionality present in ppp and l2tp in order to enable secure remote access. Scott From owner-ipsec@lists.tislabs.com Wed May 24 15:54:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11314; Wed, 24 May 2000 15:54:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06542 Wed, 24 May 2000 17:50:41 -0400 (EDT) Reply-To: From: "Glen Zorn" To: "Stephen Kent" , "Waters, Stephen" Cc: Subject: RE: L2TP+IPsec and IKE authentication Date: Wed, 24 May 2000 14:41:31 -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-ipsec@lists.tislabs.com Precedence: bulk Comments interspersed below. > Stephen, > > >My take on this is that secondary authentication is needed, be > it at the PPP > >level, XAUTH or other (e.g. CRACK proposal) to allow for a 'challenge'. > > > >If we relied solely on a device-loaded certificate or pre-shared > secret to > >authenticate the user, that is not a 'secure' situation in the > event of the > >device being 'borrowed'. > > > >In time, when certificate smartcards and native laptop smartcard > readers are > >readily available (smartcards that request a user challenge - > >pin/signature/biometrics), then we may be able to dispense with > >'device+user' authentication. > > As you note here, if one uses a smart card with a PIN or a biometric > to activate it, then it is arguably as secure as using a SecurID > card. At least. > From an interoperability perspective, how the private key is > made available for use in IKE the two are indistinguishable, i.e., > the means by which the private key (not the certificate, as suggested > above) is protected is purely a local matter. Yes. > So, what is disturbing > about this argument is that we're making architectural accommodations > for what would normally not be subject to an IETF standard. This is > even more surprising because in most (if not all) of the other > security standards I can think of, we are amazingly silent about > these sorts of assurance issues. Thus I am forced to conclude that > the departure from this precedent is driven more by market(ing) > forces than by technology or security concerns. God forbid we would allow reality to impinge upon the standardization process. > > Steve > > > From owner-ipsec@lists.tislabs.com Wed May 24 15:54:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA11311; Wed, 24 May 2000 15:54:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06482 Wed, 24 May 2000 17:39:53 -0400 (EDT) Reply-To: From: "Glen Zorn" To: "Waters, Stephen" , "Jan Vilhuber" Cc: Subject: RE: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability) Date: Wed, 24 May 2000 14:26:29 -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: <29752A74B6C5D211A4920090273CA3DC01D28110@new-exc1.ctron.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Sorry, but this 'why reinvent' call seems too late - it's been done > and plenty of vendors have implemented it. The call went out a long time ago, but was ignored. > > Keeping faith with installed Remote Access tools is common practice > for IPSEC-only remote access products using a combination of the new > tunnel RADIUS attributes (sometimes), and most of the old ones (except > stuff like 'call-back'). > > I know of at least 6 shipping IPSEC client/server products that do > just this, and I would not be surprised to find the actual number is > much higher. How many of those actually interoperate (outside of bake-offs)? > > So, is the path of least resistance really to implement IPSEC/L2TP/PPP > as well? > > Steve. > > > > > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Wednesday, May 17, 2000 11:57 PM > To: Scott G. Kelly > Cc: W. Mark Townsley; Ari Huttunen; Stephen Kent; CHINNA N.R. PELLACURU; > ipsec@lists.tislabs.com > Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router > interoperability) > > > On Wed, 17 May 2000, Scott G. Kelly wrote: > > The point has been made that some sort of aaa infrastructure has been > > deployed for dial-up users, and that customers should not be asked to > > discard this. Please clarify what components would be discarded if we do > > not use l2tp. For example, I know of several ipsec vendors who implement > > some sort of radius interaction without using either ppp or l2tp, so it > > seems that radius investments are not necessarily in jeopardy here. > > Please address this. > > > That's exactly my point though: There's certainly people that have > implemented this, but what they had to do was essentially > *re-implement* the > radius interaction (if not define it from scratch), whereas PPP has hashed > all this out over the years, and there would not have to be any > re-inventing > and/or re-implementing. > > Example: Config-mode does address-assignment, dns and wins assignment, and > so > forth. PPP already does all this. PPP also does more (look at some fairly > complex radius profile for PPP; I can't find any in my radius directory > off-hand), which you'd have to define and implement in > config-mode (or some > other mechanism). Why bother? it's been done. it's solved. Let's use it. > > Another example: xauth and all the different authentication types. While > radius isn't a stellar example in this case (tacacs+ handles > things like EAP > better, I think; but let's please not get into a flame-war about which is > better.. it's an example), do you really want to reinvent all the > different > authentication type (token card, next pin mode, chap, PAP, EAP, skey, etc > etc) in xauth when it's already been done in PPP? The code exists, is > well-seasoned and well-tested. > > L2tp gives you all those for free via PPP. I see no reason to > reinvent them > in IKE/IPSEC and clutter the rfc's and the already complex code. > > jan > > > Secondly, in response to overhead concerns, the point has been made that > > there are various header compression schemes available in ppp/l2tp which > > mitigate this. While this response addresses the on-the-wire overhead to > > some extent, it ignores the additional packet processing overhead and > > complexity that wrapping the packets in 2 more protocols (all the while > > doing header compression) entails. Please address this. > > > > Finally, in response to the security issues raised by obscuring the > > transit selectors from the ipsec machinery, the argument has been made > > that ppp provides all the necessary protections. However, this is not > > all that reassuring, and conjures up images of the left hand not knowing > > what the right hand is doing. Please elaborate a bit on how this > > mechanism provides comparable assurance to one where ipsec is employed > > alone. > > > > Scott > > > > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > From owner-ipsec@lists.tislabs.com Wed May 24 16:15:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11759; Wed, 24 May 2000 16:15:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06596 Wed, 24 May 2000 18:04:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 24 May 2000 18:12:22 -0400 To: From: Stephen Kent Subject: RE: L2TP+IPsec and IKE authentication Cc: Content-Type: multipart/alternative; boundary="============_-1252916066==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1252916066==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Glen, > > > So, what is disturbing > > about this argument is that we're making architectural accommodations > > for what would normally not be subject to an IETF standard. This is > > even more surprising because in most (if not all) of the other > > security standards I can think of, we are amazingly silent about > > these sorts of assurance issues. Thus I am forced to conclude that > > the departure from this precedent is driven more by market(ing) > > forces than by technology or security concerns. > >God forbid we would allow reality to impinge upon the standardization >process. Often those who disparage standards and cite (their version of) reality as the ultimate test of relevance are those who find solace in the ability of dominant market players to set de facto standards. Such standards need not undergo the scrutiny that the IETF usually imposes on proposals, making life easier for the developers, if not, ultimately, users. It's so nice to see that the disregard for standards processes that you honed during your tenure at Microsoft has not been lost in your transition to Cisco. Steve --============_-1252916066==_ma============ Content-Type: text/enriched; charset="us-ascii" Glen, < > So, what is disturbing > about this argument is that we're making architectural accommodations > for what would normally not be subject to an IETF standard. This is > even more surprising because in most (if not all) of the other > security standards I can think of, we are amazingly silent about > these sorts of assurance issues. Thus I am forced to conclude that > the departure from this precedent is driven more by market(ing) > forces than by technology or security concerns. God forbid we would allow reality to impinge upon the standardization process. Often those who disparage standards and cite (their version of) reality as the ultimate test of relevance are those who find solace in the ability of dominant market players to set de facto standards. Such standards need not undergo the scrutiny that the IETF usually imposes on proposals, making life easier for the developers, if not, ultimately, users. It's so nice to see that the disregard for standards processes that you honed during your tenure at Microsoft has not been lost in your transition to Cisco. Steve --============_-1252916066==_ma============-- From owner-ipsec@lists.tislabs.com Thu May 25 00:16:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18150; Thu, 25 May 2000 00:16:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA07846 Thu, 25 May 2000 02:12:30 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 24 May 2000 23:19:00 -0700 (PDT) From: Jan Vilhuber To: Stephen Kent cc: gwz@cisco.com, ipsec@lists.tislabs.com Subject: RE: L2TP+IPsec and IKE authentication In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's really nice to see this list not degrading to ad hominem attacks. It keeps the discussion productive. Oh wait... jan On Wed, 24 May 2000, Stephen Kent wrote: > Glen, > > > > > > > > > So, what is disturbing > > > about this argument is that we're making architectural accommodations > > > for what would normally not be subject to an IETF standard. This is > > > even more surprising because in most (if not all) of the other > > > security standards I can think of, we are amazingly silent about > > > these sorts of assurance issues. Thus I am forced to conclude that > > > the departure from this precedent is driven more by market(ing) > > > forces than by technology or security concerns. > > > >God forbid we would allow reality to impinge upon the standardization > >process. > > Often those who disparage standards and cite (their version of) > reality as the ultimate test of relevance are those who find solace > in the ability of dominant market players to set de facto standards. > Such standards need not undergo the scrutiny that the IETF usually > imposes on proposals, making life easier for the developers, if not, > ultimately, users. > > It's so nice to see that the disregard for standards processes that > you honed during your tenure at Microsoft has not been lost in your > transition to Cisco. > > Steve > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu May 25 00:16:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18158; Thu, 25 May 2000 00:16:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA07822 Thu, 25 May 2000 02:10:01 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 24 May 2000 23:16:30 -0700 (PDT) From: Jan Vilhuber To: "Scott G. Kelly" cc: gwz@cisco.com, Henry Spencer , IP Security List Subject: Re: Windows 2000 and Cicsco router interoperability In-Reply-To: <392C4DF4.D6EEA3AA@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 24 May 2000, Scott G. Kelly wrote: > Glen Zorn wrote: > > > > > Henry Spencer wrote: > > > > > Granted, if security isn't important to the customer, their security is > > > likely to be weak. But careful design by specifiers and suppliers can > > > have a big effect on *how* weak it is, both by avoiding gratuitous holes > > > and by influencing customer behavior in the right direction. Such > > > measures can considerably improve the odds that a cracker will pick on > > > somebody else. (Flu vaccination will not guarantee that you don't get the > > > flu, but it considerably improves the odds of getting only a mild case.) > > > > To continue your medical analogy (though I'm not sure how appropriate it > > is), if flu shots were as painful as rabies treatment, how many people would > > just take their chances w/the flu? My point here is that the entire purpose > > of xuth/mode config/etc. seems to be to create precisely the functionality > > already present in PPP (and by extension, L2TP). > > > > Actually, I think the entire point of the various user auth proposals > are to create the minimal necessary and sufficient *subset* of the > functionality present in ppp and l2tp in order to enable secure remote > access. > However, experience has shown, that when you trim down and think you can offer the trimmed down version to customers, they usually say: Cool. This is great. Can it also do ? Where foo is usually something that your concept was precisely designed NOT to do... Trimming down, in my opinion, is a bad choice, if you already have a mechanism that does the superset. People invariably will want all features of the superset in the subset (which by definition means you've just reinvented the superset). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu May 25 06:19:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08077; Thu, 25 May 2000 06:19:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08925 Thu, 25 May 2000 08:03:31 -0400 (EDT) Message-ID: <6097687B2BCFD211AFA0006008C9A1A3172E5C@mx.arx.com> From: Prateek Kapadia To: "'ipsec@lists.tislabs.com'" Cc: Amir Shahal Subject: Configuring W2K Server in Tunnel Mode Date: Thu, 25 May 2000 15:11:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We have a W2K Server configured as a VPN Gateway on which we have defined the policy for an IPsec tunnel from the W2K machine to a proprietary IPsec gateway. However, we cannot seem to get the W2K server negotiate tunnel mode. As initiator, it just silently drops traffic. As responder, Phase II fails with the message "Expecting Transport Mode" in the oakley log. The same scenario was tested at the last interoperability workshop where it worked smoothly. We presume that some vendors must have come across a similar scenario and symptoms in W2K configuration for IPsec interoperability testing. We'd appreciate any leads or pointers to parts of the configuration that we may have missed. Thanking you in anticipation, Prateek & Amir Algorithmic Research. From owner-ipsec@lists.tislabs.com Thu May 25 08:37:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA13395; Thu, 25 May 2000 08:37:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09443 Thu, 25 May 2000 10:11:40 -0400 (EDT) Message-ID: <392D3671.48D630E@F-Secure.com> Date: Thu, 25 May 2000 17:19:29 +0300 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Waters, Stephen" CC: Yael Dayan , ipsec@lists.tislabs.com Subject: Re: L2TP+IPsec and IKE authentication References: <29752A74B6C5D211A4920090273CA3DC01D28178@new-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My take is that it is important for the Corporation being accessed whether or not the access device used is secure or not. A cybercafe is not secure enough to access your corporate confidential secrets. I also see certificates and smartcards being readily available in the near future. The obvious result of this line of thinking is that you should be able to use TWO CERTIFICATES per one IKE negotiation. Certificate A is a user-certificate stored in a smartcard. Certificate B is a device certificate stored on a device, and *not* on the smartcard. Then based on the Corporation policy, either/both certificates A or B would be demanded by the SGW. The effect of this is that the probability of using an untrusted access device is less. This would not completely prohibit it, because you can under proper conditions (depending on the HW and stuff) steal either or both of the certificates and the private keys. I see two ways to do this. You create a new IKE phase 1 mode that requires two certificates by one side, maybe both sides (Yikes!?). Or you take the X-Auth draft and put in there a possibility to use further certificate-based authentication. I don't see how PPP/L2TP would be able to help in this scenario. Ari "Waters, Stephen" wrote: > > My take on this is that secondary authentication is needed, be it at the PPP > level, XAUTH or other (e.g. CRACK proposal) to allow for a 'challenge'. > > If we relied solely on a device-loaded certificate or pre-shared secret to > authenticate the user, that is not a 'secure' situation in the event of the > device being 'borrowed'. > > In time, when certificate smartcards and native laptop smartcard readers are > readily available (smartcards that request a user challenge - > pin/signature/biometrics), then we may be able to dispense with > 'device+user' authentication. > > On the up-side, having a root trust in a device, as well as a user of that > device does provide extra security. On the down-side, it is restrictive - > e.g. connecting from shared/public equipment such as from a cyber cafe. > > Steve. > > -----Original Message----- > From: Yael Dayan [ mailto:yael@radguard.com ] > Sent: Wednesday, May 24, 2000 9:51 AM > To: ipsra > Cc: ipsec@lists.tislabs.com > Subject: L2TP+IPsec and IKE authentication > > It seems as though no one is paying attention to an issue that dominated > these mailing lists in the not so far past, concerning the validity of > the authentication procedure imposed by XAUTH. > > L2TP+IPsec requires IKE. IKE is an authenticated key exchange and yet > people clearly state that the user authentication will take place in the > PPP authentication. > This means one of these is true: > 1. Users have certificates. In this case why do we need the PPP > authentication? > 2. Each user has a pre-shared secret with the SGW. Again, why do we need > the PPP authentication? > 3. The user does not authenticate to the SGW and Phase I, Phase II and > IPsec traffic happen prior to authentication of the user. To support > this, IKE requires changes and the architecture in "security > architecture" becomes somewhat questionable. > > Yael -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu May 25 10:38:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16255; Thu, 25 May 2000 10:38:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12891 Thu, 25 May 2000 12:34:24 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Thu, 25 May 2000 09:40:55 -0700 (PDT) From: Jan Vilhuber To: "Scott G. Kelly" cc: gwz@cisco.com, Henry Spencer , IP Security List Subject: Re: Windows 2000 and Cicsco router interoperability In-Reply-To: <392D54DE.32206B3@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 25 May 2000, Scott G. Kelly wrote: > Jan Vilhuber wrote: > > > On Wed, 24 May 2000, Scott G. Kelly wrote: > > > Actually, I think the entire point of the various user auth proposals > > > are to create the minimal necessary and sufficient *subset* of the > > > functionality present in ppp and l2tp in order to enable secure remote > > > access. > > > > > However, experience has shown, that when you trim down and think you can > > offer the trimmed down version to customers, they usually say: Cool. This is > > great. Can it also do ? Where foo is usually something that your concept > > was precisely designed NOT to do... > > > > Trimming down, in my opinion, is a bad choice, if you already have a > > mechanism that does the superset. People invariably will want all features > > of the superset in the subset (which by definition means you've just > > reinvented the superset). > > > > Okay, this brings us back to a question I raised last week which remains > unanswered. We have a requirements document. Most of the functionality > provided by ppp and l2tp is not listed in that document. Your argument > implies that the document is deficient in this regard. Please enumerate > what requirements are missing from that document, as it is very > important that we reach consensus on requirements before we attempt to > select a solution. > I'm not sure what docuemnt you are talking about, and I certainly wan't implying anything in particular. I was merely pointing out the deficiencies of trimming down, and not pointing at any document at all. Maybe someone from the l2tp group can come up with these requirements. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu May 25 10:39:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16390; Thu, 25 May 2000 10:39:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12560 Thu, 25 May 2000 12:22:21 -0400 (EDT) Message-ID: <392D54DE.32206B3@redcreek.com> Date: Thu, 25 May 2000 09:29:18 -0700 From: "Scott G. Kelly" 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 To: Jan Vilhuber CC: gwz@cisco.com, Henry Spencer , IP Security List Subject: Re: Windows 2000 and Cicsco router interoperability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jan, Jan Vilhuber wrote: > On Wed, 24 May 2000, Scott G. Kelly wrote: > > Actually, I think the entire point of the various user auth proposals > > are to create the minimal necessary and sufficient *subset* of the > > functionality present in ppp and l2tp in order to enable secure remote > > access. > > > However, experience has shown, that when you trim down and think you can > offer the trimmed down version to customers, they usually say: Cool. This is > great. Can it also do ? Where foo is usually something that your concept > was precisely designed NOT to do... > > Trimming down, in my opinion, is a bad choice, if you already have a > mechanism that does the superset. People invariably will want all features > of the superset in the subset (which by definition means you've just > reinvented the superset). > Okay, this brings us back to a question I raised last week which remains unanswered. We have a requirements document. Most of the functionality provided by ppp and l2tp is not listed in that document. Your argument implies that the document is deficient in this regard. Please enumerate what requirements are missing from that document, as it is very important that we reach consensus on requirements before we attempt to select a solution. Scott From owner-ipsec@lists.tislabs.com Thu May 25 11:16:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA16979; Thu, 25 May 2000 11:16:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13651 Thu, 25 May 2000 13:02:52 -0400 (EDT) Date: Thu, 25 May 2000 10:09:46 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: "Scott G. Kelly" cc: gwz@cisco.com, Henry Spencer , IP Security List Subject: Re: Windows 2000 and Cicsco router interoperability In-Reply-To: <392C4DF4.D6EEA3AA@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "minimal" "necessary" "sufficient" by whose standards? By standards of the current non-existant remote user population? If they are unnecessary from a remote access point of view then why are they in that standard? The point I am trying to make is that what is "sufficient" today, may not be so tommorow, and thus needs constant hacking of IKE. On Wed, 24 May 2000, Scott G. Kelly wrote: > Glen Zorn wrote: > > > > > Henry Spencer wrote: > > > > > Granted, if security isn't important to the customer, their security is > > > likely to be weak. But careful design by specifiers and suppliers can > > > have a big effect on *how* weak it is, both by avoiding gratuitous holes > > > and by influencing customer behavior in the right direction. Such > > > measures can considerably improve the odds that a cracker will pick on > > > somebody else. (Flu vaccination will not guarantee that you don't get the > > > flu, but it considerably improves the odds of getting only a mild case.) > > > > To continue your medical analogy (though I'm not sure how appropriate it > > is), if flu shots were as painful as rabies treatment, how many people would > > just take their chances w/the flu? My point here is that the entire purpose > > of xuth/mode config/etc. seems to be to create precisely the functionality > > already present in PPP (and by extension, L2TP). > > > > Actually, I think the entire point of the various user auth proposals > are to create the minimal necessary and sufficient *subset* of the > functionality present in ppp and l2tp in order to enable secure remote > access. > > Scott > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu May 25 12:09:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA17873; Thu, 25 May 2000 12:09:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15619 Thu, 25 May 2000 14:10:40 -0400 (EDT) Message-ID: <392D6E40.3318F79A@redcreek.com> Date: Thu, 25 May 2000 11:17:36 -0700 From: "Scott G. Kelly" 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 To: "CHINNA N.R. PELLACURU" CC: gwz@cisco.com, Henry Spencer , IP Security List Subject: Re: Windows 2000 and Cicsco router interoperability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Reply sent to ipsra list since that's where this discussion belongs. "CHINNA N.R. PELLACURU" wrote: > > "minimal" "necessary" "sufficient" by whose standards? By standards of the > current non-existant remote user population? If they are unnecessary from > a remote access point of view then why are they in that standard? > > The point I am trying to make is that what is "sufficient" today, may not > be so tommorow, and thus needs constant hacking of IKE. > > On Wed, 24 May 2000, Scott G. Kelly wrote: > > > Glen Zorn wrote: > > > > > > > > > Henry Spencer wrote: > > > > > > > Granted, if security isn't important to the customer, their security is > > > > likely to be weak. But careful design by specifiers and suppliers can > > > > have a big effect on *how* weak it is, both by avoiding gratuitous holes > > > > and by influencing customer behavior in the right direction. Such > > > > measures can considerably improve the odds that a cracker will pick on > > > > somebody else. (Flu vaccination will not guarantee that you don't get the > > > > flu, but it considerably improves the odds of getting only a mild case.) > > > > > > To continue your medical analogy (though I'm not sure how appropriate it > > > is), if flu shots were as painful as rabies treatment, how many people would > > > just take their chances w/the flu? My point here is that the entire purpose > > > of xuth/mode config/etc. seems to be to create precisely the functionality > > > already present in PPP (and by extension, L2TP). > > > > > > > Actually, I think the entire point of the various user auth proposals > > are to create the minimal necessary and sufficient *subset* of the > > functionality present in ppp and l2tp in order to enable secure remote > > access. > > > > Scott > > > > chinna narasimha reddy pellacuru > s/w engineer From owner-ipsec@lists.tislabs.com Thu May 25 12:12:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA17932; Thu, 25 May 2000 12:12:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15366 Thu, 25 May 2000 14:02:46 -0400 (EDT) Message-ID: <392D6C66.DB7B5F99@redcreek.com> Date: Thu, 25 May 2000 11:09:42 -0700 From: "Scott G. Kelly" 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 To: Jan Vilhuber CC: gwz@cisco.com, Henry Spencer , IP Security List Subject: Re: Windows 2000 and Cicsco router interoperability References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Reply sent to ipsra list, since that is where this discussion belongs. Jan Vilhuber wrote: > > On Thu, 25 May 2000, Scott G. Kelly wrote: > > Jan Vilhuber wrote: > > > > > On Wed, 24 May 2000, Scott G. Kelly wrote: > > > > Actually, I think the entire point of the various user auth proposals > > > > are to create the minimal necessary and sufficient *subset* of the > > > > functionality present in ppp and l2tp in order to enable secure remote > > > > access. > > > > > > > However, experience has shown, that when you trim down and think you can > > > offer the trimmed down version to customers, they usually say: Cool. This is > > > great. Can it also do ? Where foo is usually something that your concept > > > was precisely designed NOT to do... > > > > > > Trimming down, in my opinion, is a bad choice, if you already have a > > > mechanism that does the superset. People invariably will want all features > > > of the superset in the subset (which by definition means you've just > > > reinvented the superset). > > > > > > > Okay, this brings us back to a question I raised last week which remains > > unanswered. We have a requirements document. Most of the functionality > > provided by ppp and l2tp is not listed in that document. Your argument > > implies that the document is deficient in this regard. Please enumerate > > what requirements are missing from that document, as it is very > > important that we reach consensus on requirements before we attempt to > > select a solution. > > > I'm not sure what docuemnt you are talking about, and I certainly wan't > implying anything in particular. I was merely pointing out the deficiencies > of trimming down, and not pointing at any document at all. > > Maybe someone from the l2tp group can come up with these requirements. > > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu May 25 12:51:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA18711; Thu, 25 May 2000 12:51:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15995 Thu, 25 May 2000 14:23:16 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: L2TP+IPsec and IKE authentication Date: Thu, 25 May 2000 11:29:13 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC677.2024A5C6" Message-ID: <6A05D00595BE644E9F435BE5947423F2FFC412@fifi.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4368.4 Thread-Topic: L2TP+IPsec and IKE authentication Thread-Index: Ab/Fz3pHSWcY0knQQIe+bXCS8Nt4fQAnA9qQ From: "William Dixon" To: "Stephen Kent" , Cc: X-OriginalArrivalTime: 25 May 2000 18:31:25.0661 (UTC) FILETIME=[6F1358D0:01BFC677] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFC677.2024A5C6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I wonder if we've lost the view of the remote access market from 3 years ago, and how much better off the situation is now - there are a variety of solutions and many of them and customers are using them to increase their business productivity and reduce direct dial costs. =20 >From a technical perspective, perhaps L2TP/IPSec is more heavy-weight than some remote access usage requires. I have high hopes that the IPSRA WG will get an RFC for a more optimal IPSec-only remote access solution, so customers who can use it will. =20 =20 It's not clear how long the remote access model VPN model will meet business communication requirements. Perhaps the IPSec WG will focus on a solution for multicast & IPv6 that always uses IPSec, end-to-end, with some kind of authenticated gateway traversal, as an alternative to a VPN remote access model. Customers will probably get in the way with those requirements... =20 3yrs ago, many many customers bitterly complained that Microsoft & Cisco didn't have a VPN protocol that worked together, that PPTP had security problems. So our (MS) support for L2TP was by sheer customer (market) demand and technically acceptable for the wide class of problems it solves - a dial compatible, leveraged infrastructure for VPN remote access that was IETF standards based - that worked for all traffic types and could fully replace PPTP. Fortunately L2TP made it to RFC in Aug 99 and requires another IETF standard for security which was already available in the IKE/IPSec RFCs in Dec 98 - which did not provide client remote access features. =20 =20 Now, MS & Cisco have both PPTP (with security fixes of course) and L2TP/IPSec support and customers can get on with their core business. =20 I see all the IPSec related support cases in Microsoft's call database - and I know that there are many practical issues with just unicast IP-only IPSec tunnel mode clients, particularly for Mom & Pop shops, small businesses and relatively unmanaged medium sized company networks - IP-only is network, end-system and application dependent. Large business & enterprise are not so much restricted by IP only. Though some large corporate business decision makers have actually asked us to commit to them that TCPIP is definitely the future, so they can phase out other transport protocols, which would still take a few years as they migrate applications & end-system configurations. Such a question may sound crazy to network engineers & service providers, but it was an important question for the customer to decide to spend the money to migrate their internal infrastructure. =20 =20 Add to this the requirement that people want their end-user remote access experience to be as similar as their at-work desktop experience, existing applications to work and new internal web content delivery multicast applications to work - and we had to provide a solution for IP broadcast & multicast through a tunnel an interoperable, deployable way now, not next year. =20 =20 -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, May 24, 2000 3:12 PM To: gwz@cisco.com Cc: ipsec@lists.tislabs.com Subject: RE: L2TP+IPsec and IKE authentication Glen,=20 =20 > So, what is disturbing=20 > about this argument is that we're making architectural accommodations=20 > for what would normally not be subject to an IETF standard. This is=20 > even more surprising because in most (if not all) of the other=20 > security standards I can think of, we are amazingly silent about=20 > these sorts of assurance issues. Thus I am forced to conclude that=20 > the departure from this precedent is driven more by market(ing)=20 > forces than by technology or security concerns.=20 God forbid we would allow reality to impinge upon the standardization=20 process.=20 Often those who disparage standards and cite (their version of) reality as the ultimate test of relevance are those who find solace in the ability of dominant market players to set de facto standards. Such standards need not undergo the scrutiny that the IETF usually imposes on proposals, making life easier for the developers, if not, ultimately, users.=20 It's so nice to see that the disregard for standards processes that you honed during your tenure at Microsoft has not been lost in your transition to Cisco.=20 Steve=20 ------_=_NextPart_001_01BFC677.2024A5C6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 wonder if we've lost the view of the remote access market from 3 years = ago, and=20 how much better off the situation is now - there are a variety of = solutions and=20 many of them and customers are using them to increase their = business=20 productivity and reduce direct dial costs.
 
From a=20 technical perspective, perhaps L2TP/IPSec is more heavy-weight than some = remote=20 access usage requires.  I have high hopes that the IPSRA WG = will get=20 an RFC for a more optimal IPSec-only remote access solution, so = customers who=20 can use it will. 
 
It's=20 not clear how long the remote access model VPN model will meet business=20 communication requirements.  Perhaps the IPSec WG = will focus=20 on a solution for multicast & IPv6 that always uses IPSec, = end-to-end, with some kind of authenticated gateway traversal, as an = alternative=20 to a VPN remote access model.  Customers will probably = get in the=20 way with those requirements...
 
=
3yrs=20 ago, many many customers bitterly complained that Microsoft = & Cisco=20 didn't have a VPN protocol that worked together, that PPTP had security=20 problems.  So our (MS) support for L2TP was by sheer customer = (market)=20 demand and technically acceptable for the wide class of problems it = solves=20 - a dial compatible, leveraged infrastructure for VPN remote=20 access that was IETF standards based - that worked for all traffic = types=20 and could fully replace PPTP.  Fortunately L2TP made it to = RFC in Aug=20 99 and requires another IETF standard for security which was already = available=20 in the IKE/IPSec RFCs in Dec 98 - which did not provide client remote = access=20 features. 
 
Now,=20 MS & Cisco have both PPTP (with security fixes of course) and=20 L2TP/IPSec support and customers can get on with their core=20 business.
 
I see all the IPSec related = support cases=20 in Microsoft's call database - and I know that there are many = practical=20 issues with just unicast IP-only IPSec tunnel mode clients, particularly = for Mom=20 & Pop shops, small businesses and relatively unmanaged medium sized = company=20 networks - IP-only is network, end-system and application = dependent. =20 Large business & enterprise are not so much restricted by IP = only. =20 Though some large corporate business decision makers have actually = asked us=20 to commit to them that TCPIP is definitely the future, so they can = phase=20 out other transport protocols, which would still take a few years as = they=20 migrate applications & end-system configurations.  Such a = question=20 may sound crazy to network engineers & service = providers, but=20 it was an important question for the customer to decide to spend = the money=20 to migrate their internal infrastructure. 
 
Add to=20 this the requirement that people want their end-user remote access=20 experience to be as similar as their at-work desktop experience, = existing=20 applications to work and new internal web content delivery multicast=20 applications to work - and we had to provide a solution for IP = broadcast=20 & multicast through a tunnel an interoperable, deployable way = now, not=20 next year.
 
 
-----Original=20 Message-----
From: Stephen Kent = [mailto:kent@bbn.com]
Sent:=20 Wednesday, May 24, 2000 3:12 PM
To: = gwz@cisco.com
Cc:=20 ipsec@lists.tislabs.com
Subject: RE: L2TP+IPsec and IKE=20 authentication

Glen,


<snip>




> So, what is disturbing

> about this argument is that we're making architectural = accommodations=20

> for what would normally not be subject to an IETF standard. = This is=20

> even more surprising because in most (if not all) of the other =

> security standards I can think of, we are amazingly silent = about

> these sorts of assurance issues. Thus I am forced to conclude = that=20

> the departure from this precedent is driven more by = market(ing)

> forces than by technology or security concerns.


God forbid we would allow reality to impinge upon the = standardization

process.


Often those who disparage standards and cite (their version of) = reality as=20 the ultimate test of relevance are those who find solace in the = ability of=20 dominant market players to set de facto standards. Such = standards need=20 not undergo the scrutiny that the IETF usually imposes on proposals, = making=20 life easier for the developers, if not, ultimately, users.


It's so nice to see that the disregard for standards processes that = you=20 honed during your tenure at Microsoft has not been lost in your = transition to=20 Cisco.


Steve

------_=_NextPart_001_01BFC677.2024A5C6-- From owner-ipsec@lists.tislabs.com Thu May 25 15:08:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20403; Thu, 25 May 2000 15:08:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA19449 Thu, 25 May 2000 16:23:10 -0400 (EDT) Message-Id: <4.3.1.0.20000525132635.00af9c80@brisco.passedge.com> X-Sender: mbaugher@brisco.passedge.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 25 May 2000 13:27:59 -0700 To: William Dixon , Stephen Kent , gwz@cisco.com From: Mark Baugher Subject: RE: L2TP+IPsec and IKE authentication Cc: ipsec@lists.tislabs.com In-Reply-To: <6A05D00595BE644E9F435BE5947423F2FFC412@fifi.platinum.corp. microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:29 AM 5/25/00 -0700, William Dixon wrote: > >Add to this the requirement that people want their end-user remote >access experience to be as similar as their at-work desktop experience, >existing applications to work and new internal web content delivery >multicast applications to work - and we had to provide a solution for IP >broadcast & multicast through a tunnel an interoperable, deployable way >now, not next year. > Why is it necessary to have a tunnel for "IP broadcast and multicast?" Mark Baugher PGP Fingerprint 01AB 9388 D69F A8E6 DD38 4D9B D558 79F3 7D45 6B1C From owner-ipsec@lists.tislabs.com Thu May 25 15:31:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20689; Thu, 25 May 2000 15:31:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20973 Thu, 25 May 2000 17:23:50 -0400 (EDT) Message-Id: <4.2.0.58.20000525173612.00a33bf0@pop3.indusriver.com> X-Sender: dchen@pop3.indusriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 25 May 2000 17:39:49 -0400 To: ipsec@lists.tislabs.com From: David Chen Subject: Is "Denial Of Service attack" a security issue? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If no, the IPSec is not "safe". --- David From owner-ipsec@lists.tislabs.com Thu May 25 19:47:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA14048; Thu, 25 May 2000 19:47:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27591 Thu, 25 May 2000 21:24:41 -0400 (EDT) From: "Mr. Anderson" Message-Id: <200005260132.VAA07567@linux.silkroad.com> Subject: Re: Is "Denial Of Service attack" a security issue? To: dchen@indusriver.com (David Chen) Date: Thu, 25 May 100 21:32:24 -0400 (EDT) Cc: ipsec@lists.tislabs.com In-Reply-To: <4.2.0.58.20000525173612.00a33bf0@pop3.indusriver.com> from "David Chen" at May 25, 0 05:39:49 pm X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, DoD attacks are all security related and yes there has been a tendency in all systems to spend a lot of time in the weeds on bits and bites and not on obvious system availabiity issues. Yes, IPSec , and in particular, the ISAKMP UDP mechanism has been documented as a future easily 'script kiddied' attack. And yes, these types of attacks are very difficult to stop, and yes, it has been discussed here and elsewhere, and yes, in all likelihood IPSec will suffer from future DoS attacks at the protocol implementation becomes more widespread and yes, no systems can be made 100 percent secure, and yes, all deployment and fielding issues are based on a risk managment method, and yes, when the benefits outweight the risks things move forward, and yes, for the vast majority of IPSec implementations the DoS risk is acceptable, and yes there are operational systems where the risk criteria are not acceptable and yes these are business case issues which orgs will decide based on their operational model. In a nutshell. IPSec is not perfect, but it is pretty darn good and much better than no-IPsec. -Neo > > If no, the IPSec is not "safe". > --- David > -- --------------------------- The Y2K Feature: A way of remaining in the 20th century for a little longer ..... 19 - 100 ... a feature, not a bug :) From owner-ipsec@lists.tislabs.com Thu May 25 20:09:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16813; Thu, 25 May 2000 20:09:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27914 Thu, 25 May 2000 21:36:10 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: Configuring W2K Server in Tunnel Mode Date: Thu, 25 May 2000 18:40:18 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC6B3.590D5A9A" Message-ID: <6A05D00595BE644E9F435BE5947423F2FFC416@fifi.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4368.4 Thread-Topic: Configuring W2K Server in Tunnel Mode Thread-Index: Ab/GRKGOtG8ipjDjTFe72DPsUbJ4nQAYqcxw From: "William Dixon" To: "Prateek Kapadia" , Cc: "Amir Shahal" X-OriginalArrivalTime: 26 May 2000 01:44:08.0883 (UTC) FILETIME=[E25CA030:01BFC6B3] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01BFC6B3.590D5A9A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Prateek, please direct all Win2k questions to the Windows 2000 newsgroup where our support engineers and others doing similar things will see it. It appears to me on the inside as: ms.beta.win2000.networking, or it could be advertised as microsoft.public.win2000.networking This KB article, Q252735, describes how to configure Win2k tunnel mode =20 http://support.microsoft.com/support/kb/articles/Q252/7/35.ASP?LN=3DEN-US= & SD=3Dgn&FR=3D0 Win2k supports address based filters only: =20 http://support.microsoft.com/support/kb/articles/Q248/9/83.ASP?LN=3DEN-US= & SD=3Dgn&FR=3D0 Use the win2k support tool command "netdiag /test:ipsec /v debug" to dump policy & filter state. -----Original Message----- From: Prateek Kapadia [mailto:prateek@arx.com] Sent: Thursday, May 25, 2000 6:12 AM To: 'ipsec@lists.tislabs.com' Cc: Amir Shahal Subject: Configuring W2K Server in Tunnel Mode We have a W2K Server configured as a VPN Gateway on which we have defined the policy for an IPsec tunnel from the W2K machine to a proprietary IPsec gateway. However, we cannot seem to get the W2K server negotiate tunnel mode. As initiator, it just silently drops traffic. As responder, Phase II fails with the message "Expecting Transport Mode" in the oakley log. The same scenario was tested at the last interoperability workshop where it worked smoothly. We presume that some vendors must have come across a similar scenario and symptoms in W2K configuration for IPsec interoperability testing. We'd appreciate any leads or pointers to parts of the configuration that we may have missed. Thanking you in anticipation, Prateek & Amir Algorithmic Research. ------_=_NextPart_001_01BFC6B3.590D5A9A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: Configuring W2K Server in Tunnel Mode

Prateek, please direct all Win2k questions to the = Windows 2000 newsgroup where our support engineers and others doing = similar things will see it.

It appears to me on the inside as: = ms.beta.win2000.networking, or it could be advertised as = microsoft.public.win2000.networking

This KB article, Q252735, describes how to configure = Win2k tunnel mode
   http://support.microsoft.com/support/kb/articles= /Q252/7/35.ASP?LN=3DEN-US&SD=3Dgn&FR=3D0

Win2k supports address based filters only:
   http://support.microsoft.com/support/kb/articles= /Q248/9/83.ASP?LN=3DEN-US&SD=3Dgn&FR=3D0

Use the win2k support tool command "netdiag = /test:ipsec /v debug" to dump policy & filter state.

-----Original Message-----
From: Prateek Kapadia [mailto:prateek@arx.com]
Sent: Thursday, May 25, 2000 6:12 AM
To: 'ipsec@lists.tislabs.com'
Cc: Amir Shahal
Subject: Configuring W2K Server in Tunnel Mode



We have a W2K Server configured as a VPN Gateway on = which we have defined
the policy for an IPsec tunnel from the W2K machine = to a proprietary IPsec
gateway. However, we cannot seem to get the W2K = server negotiate tunnel
mode. As initiator, it just silently drops traffic. = As responder, Phase II
fails with the message "Expecting Transport = Mode" in the oakley log.

The same scenario was tested at the last = interoperability workshop where it
worked smoothly. We presume that some vendors must = have come across a
similar scenario and symptoms in W2K configuration = for IPsec
interoperability testing. We'd appreciate any leads = or pointers to parts of
the configuration that we may have missed.

Thanking you in anticipation,
Prateek & Amir
Algorithmic Research.

------_=_NextPart_001_01BFC6B3.590D5A9A-- From owner-ipsec@lists.tislabs.com Fri May 26 06:47:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05741; Fri, 26 May 2000 06:47:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA06455 Fri, 26 May 2000 07:53:56 -0400 (EDT) Message-ID: <001001bfc6d5$e9e584d0$0a00000a@cit10> From: =?gb2312?B?zsK41g==?= To: Subject: Network Neighborhood on IPSec in Tunneling mode Date: Fri, 26 May 2000 13:47:38 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01BFC718.F4AC7A70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000D_01BFC718.F4AC7A70 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgZXZlcnlvbmU7DQogICBJIGhhdmUgaW1wbGVtZW50dGVkIElQU2VjIHByb3RvY29sIGluIFR1 bm5lbGluZyBtb2RlIG9uIG15IA0KZ2F0ZXdheS5JIHdhbnQgdG8gdXNlIHRoaXMgZ2F0ZXdheSB0 byBjb25uZWN0IHNlcnZlbCBzdWJuZXQgaW50bw0KYSB2aXJ0dWFsIHN1Ym5ldC5TbyBJIHNlbmQg YWxsIHRoZSBicm9hZGNhc3QgaXAgcGFja2V0IGFuZCBJQ01QDQpwYWNrZXQgdG8gZWFjaCBzdWJu ZXQuTm93IEkgY2FuIHVzZSB0aGUgYWRkcmVzcyxzdWNoIGFzDQoiXFwxMC4wLjAuMTBcdXNlcnMg InRvIGFjY2VzcyB0aGUgY29tcHV0ZXIgaW4gb3RoZXIgc3VibmV0Lg0KQnV0IEkgY2FuJ3Qgc2Vl IHRoZW0gaW4gbmV0d29yayBuZWlnaGJvcmhvb2QhDQpDYW4gYW55b25lIHRlbGwgbWUgaG93IHRv IGltcGxlbWVudCBpdD8NClRoYW5rcyBhIGxvdCENCg0KQmlsbCBXZW4NCg0K ------=_NextPart_000_000D_01BFC718.F4AC7A70 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC4zODI1LjEzMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IaSBldmVyeW9uZTs8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDtJIGhhdmUgaW1w bGVtZW50dGVkIElQU2VjIHByb3RvY29sIGluIA0KVHVubmVsaW5nIG1vZGUgb24gbXkgPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Z2F0ZXdheS5JIHdhbnQgdG8gPC9GT05UPjxGT05U IHNpemU9Mj51c2UgdGhpcyBnYXRld2F5IHRvIA0KY29ubmVjdCBzZXJ2ZWwgc3VibmV0IGludG88 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5hIHZpcnR1YWwgc3VibmV0LjwvRk9OVD48 Rk9OVCBzaXplPTI+U28gSSBzZW5kIGFsbCB0aGUgDQpicm9hZGNhc3QgaXAgcGFja2V0IGFuZCBJ Q01QPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+cGFja2V0IHRvIGVhY2ggc3VibmV0 Lk5vdyBJIGNhbiB1c2UgdGhlIGFkZHJlc3Msc3VjaCANCmFzPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+IjxBIGhyZWY9ImZpbGU6Ly9cXDEwLjAuMC4xMFx1c2VycyI+XFwxMC4wLjAu MTBcdXNlcnM8L0E+ICJ0byANCmFjY2VzcyB0aGUgY29tcHV0ZXIgaW4gb3RoZXIgc3VibmV0Ljwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkJ1dCBJIGNhbid0IHNlZSB0aGVtIGluIG5l dHdvcmsgbmVpZ2hib3Job29kITwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkNhbiBh bnlvbmUgdGVsbCBtZSBob3cgdG8gaW1wbGVtZW50IGl0PzwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPlRoYW5rcyBhIGxvdCE8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5CaWxsIFdlbjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRElWPjwvRk9OVD48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000D_01BFC718.F4AC7A70-- From owner-ipsec@lists.tislabs.com Fri May 26 07:57:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07285; Fri, 26 May 2000 07:57:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06910 Fri, 26 May 2000 09:45:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Fri, 26 May 2000 06:44:05 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: New patent info Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IETF's intellectual property repository got an interesting addition yesterday: . Has anyone heard of this before? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri May 26 08:14:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07621; Fri, 26 May 2000 08:14:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06981 Fri, 26 May 2000 10:02:59 -0400 (EDT) Message-Id: <4.2.0.58.20000526101529.00a36310@pop3.indusriver.com> X-Sender: dchen@pop3.indusriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 26 May 2000 10:19:03 -0400 To: "Mr. Anderson" From: David Chen Subject: Re: Is "Denial Of Service attack" a security issue? Cc: ipsec@lists.tislabs.com In-Reply-To: <200005260132.VAA07567@linux.silkroad.com> References: <4.2.0.58.20000525173612.00a33bf0@pop3.indusriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since the IPSec, especially IKE, is not DOS attack resistant, what is the IPSec security level try to achieve? Shall this been documented in the RFC for the scope/capability of security level? Or let user find out later? (ie. been attacked) --- David At 09:32 PM 5/25/00 -0400, you wrote: >Yes, DoD attacks are all security related and yes there >has been a tendency in all systems to spend a lot of time >in the weeds on bits and bites and not on obvious system >availabiity issues. Yes, IPSec , and in particular, the >ISAKMP UDP mechanism has been documented as a future >easily 'script kiddied' attack. And yes, these types >of attacks are very difficult to stop, and yes, it has >been discussed here and elsewhere, and yes, in all likelihood >IPSec will suffer from future DoS attacks at the protocol >implementation becomes more widespread and yes, no systems >can be made 100 percent secure, and yes, all deployment >and fielding issues are based on a risk managment method, >and yes, when the benefits outweight the risks things move >forward, and yes, for the vast majority of IPSec implementations >the DoS risk is acceptable, and yes there are operational >systems where the risk criteria are not acceptable and yes >these are business case issues which orgs will decide based >on their operational model. > >In a nutshell. IPSec is not perfect, but it is pretty >darn good and much better than no-IPsec. > > >-Neo > > > > If no, the IPSec is not "safe". > > --- David > > > > >-- > >--------------------------- >The Y2K Feature: > >A way of remaining in the 20th century for a little >longer ..... 19 - 100 ... a feature, not a bug :) ======================================== David Chen Indus River Networks, Inc. www.indusriver.com 31 Nagog Park Acton, MA 01720 U.S.A. dchen@indusriver.com (978) 266-8141 ======================================== From owner-ipsec@lists.tislabs.com Fri May 26 10:12:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10064; Fri, 26 May 2000 10:12:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07651 Fri, 26 May 2000 12:08:26 -0400 (EDT) Message-Id: <4.2.0.58.20000526122316.00a3d720@pop3.indusriver.com> X-Sender: dchen@pop3.indusriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 26 May 2000 12:24:40 -0400 To: "Scott G. Kelly" From: David Chen Subject: Re: Is "Denial Of Service attack" a security issue? Cc: ipsec@lists.tislabs.com In-Reply-To: <392EA14F.72C69936@redcreek.com> References: <4.2.0.58.20000525173612.00a33bf0@pop3.indusriver.com> <4.2.0.58.20000526101529.00a36310@pop3.indusriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 09:07 AM 5/26/00 -0700, you wrote: >David Chen wrote: > > > > Since the IPSec, especially IKE, is not DOS attack resistant, > > what is the IPSec security level try to achieve? > > Shall this been documented in the RFC for the scope/capability of > > security level? > > Or let user find out later? (ie. been attacked) > > --- David > >While there are DoS issues in IKE that may be remedied by modifications, >I think that a device which is capable of wireline-speed processing is >effectively immune to most of these. In the case where an attacker is >capable of saturating the medium with packets, there are other remedies. > >I think there was consensus in Adelaide that IKE could benefit from some >revisions, although it's not clear how much revision the AD's will >permit at this point. If you have specific suggestions for bolstering >IKE in terms of DoS attacks, I certainly would be interested in hearing >them. > >One such suggestion has already been documented in a draft (IKE base >mode). Are you referring "cookies" solution that was killed by simpson's draft? >Scott From owner-ipsec@lists.tislabs.com Fri May 26 10:13:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10085; Fri, 26 May 2000 10:13:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07675 Fri, 26 May 2000 12:13:02 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B003694E0D@hdsmsx31.hd.intel.com> From: "Shriver, John" To: "'Paul Hoffman'" , ipsec@lists.tislabs.com Subject: RE: New patent info Date: Fri, 26 May 2000 09:20:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's going to have an interesting problem with prior art from RFC 1038 in 1988, given that is has a filing date of 1989. This patent is for a toy. One that would have been obvious even then. It hadn't been previously patented because it was obvious and banally useless. It quite obviously has no relevance to IPsec. You can't even claim access controls, since routers had those before 1988. He's fishing. Use you judgement as to whether you want to spend any money on a lawyer over this. At leas the IETF's IPR process is no longer so broken that this would stop all progress on IPsec. (I once posed a hypothetical example on the PPP mailing list, and caused a complete panic.) > -----Original Message----- > From: Paul Hoffman [mailto:phoffman@vpnc.org] > Sent: Friday, May 26, 2000 9:44 AM > To: ipsec@lists.tislabs.com > Subject: New patent info > > > The IETF's intellectual property repository got an interesting > addition yesterday: . Has > anyone heard of this before? > > --Paul Hoffman, Director > --VPN Consortium > > From owner-ipsec@lists.tislabs.com Fri May 26 10:13:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10099; Fri, 26 May 2000 10:13:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07643 Fri, 26 May 2000 12:08:13 -0400 (EDT) From: "Linda Walsh" To: "David Chen" , "Mr. Anderson" Cc: Subject: RE: Is "Denial Of Service attack" a security issue? Date: Fri, 26 May 2000 09:14:53 -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: <4.2.0.58.20000526101529.00a36310@pop3.indusriver.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm somewhat new to this area, but it seems you can define DOS security threats using temporal constraints on state change. For example. At each point in a security state diagram, you have a subject requesting some access (r,w,x,a) to an object. The secure Reference Monitor (RM, Target of Evaluation (TOE) or Trusted Computing Base (TCB) decides to honor or reject the request. A reject means the subject isn't authorized to do whatever. An accept means it is. If you add temporal constraints, you have a means of defining DOS threats. The first level of DOS, it would seem, would be that the 'request' got "lost" (dropped). That's pretty bad. Imagine an OS that under high load just never 'hears' a programs request to read a file. Unconscionable. For such a situation to occur, it usually means 'system failure' -- something almost always consider a fatal flaw (except for deadlock cases where say 2 users each want all of memory to do a task, but each only asks for half to begin with, then each ask for 2nd half and both wait a *very* long time) -- or the case where they want 2 files and they don't lock the files in the same order). In a 'well working' system the system may thrash for a while under high load, but it won't "drop" the read request, it just may take a while. An example under Linux -- under 2.2.5, I believe, was my using "dd if=/dev/sdb of=/dev/sdc" to copy a disk. A 9G disk took about 15-20 minutes. Ok...fine. Then I had to do the same w/an 18G. Took 9-10 hours! It did finish, but it thrashed horribly. While the machine had 1G of memory, Linux didn't handle buffers cleanly. So my time to finish wasn't linear. I'd say it was a bug in how Linux handled buffers at the time -- *BUT* it didn't cause a system failure and the request *was* complete. Since there were no 'hard' real-time constraints, this was 'ok' (not desirable, but it 'passed'). In that example, it wasn't really a DOS caused by an external user, but one caused by a system flaw (that has since been remedied -- the same copy now takes about 40 minutes -- a linear increase). Anyway, in order to address/measure DOS security issues, one could add the operator a time constraint to the state change. One then can define priorities in the protocol and classes of service. Ideally, unauthorized users would never be able to deny service (w/in a time constraint) to an authorized user. Another means is to use 'resource usage bounding' on individual users. Say anything more than 3 requests for the same webpage within second or 100 requests total for the same user (arbitrary numbers pulled out of a hat) are limits. Users exceeding those limits are regarded as violating security policy and are denied. This allows 'legitimate' users continued access in the face of a DOS attach. It could also be possible for those limits to be dynamic based on total system load. Something like how UNIX deals with time-share cpu priorities -- those that are CPU hogs get lower priorities than those using little CPU. Oddly, it's been common-place for *YEARS* to have cpu, file-size and memory limitations or dynamic priorities on users -- but it is still rare to any something like that built in to an OS. It's sorta like OS's of today are still operating like single-user systems and networking is something that was just tacked on as an afterthought. (Oh how many times have I wished that I could renice a process's network priority -- large file xfer (maybe hours long) in background over an ISDN line, but I want my interactive sessions or small file copies to be snappy). This may be beyond the scope of IPsec, but ...it'd be nice to start thinking about it or at least the support for such concepts... -Linda > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of David Chen > Sent: Friday, May 26, 2000 7:19 AM > To: Mr. Anderson > Cc: ipsec@lists.tislabs.com > Subject: Re: Is "Denial Of Service attack" a security issue? > > > Since the IPSec, especially IKE, is not DOS attack resistant, > what is the IPSec security level try to achieve? > Shall this been documented in the RFC for the scope/capability of > security level? > Or let user find out later? (ie. been attacked) > --- David > > From owner-ipsec@lists.tislabs.com Fri May 26 10:16:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10134; Fri, 26 May 2000 10:16:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07573 Fri, 26 May 2000 12:00:47 -0400 (EDT) Message-ID: <392EA14F.72C69936@redcreek.com> Date: Fri, 26 May 2000 09:07:43 -0700 From: "Scott G. Kelly" 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 To: David Chen CC: "Mr. Anderson" , ipsec@lists.tislabs.com Subject: Re: Is "Denial Of Service attack" a security issue? References: <4.2.0.58.20000525173612.00a33bf0@pop3.indusriver.com> <4.2.0.58.20000526101529.00a36310@pop3.indusriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Chen wrote: > > Since the IPSec, especially IKE, is not DOS attack resistant, > what is the IPSec security level try to achieve? > Shall this been documented in the RFC for the scope/capability of > security level? > Or let user find out later? (ie. been attacked) > --- David While there are DoS issues in IKE that may be remedied by modifications, I think that a device which is capable of wireline-speed processing is effectively immune to most of these. In the case where an attacker is capable of saturating the medium with packets, there are other remedies. I think there was consensus in Adelaide that IKE could benefit from some revisions, although it's not clear how much revision the AD's will permit at this point. If you have specific suggestions for bolstering IKE in terms of DoS attacks, I certainly would be interested in hearing them. One such suggestion has already been documented in a draft (IKE base mode). Scott From owner-ipsec@lists.tislabs.com Fri May 26 10:24:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10436; Fri, 26 May 2000 10:24:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07700 Fri, 26 May 2000 12:21:27 -0400 (EDT) Message-ID: <392EA625.CEABA23E@redcreek.com> Date: Fri, 26 May 2000 09:28:21 -0700 From: "Scott G. Kelly" 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 To: David Chen CC: ipsec@lists.tislabs.com Subject: Re: Is "Denial Of Service attack" a security issue? References: <4.2.0.58.20000525173612.00a33bf0@pop3.indusriver.com> <4.2.0.58.20000526101529.00a36310@pop3.indusriver.com> <4.2.0.58.20000526122316.00a3d720@pop3.indusriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David Chen wrote: > > Are you referring "cookies" solution that was killed by simpson's draft? > > >Scott No, I'm referring to the ike base mode draft. See http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-base-mode-02.txt Scott From owner-ipsec@lists.tislabs.com Fri May 26 11:33:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11499; Fri, 26 May 2000 11:33:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08050 Fri, 26 May 2000 13:08:00 -0400 (EDT) Message-Id: <4.2.0.58.20000526131511.00a36730@pop3.indusriver.com> X-Sender: dchen@pop3.indusriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 26 May 2000 13:24:07 -0400 To: "Scott G. Kelly" From: David Chen Subject: Re: Is "Denial Of Service attack" a security issue? Cc: ipsec@lists.tislabs.com In-Reply-To: <392EA625.CEABA23E@redcreek.com> References: <4.2.0.58.20000525173612.00a33bf0@pop3.indusriver.com> <4.2.0.58.20000526101529.00a36310@pop3.indusriver.com> <4.2.0.58.20000526122316.00a3d720@pop3.indusriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, Thanks for the pointer. After reading this draft, here is my comments: 1. base mode with signature - it possibly takes lots of resource to verity the signature. 2. base mode with public key - subject to MIM attack and need lots of resource for RSA public operation. 3. base mode with revised public key - same as 3 -> can you trust this key? 4. base mode with pre-shared key - less resources but subject to spoofing... --- David At 09:28 AM 5/26/00 -0700, you wrote: >David Chen wrote: > > > > Are you referring "cookies" solution that was killed by simpson's draft? > > > > >Scott > >No, I'm referring to the ike base mode draft. See > >http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-base-mode-02.txt > >Scott From owner-ipsec@lists.tislabs.com Fri May 26 13:49:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13736; Fri, 26 May 2000 13:49:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08785 Fri, 26 May 2000 15:40:27 -0400 (EDT) Message-ID: <392ED525.D0DDEB1E@insight-corp.com> Date: Fri, 26 May 2000 15:49:56 -0400 From: Chris Whitely Reply-To: chrisw@insight-corp.com X-Mailer: Mozilla 4.72 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IP QoS Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Anyone know any good documents for 1) giving an overview about how IP VPN QoS is maintained on an end-to-end basis, and 2) the network software tools necessary to manage IP VPNs? Thanks, Chris -- Christopher P. Whitely Project Manager The Insight Research Corporation Gatehall I, One Gatehall Drive Parsippany, NJ 07054 Phone: 973-605-1400 Fax: 973-605-1440 http://www.insight-corp.com From owner-ipsec@lists.tislabs.com Sat May 27 16:35:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07900; Sat, 27 May 2000 16:35:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13259 Sat, 27 May 2000 18:14:18 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "Shriver, John" Cc: "'Paul Hoffman'" , ipsec@lists.tislabs.com, sob@harvard.edu Subject: Re: New patent info Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 May 2000 18:22:12 -0400 Message-Id: <20000527222213.A9C5535DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <392A357CE6FFD111AC3E00A0C99848B003694E0D@hdsmsx31.hd.intel.com>, "S hriver, John" writes: >It's going to have an interesting problem with prior art from RFC 1038 in >1988, given that is has a filing date of 1989. > >This patent is for a toy. One that would have been obvious even then. It >hadn't been previously patented because it was obvious and banally useless. > >It quite obviously has no relevance to IPsec. > >You can't even claim access controls, since routers had those before 1988. > >He's fishing. > >Use you judgement as to whether you want to spend any money on a lawyer over >this. At leas the IETF's IPR process is no longer so broken that this would >stop all progress on IPsec. (I once posed a hypothetical example on the PPP >mailing list, and caused a complete panic.) Agreed -- it's preposterous. RFC 791 had security labels. And the patent specifically notes that encryption is too expensive, which makes the relevance to IPsec dubious, at best. --Steve Bellovin From owner-ipsec@lists.tislabs.com Sat May 27 19:32:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA27342; Sat, 27 May 2000 19:32:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA13619 Sat, 27 May 2000 21:32:32 -0400 (EDT) Date: Sun, 28 May 2000 11:39:58 +1000 (EST) From: KokMing Subject: Reasons for AH & ESP To: ipsec@lists.tislabs.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Does anyone know, or is able to explain the reasons for AH & ESP? As Neil Ferguson and Bruce Schneier wrote in 'Cryptographic Evaluation of IPsec', I too, find no reasons for two protocols in the RFCs. The reasons I think of is.. 1. Cryptography is not exportable Well, it's more or less exportable now, and does the use of MD5 as a HMAC count as cryptography? I think not. Wouldn't it be better to have an ESP with compulsory AH authentication, and optional encryption? 2. It's more flexible IMHO, the flexibility of IPsec is killing it, the configurations are simply too numerous and complex for a layman (like me) to make head and tail, much less use it properly. 3. Finer grain of control As said, is it necessary? Will it make IPsec more secure against cracking? or spoofing? or nothing? I'm sorry if this has been dwelt on long ago, but I simply couldn't stand the mess IPsec is in, while I'm writing a paper about it, and I'll like some comments on my views. Regards, Kokming Ang ISRC Queensland University of Technology Brisbane, Australia From owner-ipsec@lists.tislabs.com Mon May 29 02:22:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12205; Mon, 29 May 2000 02:22:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA17245 Mon, 29 May 2000 03:48:53 -0400 (EDT) Message-ID: <11EAD88229D3D3118A4D009027DC878C0B9D05@magnum.osd.ausys.se> From: Per Persson Exjobbare To: ipsec@lists.tislabs.com Subject: IPSec between Windows2000 and Solaris8 Date: Mon, 29 May 2000 09:57:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello again I want to get a IPSec-secured connection between a Solaris8 workstation and a Windows2000 server. Does anyone know how to configure IPSec to work between these two platforms or where i can find information about it? Thanks Per Persson __________________________________ Per Persson AU-System SWEDEN www.ausys.se Examensarbetare phone: +46 (0)70-3287457 email: per.persson@ausys.se From owner-ipsec@lists.tislabs.com Mon May 29 07:08:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24894; Mon, 29 May 2000 07:08:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18129 Mon, 29 May 2000 08:58:40 -0400 (EDT) Message-Id: <4.3.1.2.20000529085323.00eba100@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 29 May 2000 09:00:35 -0400 To: KokMing , ipsec@lists.tislabs.com From: Robert Moskowitz Subject: Re: Reasons for AH & ESP In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:39 AM 5/28/2000 +1000, KokMing wrote: >Does anyone know, or is able to explain the reasons for AH & ESP? >As Neil Ferguson and Bruce Schneier wrote in 'Cryptographic Evaluation of >IPsec', I too, find no reasons for two protocols in the RFCs. Part of it is Historical: 1) Review RFCs 1825 - 1829. Then ESP did not do packet authentication. For privacy and authentication, yoiu needed both AH + ESP. 2) Early reworking of ESP, adding authentication (after the Danver's IETF) did not have a mode with authentication and no privacy. This only came about when I convinced Rob Glenn to write the NULL transform draft at the IPsec workshop in Raleigh NC (Workshop #5). During standards development, it was of greater concern to get things right than to argue what to prune. There where some back then, that valued AH over ESP NULL for export reasons, for example. Then there is the IPv6 concern. AH DOES offer header protection for IPv6 that ESP cannot provide. Hope this helps some. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec@lists.tislabs.com Mon May 29 21:02:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA06688; Mon, 29 May 2000 21:02:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA20684 Mon, 29 May 2000 22:42:11 -0400 (EDT) Message-Id: <200005300250.WAA07451@granger.mail.mindspring.net> X-Sender: krumpli6@mail.mindspring.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 29 May 2000 22:50:57 -0400 To: ipsec@lists.tislabs.com From: "Thomas Porter, Ph.D." Subject: Re: Reasons for AH & ESP In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:39 AM 5/28/2000 +1000, you wrote: >Hi, > >Does anyone know, or is able to explain the reasons for AH & ESP? >As Neil Ferguson and Bruce Schneier wrote in 'Cryptographic Evaluation of >IPsec', I too, find no reasons for two protocols in the RFCs. > Currently, there is no reason to do AH. It's a relic... Tom >The reasons I think of is.. > >1. Cryptography is not exportable >Well, it's more or less exportable now, and does the use of MD5 as a HMAC >count as cryptography? I think not. Wouldn't it be better to have an ESP >with compulsory AH authentication, and optional encryption? > >2. It's more flexible >IMHO, the flexibility of IPsec is killing it, the configurations are >simply too numerous and complex for a layman (like me) to make head and >tail, much less use it properly. > >3. Finer grain of control >As said, is it necessary? Will it make IPsec more secure against >cracking? or spoofing? or nothing? > >I'm sorry if this has been dwelt on long ago, but I simply couldn't stand >the mess IPsec is in, while I'm writing a paper about it, and I'll like >some comments on my views. > >Regards, >Kokming Ang > >ISRC >Queensland University of Technology >Brisbane, Australia > ***************************** Thomas Porter, Ph.D. http://www.dtool.com http://www.xnetsec.com "There is magic in the web." Shakespeare Othello, Act 3, Scene 4 ********************************** From owner-ipsec@lists.tislabs.com Tue May 30 07:02:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06663; Tue, 30 May 2000 07:02:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22143 Tue, 30 May 2000 08:35:53 -0400 (EDT) Message-Id: <3.0.5.32.20000529125806.032d9e40@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 29 May 2000 12:58:06 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Reasons for AH & ESP In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id GAA17826 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:39 28.5.2000 +1000, you wrote: >Hi, > >Does anyone know, or is able to explain the reasons for AH & ESP? >As Neil Ferguson and Bruce Schneier wrote in 'Cryptographic Evaluation of >IPsec', I too, find no reasons for two protocols in the RFCs. > If I understand the Subject line correctly, you are not talking about ESP and AH applied to packets after another, but "why two protocols, when one would be enough?". Well, if you look at IPv4 only, it doesn't make sense, agreed. AH's main feature is that is protects parts of the IP header. But in IPv4, there isn't anything interesting to protect. Thus, you don't need AH, ESP-NULL-SHA1 is just fine. AH is for IPv6. (Ever had a look at them IPv6 IP header options?) Jörn From owner-ipsec@lists.tislabs.com Tue May 30 07:05:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06741; Tue, 30 May 2000 07:05:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA22182 Tue, 30 May 2000 08:40:53 -0400 (EDT) Message-ID: <393380B9.D22ED9A2@ccsr.cam.ac.uk> Date: Tue, 30 May 2000 09:50:01 +0100 From: Kanta Matsuura X-Mailer: Mozilla 4.6 [ja] (Win98; I) X-Accept-Language: ja MIME-Version: 1.0 To: "Scott G. Kelly" CC: David Chen , "Mr. Anderson" , ipsec@lists.tislabs.com Subject: Re: Is "Denial Of Service attack" a security issue? References: <4.2.0.58.20000525173612.00a33bf0@pop3.indusriver.com> <4.2.0.58.20000526101529.00a36310@pop3.indusriver.com> <392EA14F.72C69936@redcreek.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, if you're interested in CPU protection as well as memory protection from exhaustion, please have a look at http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-02.txt. Here's the abstract of the draft: Phase 1 of the Internet Key Exchange (IKE) [HC98] has several modes with different number of message passes. For those who want to save their bandwidth, three-pass Aggressive Mode is a good choice since it has minimal number of message passes in Phase 1. The public-key primitive method in Aggressive Mode provides significant security advantages over the other alternatives and should be the method of choice in many implementations. In this method, however, the responder must pay computational cost as expensive as modular exponentiation BEFORE identifying the initiator. This feature can be abused by malicious initiators for a Denial-of-Service (DoS) attack. The purpose of this document is to solve this problem in digital-signature method by using falling- together (FT) mechanism [MI98], [MI99] in conjunction with stateless-connection technique [AN97] and an appropriate use of Cookies [KS99]. -- Kanta -- "Scott G. Kelly" wrote: > David Chen wrote: > > > > Since the IPSec, especially IKE, is not DOS attack resistant, > > what is the IPSec security level try to achieve? > > Shall this been documented in the RFC for the scope/capability of > > security level? > > Or let user find out later? (ie. been attacked) > > --- David > > While there are DoS issues in IKE that may be remedied by modifications, > I think that a device which is capable of wireline-speed processing is > effectively immune to most of these. In the case where an attacker is > capable of saturating the medium with packets, there are other remedies. > > I think there was consensus in Adelaide that IKE could benefit from some > revisions, although it's not clear how much revision the AD's will > permit at this point. If you have specific suggestions for bolstering > IKE in terms of DoS attacks, I certainly would be interested in hearing > them. > > One such suggestion has already been documented in a draft (IKE base > mode). > > Scott -- ----^----^---- Kanta MATSUURA, Ph.D. Visiting Scholar Centre for Communications Systems Research University of Cambridge 10 Downing Street, Cambridge, CB2 3DS Tel: +44 1223 740107 From owner-ipsec@lists.tislabs.com Tue May 30 09:25:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11459; Tue, 30 May 2000 09:25:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22731 Tue, 30 May 2000 11:02:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4.3.1.2.20000529085323.00eba100@homebase.htt-consult.com> References: <4.3.1.2.20000529085323.00eba100@homebase.htt-consult.com> Date: Tue, 30 May 2000 11:04:53 -0400 To: Robert Moskowitz From: Stephen Kent Subject: Re: Reasons for AH & ESP Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bob, >At 11:39 AM 5/28/2000 +1000, KokMing wrote: > >>Does anyone know, or is able to explain the reasons for AH & ESP? >>As Neil Ferguson and Bruce Schneier wrote in 'Cryptographic Evaluation of >>IPsec', I too, find no reasons for two protocols in the RFCs. > >Part of it is Historical: > >1) Review RFCs 1825 - 1829. Then ESP did not do packet >authentication. For privacy and authentication, yoiu needed both AH >+ ESP. True, but when I started to rewrite the AH, ESP, and Ipsec architecture documents, the fact that the old ESP supported only encryption was not a influence on the new ESP. > >2) Early reworking of ESP, adding authentication (after the >Danver's IETF) did not have a mode with authentication and no >privacy. This only came about when I convinced Rob Glenn to write >the NULL transform draft at the IPsec workshop in Raleigh NC >(Workshop #5). I think you are trying to rewrite history here :-). As the ESP document editor, I introduced the notion of ESP as completely modular. This was debated on the list and later rejected by a group of developers at the St. Louis IETF, which I was unable to attend. So, I removed the text from the next draft of ESP. However, a few months later, the developers started to receive requests from perspective clients who wanted an authentication only ESP, and so ESP became modular again. As you may recall, I am the co-author of 2410, with Rob. That document was required only because the IKE developers did not want to change the payload definition for ESP, to allow either one or two algorithms. Hence the need for null encryption and null authentication algorithm definitions. But, since the IPsec architecture does not require IKE, this accommodation of IKE constraints was not essential to the modular definition of ESP. >During standards development, it was of greater concern to get >things right than to argue what to prune. There where some back >then, that valued AH over ESP NULL for export reasons, for example. Still a valid concern for U.S. hardware vendors today, despite the earlier comment. The relaxed export rules are most lenient towards mass market software. > >Then there is the IPv6 concern. AH DOES offer header protection for >IPv6 that ESP cannot provide. Correct. Steve From owner-ipsec@lists.tislabs.com Tue May 30 14:35:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19287; Tue, 30 May 2000 14:35:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24379 Tue, 30 May 2000 16:18:29 -0400 (EDT) From: "mouss" To: "Joern Sierwald" , Subject: RE: Reasons for AH & ESP Date: Tue, 30 May 2000 22:36:16 +0200 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <3.0.5.32.20000529125806.032d9e40@smtp.datafellows.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > [snip] > Well, if you look at IPv4 only, it doesn't make sense, agreed. > AH's main feature is that is protects parts of the > IP header. But in IPv4, there isn't anything interesting to > protect. > [snip] you are surpising me. Are yo trying to say that a host who signs his IPv4 header (thus his source address) using key that he negociated with mine, and that based on some external key negociation, which is not defined by AH but elsewhere, is the same as any spoofing host? I agree that AH relies on the security provided by the key negociation protocol. but then it's still good tohave AH while "controlling" and improving key ngociation. Fr example, AH is good if my negociatio daemon only accepts to talk to daemons having a certificate provided by some give authority. The why not use ESP here? ebecause I simply don't wanna pay the perf overhead when I don't need it. Moreover, from a design viewpoint, separating authentication and confidentiality is a self-justified purpose. regards, mouss From owner-ipsec@lists.tislabs.com Tue May 30 15:22:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20504; Tue, 30 May 2000 15:22:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24563 Tue, 30 May 2000 17:02:59 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14644.11877.963186.587329@xedia.com> Date: Tue, 30 May 2000 17:11:01 -0400 (EDT) To: ipntrq@free.fr Cc: joern.sierwald@F-Secure.com, ipsec@lists.tislabs.com Subject: RE: Reasons for AH & ESP References: <3.0.5.32.20000529125806.032d9e40@smtp.datafellows.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "mouss" == mouss writes: >> [snip] Well, if you look at IPv4 only, it doesn't make sense, >> agreed. AH's main feature is that is protects parts of the IP >> header. But in IPv4, there isn't anything interesting to protect. >> [snip] mouss> you are surpising me. Are yo trying to say that a host who mouss> signs his IPv4 header (thus his source address) using key that mouss> he negociated with mine, and that based on some external key mouss> negociation, which is not defined by AH but elsewhere, is the mouss> same as any spoofing host? I don't really understand what you're saying. In any case, ESP provides authentication just as AH does. There are slight differences, but all important data is protected in both cases. mouss> I agree that AH relies on the security provided by the key mouss> negociation protocol. but then it's still good tohave AH while mouss> "controlling" and improving key ngociation. Fr example, AH is mouss> good if my negociatio daemon only accepts to talk to daemons mouss> having a certificate provided by some give authority. The why mouss> not use ESP here? ebecause I simply don't wanna pay the perf mouss> overhead when I don't need it. What performance overhead? The header/trailer overhead is the same in both cases, and ESP in authentication-only mode has less CPU overhead than AH because it is significantly simpler. mouss> Moreover, from a design viewpoint, separating authentication mouss> and confidentiality is a self-justified purpose. Perhaps. But not at the cost of a lot of complexity. If AH were as simple as ESP authentication mode, I would agree with you, but it isn't -- not by a large margin. paul