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: <aboba@internaut.com>
From: "Bernard Aboba" <aboba@internaut.com>
To: "'Tylor Allison'" <allison@securecomputing.com>, <ietf-ipsra@vpnc.org>,
<ipsec@lists.tislabs.com>
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: <Pine.GSO.4.21.0004281557210.540-100000@stpsowk45.sctc.com>
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 <RuheenaR@future.futsoft.com>
Reply-To: "RuheenaR@future.futsoft.com" <RuheenaR@future.futsoft.com>
To: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>,
"ietf-pkix@imc.org"
<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 <niloo@cisco.com>
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" <john.shriver@intel.com>
To: "'Niloo Soleimani'" <niloo@cisco.com>, 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" <john.shriver@intel.com>
cc: "'Niloo Soleimani'" <niloo@cisco.com>, 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 <dharkins@network-alchemy.com>
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: <v0422080eb53772e5356b@[171.78.30.107]>
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 <niloo@cisco.com>
From: Stephen Kent <kent@bbn.com>
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: <v04220801b53883fbd1ae@[171.78.30.107]>
In-Reply-To:
<D104150098E6D111B7830000F8D90AE801A87031@exna02.securitydynamics.com>
References:
<D104150098E6D111B7830000F8D90AE801A87031@exna02.securitydynamics.com>
Date: Fri, 5 May 2000 09:58:59 -0400
To: "Kavsan, Bronislav" <bkavsan@rsasecurity.com>
From: Stephen Kent <kent@bbn.com>
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: <D104150098E6D111B7830000F8D90AE801A87031@exna02.securitydynamics.com>
From: "Kavsan, Bronislav" <bkavsan@rsasecurity.com>
To: "'Stephen Kent'" <kent@bbn.com>, Niloo Soleimani <niloo@cisco.com>
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 <TJenkins@CatenaNet.com>
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
<http://search.ietf.org/internet-drafts/draft-jenkins-ipsec-rekeying-06.txt>
.
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" <mark5@mediaone.net>
To: <ipsec@lists.tislabs.com>
References: <D104150098E6D111B7830000F8D90AE801A87031@exna02.securitydynamics.com> <v04220801b53883fbd1ae@[171.78.30.107]>
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" <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
>
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 <kent@bbn.com>
From: Niloo Soleimani <niloo@cisco.com>
Subject: RE: IPsec or IPSec?
Cc: "Kavsan, Bronislav" <bkavsan@rsasecurity.com>, ipsec@lists.tislabs.com
In-Reply-To: <v04220801b53883fbd1ae@[171.78.30.107]>
References: < <D104150098E6D111B7830000F8D90AE801A87031@exna02.securitydynamics.com>
<D104150098E6D111B7830000F8D90AE801A87031@exna02.securitydynamics.com>
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: <v04220817b538c56b3167@[171.78.30.107]>
In-Reply-To: <001101bfb6be$534474e0$fa811818@we.mediaone.net>
References:
<D104150098E6D111B7830000F8D90AE801A87031@exna02.securitydynamics.com>
<v04220801b53883fbd1ae@[171.78.30.107]>
<001101bfb6be$534474e0$fa811818@we.mediaone.net>
Date: Fri, 5 May 2000 14:39:33 -0400
To: "Mark" <mark5@mediaone.net>
From: Stephen Kent <kent@bbn.com>
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
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 <vilhuber@cisco.com>
To: ipsec@lists.tislabs.com
Subject: Re: IPsec or IPSec?
In-Reply-To: <001101bfb6be$534474e0$fa811818@we.mediaone.net>
Message-ID: <Pine.SOL.3.96.1000505114811.22997K-100000@jvilhube-ss20.cisco.com>
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" <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
> >
>
>
--
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" <pcn@cisco.com>
To: Dan Harkins <dharkins@network-alchemy.com>
cc: "Shriver, John" <john.shriver@intel.com>,
"'Niloo Soleimani'" <niloo@cisco.com>, ipsec@lists.tislabs.com,
smilley@cisco.com
Subject: Re: IPsec or IPSec?
In-Reply-To: <200005041929.MAA01170@potassium.network-alchemy.com>
Message-ID: <Pine.GSO.4.10.10005051152310.27340-100000@zipper.cisco.com>
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 <vilhuber@cisco.com>
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" <angelos@dsl.cis.upenn.edu>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <Pine.SOL.3.96.1000505114811.22997K-100000@jvilhube-ss20.cisco.com>,
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" <mark5@mediaone.net>
From: David Chen <dchen@indusriver.com>
Subject: Re: IPsec or IPSec?
Cc: ipsec@lists.tislabs.com
In-Reply-To: <001101bfb6be$534474e0$fa811818@we.mediaone.net>
References: <D104150098E6D111B7830000F8D90AE801A87031@exna02.securitydynamics.com>
<v04220801b53883fbd1ae@[171.78.30.107]>
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" <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
Content-Type: text/html; charset="us-ascii"
<html>
Mark,<br>
I vote for IPSec. It's simple.<br>
IPSec stands for <font color="#0000FF">I</font>nternetworking
<font color="#0000FF">P</font>rotocol
<font color="#0000FF">S</font>ecurity.<br>
IPsec stands for <font color="#0000FF">I</font>nternetworking
<font color="#0000FF">P</font>sec?<br>
<br>
Naming is very important for historian. :o)<br>
<br>
--- David<br>
<br>
At 11:18 AM 5/5/00 -0700, you wrote:<br>
<blockquote type=cite cite>I think this battle may already be lost.
It would appear that most<br>
commercial products and industry references use the spelling 'IPSec' -
the<br>
other variant seems to be rare...<br>
<br>
----- Original Message -----<br>
From: "Stephen Kent" <kent@bbn.com><br>
To: "Kavsan, Bronislav" <bkavsan@rsasecurity.com><br>
Cc: <ipsec@lists.tislabs.com><br>
Sent: Friday, May 05, 2000 6:58 AM<br>
Subject: RE: IPsec or IPSec?<br>
<br>
<br>
> At 9:41 AM -0400 5/5/00, Kavsan, Bronislav wrote:<br>
> >How come then - Dan Harkins, who co-authored some major RFCs
named his<br>
book<br>
> >"IPSec The New Security Standard...." and uses this
spelling throghout<br>
the<br>
> >book?<br>
> ><br>
> >(Just a little subliminal commercial for Dan :)<br>
> ><br>
><br>
> Typos happen :-)<br>
><br>
> Steve<br>
></blockquote></html>
--=====================_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" <john.shriver@intel.com>,
"'Niloo Soleimani'" <niloo@cisco.com>, ipsec@lists.tislabs.com
From: Robert Moskowitz <rgm-sec@htt-consult.com>
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: <jdunn@yipes.com>
From: "Jim Stephenson-Dunn" <jdunn@yipes.com>
To: "'Robert Moskowitz'" <rgm-sec@htt-consult.com>,
"'Shriver, John'" <john.shriver@intel.com>,
"'Niloo Soleimani'" <niloo@cisco.com>, <ipsec@lists.tislabs.com>
Cc: <smilley@cisco.com>
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" <s81331@cclinf.polito.it>
To: <ipsec@lists.tislabs.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.3800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Has anybody tried ISAKMP between =
W2000 and=20
Cisco routers?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have tried with pre-shared secret =
authentication=20
method:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>des-sha1 and des-md5 in main =
mode</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>des-esp , des-sha1 , des-md5 and ah in =
quick=20
mode</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>They successfully worked in main mode,=20
but they couldn't setup the IPsec SA in quick =
mode.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Andrea =
Schiavoni</FONT></DIV></BODY></HTML>
------=_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" <balenson@tislabs.com>
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 <pat@secureops.com>
To: "'Andrea Schiavoni'" <s81331@cclinf.polito.it>, 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"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.00.2314.1000" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=799300014-08052000>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.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=799300014-08052000></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=799300014-08052000></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=799300014-08052000>Regards,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=799300014-08052000></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=799300014-08052000>
<P><FONT face=Arial size=2>________________</FONT> <BR><FONT face=Arial
size=2>Patrick Ethier</FONT> <BR><FONT face=Arial size=2>Product
Development</FONT> <BR><FONT face=Arial size=2>SecureOps Inc.</FONT> <BR><FONT
face=Arial size=2>patrick@secureops.com</FONT> <BR><FONT face=Arial size=2>(514)
982-0678 x 106</FONT> <BR><FONT face=Arial size=2>(514) 982-0362 - fax</FONT>
</P></SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Andrea Schiavoni
[mailto:s81331@cclinf.polito.it]<BR><B>Sent:</B> Saturday, May 06, 2000 7:57
AM<BR><B>To:</B> ipsec@lists.tislabs.com<BR><B>Subject:</B> Windows 2000 and
Cicsco router interoperability<BR><BR></DIV></FONT>
<DIV><FONT face=Arial size=2>Has anybody tried ISAKMP between W2000 and
Cisco routers?</FONT></DIV>
<DIV><FONT face=Arial size=2>I have tried with pre-shared secret
authentication method:</FONT></DIV>
<DIV><FONT face=Arial size=2>des-sha1 and des-md5 in main mode</FONT></DIV>
<DIV><FONT face=Arial size=2>des-esp , des-sha1 , des-md5 and ah in quick
mode</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>They successfully worked in main mode,
but they couldn't setup the IPsec SA in quick mode.</FONT></DIV>
<DIV><FONT face=Arial size=2>Thanks</FONT></DIV>
<DIV><FONT face=Arial size=2>Andrea
Schiavoni</FONT></DIV></BLOCKQUOTE></BODY></HTML>
------_=_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 <pat@secureops.com>
cc: "'Andrea Schiavoni'" <s81331@cclinf.polito.it>, 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 <carney@securecomputing.com>
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"
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
>
>
> <META content="MSHTML 5.00.2314.1000" name=GENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=#ffffff>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=799300014-08052000>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.</SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN
> class=799300014-08052000></SPAN></FONT> </DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN
> class=799300014-08052000></SPAN></FONT> </DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN
> class=799300014-08052000>Regards,</SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN
> class=799300014-08052000></SPAN></FONT> </DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=799300014-08052000>
> <P><FONT face=Arial size=2>________________</FONT> <BR><FONT face=Arial
> size=2>Patrick Ethier</FONT> <BR><FONT face=Arial size=2>Product
> Development</FONT> <BR><FONT face=Arial size=2>SecureOps Inc.</FONT> <BR><FONT
> face=Arial size=2>patrick@secureops.com</FONT> <BR><FONT face=Arial size=2>(514)
> 982-0678 x 106</FONT> <BR><FONT face=Arial size=2>(514) 982-0362 - fax</FONT>
> </P></SPAN></FONT></DIV>
> <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
> <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
> size=2>-----Original Message-----<BR><B>From:</B> Andrea Schiavoni
> [mailto:s81331@cclinf.polito.it]<BR><B>Sent:</B> Saturday, May 06, 2000 7:57
> AM<BR><B>To:</B> ipsec@lists.tislabs.com<BR><B>Subject:</B> Windows 2000 and
> Cicsco router interoperability<BR><BR></DIV></FONT>
> <DIV><FONT face=Arial size=2>Has anybody tried ISAKMP between W2000 and
> Cisco routers?</FONT></DIV>
> <DIV><FONT face=Arial size=2>I have tried with pre-shared secret
> authentication method:</FONT></DIV>
> <DIV><FONT face=Arial size=2>des-sha1 and des-md5 in main mode</FONT></DIV>
> <DIV><FONT face=Arial size=2>des-esp , des-sha1 , des-md5 and ah in quick
> mode</FONT></DIV>
> <DIV> </DIV>
> <DIV><FONT face=Arial size=2>They successfully worked in main mode,
> but they couldn't setup the IPsec SA in quick mode.</FONT></DIV>
> <DIV><FONT face=Arial size=2>Thanks</FONT></DIV>
> <DIV><FONT face=Arial size=2>Andrea
> Schiavoni</FONT></DIV></BLOCKQUOTE></BODY></HTML>
>
> ------_=_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: <F142A45401DAD31191F0009027E326ED3D11D9@il06exm20.corp.mot.com>
From: Khurram Salman-ASK004 <S.Khurram@motorola.com>
To: "'Patrick Ethier'" <pat@secureops.com>,
"'Andrea Schiavoni'"
<s81331@cclinf.polito.it>,
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 <rfc-editor@ISI.EDU>, iana@iana.org
Cc: Internet Architecture Board <iab@ISI.EDU>
Cc: ipsec@lists.tislabs.com
From: The IESG <iesg-secretary@ietf.org>
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' <draft-ietf-ipsec-auth-hmac-ripemd-160-96-04.txt> 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: <vinod.porwal@ishoni.com>
From: "Vinod Porwal" <vinod.porwal@ishoni.com>
To: <ipsec@lists.tislabs.com>
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" <Philippe_Piemont@eur.3com.com>
To: Mike Carney <carney@securecomputing.com>
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" <nmdhara@broadpac.com>
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: IPsec mailing list <ipsec@lists.tislabs.com>
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 <HDR,SA> was not received by Y. Later Y sends a packet
containing <HDR, SA> 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" <cedarjak@webspan.net>
To: "N. Muralidhar" <nmdhara@broadpac.com>,
"IPsec mailing list" <ipsec@lists.tislabs.com>
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 <nmdhara@broadpac.com>
> To: IPsec mailing list <ipsec@lists.tislabs.com>
> 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 <HDR,SA> was not received by Y. Later Y sends a packet
> containing <HDR, SA> 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 <Jac.Kloots@surfnet.nl>
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 <carney@securecomputing.com>
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" <zamparelli@mclink.it>
To: "Philippe Piemont" <Philippe_Piemont@eur.3com.com>
Cc: <ipsec@lists.tislabs.com>
Subject: R: Windows 2000 and Cicsco router interoperability
Date: Wed, 10 May 2000 10:34:08 +0200
Message-ID: <KNEJIHNEOIGPDMHMEIKKAECACEAA.zamparelli@mclink.it>
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 <CTrobridge@baltimore.com>
To: Mike Carney <carney@securecomputing.com>
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 <Vipul.Gupta@Eng.Sun.COM>
Reply-To: Vipul Gupta <Vipul.Gupta@Eng.Sun.COM>
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" <nmdhara@broadpac.com>
> X-Accept-Language: en
> MIME-Version: 1.0
> To: IPsec mailing list <ipsec@lists.tislabs.com>
> 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 <HDR,SA> was not received by Y. Later Y sends a packet
> containing <HDR, SA> 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 <sami.vaarala@netseal.com>
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 <CTrobridge@baltimore.com>
cc: Mike Carney <carney@securecomputing.com>, 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 <carney@securecomputing.com>
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 <bmccann@indusriver.com>
MIME-Version: 1.0
To: Chris Trobridge <CTrobridge@baltimore.com>
CC: Mike Carney <carney@securecomputing.com>, 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 <sami.vaarala@netseal.com>
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 <bmccann@indusriver.com>
cc: Chris Trobridge <CTrobridge@baltimore.com>,
Mike Carney <carney@securecomputing.com>, 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 <dharkins@network-alchemy.com>
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 <bmccann@indusriver.com>
MIME-Version: 1.0
To: Dan Harkins <dharkins@network-alchemy.com>
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: <B58A778AE8E8D211B6C700805FE69B1A02594D0E@ex-nl-u1.vanenburg.com>
From: Michel de Koning <mdkoning@vanenburg.com>
To: "'Sami Vaarala'" <sami.vaarala@netseal.com>, 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: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Ben McCann" <bmccann@indusriver.com>,
"Dan Harkins" <dharkins@network-alchemy.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Windows 2000 and Cicsco router interoperability
Date: Wed, 10 May 2000 13:53:45 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPCEDGCEAA.gwz@cisco.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 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 <Michael Reilly" <michaelr@cisco.com>
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 <mdkoning@vanenburg.com>
Cc: "'Sami Vaarala'" <sami.vaarala@netseal.com>, 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: <B58A778AE8E8D211B6C700805FE69B1A02594D0E@ex-nl-u1.vanenburg.com>
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" <pcn@cisco.com>
To: Ben McCann <bmccann@indusriver.com>
cc: Dan Harkins <dharkins@network-alchemy.com>, ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
In-Reply-To: <3919983C.4DDC22B1@indusriver.com>
Message-ID: <Pine.GSO.4.10.10005101447140.2714-100000@irp-view5.cisco.com>
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 <bmccann@indusriver.com>
MIME-Version: 1.0
To: gwz@cisco.com
CC: ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <NDBBIHMPILAAGDHPCIOPCEDGCEAA.gwz@cisco.com>
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" <tytso@mit.edu>
To: <Black_David@emc.com>
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 <sami.vaarala@netseal.com>
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" <Stephen.Waters@cabletron.com>
To: Dan Harkins <dharkins@network-alchemy.com>
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: <B58A778AE8E8D211B6C700805FE69B1A02594D43@ex-nl-u1.vanenburg.com>
From: Michel de Koning <mdkoning@vanenburg.com>
To: "'Waters, Stephen'" <Stephen.Waters@cabletron.com>,
Dan Harkins
<dharkins@network-alchemy.com>
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: <D76D503DE976D1119C7E00A0C944D87501CA7F96@RSYS002A>
From: "Gallagher, Mick" <mick.gallagher@roke.co.uk>
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 <pkoning@xedia.com>
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 <Stephen.Waters@cabletron.com> 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 <pkoning@xedia.com>
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 <Franck.Le@nokia.com> 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 <dchen@indusriver.com>
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"
<html>
At 02:00 PM 5/10/00 -0500, you wrote:<br>
<blockquote type=cite cite>Hi,<br>
<br>
I have some questions on IKE.<br>
Actually I was wondering if in the Main Mode, protection against man in
the<br>
middle attacks is provided.</blockquote><br>
<font color="#0000FF">The countermeasure of MIM attack is authenticate
the peer. (and off course mutually)<br>
The third pair of message will take care of this.<br>
<br>
<br>
</font><blockquote type=cite cite>Since the first messages are sent in
clear mode and without any<br>
authentication, can't a Bad Guy modify for example the SA payload ? That
can<br>
bring to a denial of service.</blockquote><br>
<font color="#0000FF">The countermeasure of DOS is demanding the equal or
larger amount of resources<br>
that attacker has to consume than the attacked.<br>
The DH key exchange in IKE requires the peers equally (if the
implementation is correct)<br>
consumes resources. <br>
<br>
</font><blockquote type=cite cite>So if it the case, is there a way to
protect against man in the middle<br>
attacks ?</blockquote><br>
I<font color="#0000FF">t is the issues of "talk first" or
"authentication first".<br>
The main mode's first and second pair of messages is "talk
first" - to establish <br>
secured comm. channel between two peers.<br>
The the pair messages is for authentication.<br>
<br>
We may ask why it is done this way???? :-)<br>
<br>
</font><blockquote type=cite cite>Thanking you in advance for your
help.<br>
<br>
Franck LE</blockquote><br>
--- David<br>
</html>
--=====================_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 <henry@spsystems.net>
To: IP Security List <ipsec@lists.tislabs.com>
Subject: Re: IKE
In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B0124D303@daeis07nok>
Message-ID: <Pine.BSI.3.91.1000511103337.1578F-100000@spsystems.net>
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" <Stephen.Waters@cabletron.com>
To: Paul Koning <pkoning@xedia.com>
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 <Stephen.Waters@cabletron.com> 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?= <beldi_o@yahoo.fr>
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]" <erik.mintz@ssmb.com>
To: ipsec@lists.tislabs.com, "'beldi olivier'" <beldi_o@yahoo.fr>
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: <v04220804b540d25d02f3@[171.78.30.107]>
In-Reply-To: <Pine.GSO.4.10.10005101447140.2714-100000@irp-view5.cisco.com>
References: <Pine.GSO.4.10.10005101447140.2714-100000@irp-view5.cisco.com>
Date: Thu, 11 May 2000 17:14:44 -0400
To: "CHINNA N.R. PELLACURU" <pcn@cisco.com>
From: Stephen Kent <kent@bbn.com>
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" <RobB@lockstream.com>
To: "beldi olivier" <beldi_o@yahoo.fr>, <ipsec@lists.tislabs.com>
Subject: RE: about compliance
Date: Thu, 11 May 2000 15:53:01 -0700
Message-ID: <NEBBIKOFNKCIADHICGPAAEBGCAAA.RobB@lockstream.com>
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" <pcn@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
In-Reply-To: <v04220804b540d25d02f3@[171.78.30.107]>
Message-ID: <Pine.GSO.4.10.10005111539080.27943-100000@zipper.cisco.com>
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" <Stephen.Waters@cabletron.com>
To: Stephen Kent <kent@bbn.com>
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 <wprice@cyphers.net>
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 <sami.vaarala@netseal.com>
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" <pcn@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
In-Reply-To: <Pine.GSO.4.10.10005111539080.27943-100000@zipper.cisco.com>
Message-ID: <Pine.GSO.4.10.10005111702010.26624-100000@zipper.cisco.com>
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 <wprice@cyphers.net>
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" <pcn@cisco.com>
CC: Stephen Kent <kent@bbn.com>, ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <Pine.GSO.4.10.10005111539080.27943-100000@zipper.cisco.com>
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" <pcn@cisco.com>
To: Will Price <wprice@cyphers.net>
cc: Stephen Kent <kent@bbn.com>, ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
In-Reply-To: <391B4B7D.8A9C460F@cyphers.net>
Message-ID: <Pine.GSO.4.10.10005111746280.465-100000@zipper.cisco.com>
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" <pcn@cisco.com>
To: Will Price <wprice@cyphers.net>
cc: Stephen Kent <kent@bbn.com>, ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
In-Reply-To: <Pine.GSO.4.10.10005111746280.465-100000@zipper.cisco.com>
Message-ID: <Pine.GSO.4.10.10005111902280.3108-100000@zipper.cisco.com>
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 <vilhuber@cisco.com>
To: "CHINNA N.R. PELLACURU" <pcn@cisco.com>
cc: Will Price <wprice@cyphers.net>, Stephen Kent <kent@bbn.com>,
ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
In-Reply-To: <Pine.GSO.4.10.10005111902280.3108-100000@zipper.cisco.com>
Message-ID: <Pine.SOL.3.96.1000511192939.17260H-100000@jvilhube-ss20.cisco.com>
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" <pcn@cisco.com>
To: Jan Vilhuber <vilhuber@cisco.com>
cc: Will Price <wprice@cyphers.net>, Stephen Kent <kent@bbn.com>,
ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
In-Reply-To: <Pine.SOL.3.96.1000511192939.17260H-100000@jvilhube-ss20.cisco.com>
Message-ID: <Pine.GSO.4.10.10005111933360.4001-100000@zipper.cisco.com>
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" <pcn@cisco.com>
To: Jan Vilhuber <vilhuber@cisco.com>
cc: Will Price <wprice@cyphers.net>, Stephen Kent <kent@bbn.com>,
ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
In-Reply-To: <Pine.GSO.4.10.10005111933360.4001-100000@zipper.cisco.com>
Message-ID: <Pine.GSO.4.10.10005111938420.4001-100000@zipper.cisco.com>
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 <fd@cisco.com>
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 <sami.vaarala@netseal.com>, 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" <skshirsa@nortelnetworks.com>
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"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.65">
<TITLE>RE: Windows 2000 and Cicsco router interoperability</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>I can understand the waste of bandwidth by L2TP.</FONT>
<BR><FONT SIZE=2>But, can you please elaborate more on how does L2TP interfere </FONT>
<BR><FONT SIZE=2>with the access controls?</FONT>
</P>
<P><FONT SIZE=2>Thanks,</FONT>
<BR><FONT SIZE=2>Shekhar</FONT>
</P>
<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Stephen Kent [<A HREF="mailto:kent@bbn.com">mailto:kent@bbn.com</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Thursday, May 11, 2000 5:15 PM</FONT>
<BR><FONT SIZE=2>> To: CHINNA N.R. PELLACURU</FONT>
<BR><FONT SIZE=2>> Cc: ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=2>> Subject: Re: Windows 2000 and Cicsco router interoperability</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> At 2:54 PM -0700 5/10/00, CHINNA N.R. PELLACURU wrote:</FONT>
<BR><FONT SIZE=2>> >I can't speak for the whole of Cisco, but the way I look at it is:</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> >Modeconfig/Xauth are being supported as quick hack to get </FONT>
<BR><FONT SIZE=2>> something to</FONT>
<BR><FONT SIZE=2>> >work, and get something to customers, until there is a </FONT>
<BR><FONT SIZE=2>> client that can do</FONT>
<BR><FONT SIZE=2>> >IPSec and L2TP.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> >I beleive that it is not our long term vision, to ship </FONT>
<BR><FONT SIZE=2>> Modeconfig/Xauth. I</FONT>
<BR><FONT SIZE=2>> >beleive that Cisco's long term goal is to follow whatever is </FONT>
<BR><FONT SIZE=2>> standardized</FONT>
<BR><FONT SIZE=2>> >in the IPSRA WG, because that's what IPSRA WG is chartered to solve.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> That's one view.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Another perspective is that L2TP over IPsec represents an effort by </FONT>
<BR><FONT SIZE=2>> Microsoft & Cisco to preserve a joint development investment in L2TP, </FONT>
<BR><FONT SIZE=2>> irrespective of its technical merit in this context :-). If I am </FONT>
<BR><FONT SIZE=2>> sending non-IP packets, L2TP is appropriate, but if I am sending IP, </FONT>
<BR><FONT SIZE=2>> then the extra headers introduced by L2TP are not only wasteful of </FONT>
<BR><FONT SIZE=2>> bandwidth on a continuing basis, but they also interfere with the </FONT>
<BR><FONT SIZE=2>> access controls that are an essential part of IPsec. One needs some </FONT>
<BR><FONT SIZE=2>> means of dealing with bind time connection parameters, but use of </FONT>
<BR><FONT SIZE=2>> L2TP on a continuing basis is an expensive means of achieving this </FONT>
<BR><FONT SIZE=2>> goal.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Steve</FONT>
</P>
</BODY>
</HTML>
------_=_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" <uri.elzur@intel.com>
To: Fabio Zamparelli <zamparelli@mclink.it>,
Philippe Piemont
<Philippe_Piemont@eur.3com.com>
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" <David_Mason@nai.com>
To: "'CHINNA N.R. PELLACURU'" <pcn@cisco.com>,
Will Price
<wprice@cyphers.net>
Cc: Stephen Kent <kent@bbn.com>, 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: <v04220801b541c01bf08d@[171.78.30.107]>
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" <skshirsa@nortelnetworks.com>
From: Stephen Kent <kent@bbn.com>
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" <pcn@cisco.com>
To: "Mason, David" <David_Mason@nai.com>
cc: Will Price <wprice@cyphers.net>, Stephen Kent <kent@bbn.com>,
ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <447A3F40A07FD211BA2700A0C99D759B78905C@md-exchange1.nai.com>
Message-ID: <Pine.GSO.4.10.10005120810420.25364-100000@zipper.cisco.com>
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" <sumis@Exchange.Microsoft.com>
To: <fd@cisco.com>, <wprice@cyphers.net>
Cc: "Sami Vaarala" <sami.vaarala@netseal.com>, <ipsec@lists.tislabs.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4366.0">
<TITLE>RE: Win2000 IKE and 3des</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>Just to clarify the behaviour of Windows 2000 - =
</FONT>
<BR><FONT SIZE=3D2>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. </FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>For dometic versions you can install the strong crypto =
pack for doing 3DES from <A =
HREF=3D"http://www.microsoft.com/windows2000/downloads/recommended/encryp=
tion/default.asp">http://www.microsoft.com/windows2000/downloads/recommen=
ded/encryption/default.asp</A></FONT></P>
<P><FONT SIZE=3D2>Sumi.</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Fr=E9d=E9ric Detienne [<A =
HREF=3D"mailto:fd@cisco.com">mailto:fd@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 12, 2000 12:56 AM</FONT>
<BR><FONT SIZE=3D2>To: wprice@cyphers.net</FONT>
<BR><FONT SIZE=3D2>Cc: Sami Vaarala; ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Win2000 IKE and 3des</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>I fully agree.</FONT>
</P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>I noticed the issue when negociating against a Cisco =
router.</FONT>
</P>
<P><FONT SIZE=3D2>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 ?).</FONT></P>
<P> <FONT SIZE=3D2>fred</FONT>
</P>
<P><FONT SIZE=3D2>Will Price wrote:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> This sounds fairly serious to me.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Perhaps this should be posted to BugTraq. =
This needs confirmation. I</FONT>
<BR><FONT SIZE=3D2>> thought I saw something like this when I was =
doing my tests against Win2K,</FONT>
<BR><FONT SIZE=3D2>> but it's been quite some time since then.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Sami Vaarala wrote:</FONT>
<BR><FONT SIZE=3D2>> > >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?</FONT></P>
<P><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > Yes, that seems to be the case. I =
have only checked that if I configure</FONT>
<BR><FONT SIZE=3D2>> > 3des, it will send des as an initiator, and =
a phase 1 SA with des will</FONT>
<BR><FONT SIZE=3D2>> > be formed (if the remote end accepts =
des). Haven't checked if it works</FONT>
<BR><FONT SIZE=3D2>> > this way as a responder; probably =
will.</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > >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?</FONT></P>
<P><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > No. This would be the correct way to =
function, and there would not be</FONT>
<BR><FONT SIZE=3D2>> > an issue if this were the case.</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > >The former is a bug which I've not seen =
in Windows 2000. The latter is</FONT>
<BR><FONT SIZE=3D2>> > >expected behavior since you configured =
it to do so.</FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > My point exactly. The latter behavior =
would be the one I would prefer</FONT>
<BR><FONT SIZE=3D2>> > to see, of course.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> --</FONT>
<BR><FONT SIZE=3D2>> Will Price, Director of Engineering</FONT>
<BR><FONT SIZE=3D2>> PGP Security, Inc.</FONT>
<BR><FONT SIZE=3D2>> a division of Network Associates, Inc.</FONT>
</P>
</BODY>
</HTML>
------_=_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 <pkoning@xedia.com>
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 <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
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" <jamesw@us.checkpoint.com>
To: "'Mason, David'" <David_Mason@nai.com>,
"'CHINNA N.R. PELLACURU'" <pcn@cisco.com>,
"'Will Price'" <wprice@cyphers.net>
Cc: "'Stephen Kent'" <kent@bbn.com>, <ipsec@lists.tislabs.com>
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 <pkoning@xedia.com>
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 <chunye@Exchange.Microsoft.com> 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" <chunye@Exchange.Microsoft.com>
To: "Paul Koning" <pkoning@xedia.com>,
"Sumi Singh" <sumis@Exchange.Microsoft.com>
Cc: <ipsec@lists.tislabs.com>
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 <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
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4366.0">
<TITLE>RE: Win2000 IKE and 3des</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>This is not a design error. If you have an =
export driver, how can you expect to run 3DES?</FONT>
</P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>Having said that, the report mechanism should probably =
be improved and we will address this in the next release. </FONT>
</P>
<P><FONT SIZE=3D2>--Chun</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Paul Koning [<A =
HREF=3D"mailto:pkoning@xedia.com">mailto:pkoning@xedia.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 12, 2000 1:24 PM</FONT>
<BR><FONT SIZE=3D2>To: Sumi Singh</FONT>
<BR><FONT SIZE=3D2>Cc: ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Win2000 IKE and 3des</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>>>>>> "Sumi" =3D=3D Sumi =
Singh <sumis@Exchange.Microsoft.com> writes:</FONT>
</P>
<P><FONT SIZE=3D2> Sumi> Just to clarify the behaviour of =
Windows 2000 - Windows 2000</FONT>
<BR><FONT SIZE=3D2> Sumi> weakens 3DES policy to DES if you do =
not have the strong</FONT>
<BR><FONT SIZE=3D2> Sumi> encryption pack (128-bit) installed. =
This weakening is</FONT>
<BR><FONT SIZE=3D2> Sumi> announced by an event in the Audit =
log. So if you have 2 peers</FONT>
<BR><FONT SIZE=3D2> Sumi> with no encryption pack installed, and =
a policy to use 3DES,</FONT>
<BR><FONT SIZE=3D2> Sumi> they will talk DES since they cannot =
do 3DES.</FONT>
</P>
<P><FONT SIZE=3D2>Clearly that's a major design error.</FONT>
</P>
<P><FONT SIZE=3D2>If you ask for something that's not supported, it =
should be rejected.</FONT>
<BR><FONT SIZE=3D2>To change it (even with a message in some obscure =
log) is clearly</FONT>
<BR><FONT SIZE=3D2>wrong. You don't build secure systems that =
way.</FONT>
</P>
<P> <FONT SIZE=3D2>paul</FONT>
</P>
</BODY>
</HTML>
------_=_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" <michaelr@cisco.com>
To: "Paul Koning" <pkoning@xedia.com>, <chunye@Exchange.Microsoft.com>
Cc: <sumis@Exchange.Microsoft.com>, <ipsec@lists.tislabs.com>
Subject: RE: Win2000 IKE and 3des
Date: Fri, 12 May 2000 16:03:44 -0700
Message-ID: <NDBBILGMDJCMOAOEPNBEIEPEDCAA.michaelr@cisco.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 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" <chunye@Exchange.Microsoft.com>
To: "Michael Reilly" <michaelr@cisco.com>, "Paul Koning" <pkoning@xedia.com>
Cc: "Sumi Singh" <sumis@Exchange.Microsoft.com>, <ipsec@lists.tislabs.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4366.0">
<TITLE>RE: Win2000 IKE and 3des</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>Yes this will be fixed.</FONT>
</P>
<P><FONT SIZE=3D2>--Chun</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Michael Reilly [<A =
HREF=3D"mailto:michaelr@cisco.com">mailto:michaelr@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 12, 2000 4:04 PM</FONT>
<BR><FONT SIZE=3D2>To: Paul Koning; Chun Ye</FONT>
<BR><FONT SIZE=3D2>Cc: Sumi Singh; ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Win2000 IKE and 3des</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>>>It should never do something less =
secure</FONT>
<BR><FONT SIZE=3D2>>>than what it was told to do. Doing so =
is a major design error.</FONT>
<BR><FONT SIZE=3D2>>>Nothing less.</FONT>
</P>
<P><FONT SIZE=3D2>Paul is obviously correct. Therefore does anyone =
know of a third party</FONT>
<BR><FONT SIZE=3D2>package for Windows 2000 similar to the ones for NT =
4.0 which does provide</FONT>
<BR><FONT SIZE=3D2>the security it is configured to provide without =
going behind your back to</FONT>
<BR><FONT SIZE=3D2>reduce security (hiding a message in an obscure =
logfile is not acceptable)?</FONT>
</P>
<P><FONT SIZE=3D2>Any chance of a fix from Microsoft?</FONT>
</P>
<P><FONT SIZE=3D2>michael</FONT>
</P>
</BODY>
</HTML>
------_=_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 <sandy@storm.ca>
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Chun Ye <chunye@Exchange.Microsoft.com>
CC: Sumi Singh <sumis@Exchange.Microsoft.com>, 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 <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.
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 <vilhuber@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: Shekhar Kshirsagar <skshirsa@nortelnetworks.com>, ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <v04220801b541c01bf08d@[171.78.30.107]>
Message-ID: <Pine.SOL.3.96.1000512235823.20735Q-100000@jvilhube-ss20.cisco.com>
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 <vilhuber@cisco.com>
To: Sandy Harris <sandy@storm.ca>
cc: Chun Ye <chunye@Exchange.Microsoft.com>,
Sumi Singh <sumis@Exchange.Microsoft.com>, ipsec@lists.tislabs.com
Subject: Re: Win2000 IKE and 3des
In-Reply-To: <391CA973.8D2BD1BE@storm.ca>
Message-ID: <Pine.SOL.3.96.1000512235627.20735P-100000@jvilhube-ss20.cisco.com>
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 <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.
>
> 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 <fd@cisco.com>
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 <sumis@Exchange.Microsoft.com>
CC: wprice@cyphers.net, Sami Vaarala <sami.vaarala@netseal.com>,
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" <chunye@Exchange.Microsoft.com>
cc: "Paul Koning" <pkoning@xedia.com>,
"Sumi Singh" <sumis@Exchange.Microsoft.com>, 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 <dharkins@network-alchemy.com>
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 <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
> Content-Type: text/html;
> charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dus-ascii">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 6.0.4366.0">
> <TITLE>RE: Win2000 IKE and 3des</TITLE>
> </HEAD>
> <BODY>
> <!-- Converted from text/plain format -->
>
> <P><FONT SIZE=3D2>This is not a design error. If you have an =
> export driver, how can you expect to run 3DES?</FONT>
> </P>
>
> <P><FONT SIZE=3D2>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.</FONT></P>
>
> <P><FONT SIZE=3D2>Having said that, the report mechanism should probably =
> be improved and we will address this in the next release. </FONT>
> </P>
>
> <P><FONT SIZE=3D2>--Chun</FONT>
> </P>
>
> <P><FONT SIZE=3D2>-----Original Message-----</FONT>
>
> <BR><FONT SIZE=3D2>From: Paul Koning [<A =
> HREF=3D"mailto:pkoning@xedia.com">mailto:pkoning@xedia.com</A>]</FONT>
>
> <BR><FONT SIZE=3D2>Sent: Friday, May 12, 2000 1:24 PM</FONT>
>
> <BR><FONT SIZE=3D2>To: Sumi Singh</FONT>
>
> <BR><FONT SIZE=3D2>Cc: ipsec@lists.tislabs.com</FONT>
>
> <BR><FONT SIZE=3D2>Subject: RE: Win2000 IKE and 3des</FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=3D2>>>>>> "Sumi" =3D=3D Sumi =
> Singh <sumis@Exchange.Microsoft.com> writes:</FONT>
> </P>
>
> <P><FONT SIZE=3D2> Sumi> Just to clarify the behaviour of =
> Windows 2000 - Windows 2000</FONT>
>
> <BR><FONT SIZE=3D2> Sumi> weakens 3DES policy to DES if you do =
> not have the strong</FONT>
>
> <BR><FONT SIZE=3D2> Sumi> encryption pack (128-bit) installed. =
> This weakening is</FONT>
>
> <BR><FONT SIZE=3D2> Sumi> announced by an event in the Audit =
> log. So if you have 2 peers</FONT>
>
> <BR><FONT SIZE=3D2> Sumi> with no encryption pack installed, and =
> a policy to use 3DES,</FONT>
>
> <BR><FONT SIZE=3D2> Sumi> they will talk DES since they cannot =
> do 3DES.</FONT>
> </P>
>
> <P><FONT SIZE=3D2>Clearly that's a major design error.</FONT>
> </P>
>
> <P><FONT SIZE=3D2>If you ask for something that's not supported, it =
> should be rejected.</FONT>
>
> <BR><FONT SIZE=3D2>To change it (even with a message in some obscure =
> log) is clearly</FONT>
>
> <BR><FONT SIZE=3D2>wrong. You don't build secure systems that =
> way.</FONT>
> </P>
>
> <P> <FONT SIZE=3D2>paul</FONT>
> </P>
>
> </BODY>
> </HTML>
> ------_=_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: <v04220800b54476839d25@[171.78.30.108]>
In-Reply-To:
<Pine.SOL.3.96.1000512235823.20735Q-100000@jvilhube-ss20.cisco.com>
References:
<Pine.SOL.3.96.1000512235823.20735Q-100000@jvilhube-ss20.cisco.com>
Date: Sun, 14 May 2000 11:30:18 -0400
To: Jan Vilhuber <vilhuber@cisco.com>
From: Stephen Kent <kent@bbn.com>
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 <vilhuber@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <v04220800b54476839d25@[171.78.30.108]>
Message-ID: <Pine.SOL.3.96.1000514113714.24176A-100000@jvilhube-ss20.cisco.com>
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" <smb@research.att.com>
To: Paul Koning <pkoning@xedia.com>
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 <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.
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" <smb@research.att.com>
To: "CHINNA N.R. PELLACURU" <pcn@cisco.com>
Cc: Jan Vilhuber <vilhuber@cisco.com>, Will Price <wprice@cyphers.net>,
Stephen Kent <kent@bbn.com>, 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 <Pine.GSO.4.10.10005111938420.4001-100000@zipper.cisco.com>, "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 <Ari.Huttunen@F-Secure.com>
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" <pcn@cisco.com>
CC: "Mason, David" <David_Mason@nai.com>, Will Price <wprice@cyphers.net>,
Stephen Kent <kent@bbn.com>, ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <Pine.GSO.4.10.10005120810420.25364-100000@zipper.cisco.com>
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 <qiuying@krdl.org.sg>
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 <qiuying@krdl.org.sg>
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" <Stephen.Waters@cabletron.com>
To: Ari Huttunen <Ari.Huttunen@F-Secure.com>
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" <pcn@cisco.com>
cc: "Mason, David" <David_Mason@nai.com>, Will Price <wprice@cyphers.net>,
Stephen Kent <kent@bbn.com>, 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."
<Pine.GSO.4.10.10005120810420.25364-100000@zipper.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 15 May 2000 09:24:19 -0500
From: Mike Carney <carney@securecomputing.com>
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" <chunye@Exchange.Microsoft.com>
cc: "Paul Koning" <pkoning@xedia.com>,
"Sumi Singh" <sumis@Exchange.Microsoft.com>, 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 <carney@securecomputing.com>
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 <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
> Content-Type: text/html;
> charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dus-ascii">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 6.0.4366.0">
> <TITLE>RE: Win2000 IKE and 3des</TITLE>
> </HEAD>
> <BODY>
> <!-- Converted from text/plain format -->
>
> <P><FONT SIZE=3D2>This is not a design error. If you have an =
> export driver, how can you expect to run 3DES?</FONT>
> </P>
>
> <P><FONT SIZE=3D2>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.</FONT></P>
>
> <P><FONT SIZE=3D2>Having said that, the report mechanism should probably =
> be improved and we will address this in the next release. </FONT>
> </P>
>
> <P><FONT SIZE=3D2>--Chun</FONT>
> </P>
>
> <P><FONT SIZE=3D2>-----Original Message-----</FONT>
>
> <BR><FONT SIZE=3D2>From: Paul Koning [<A =
> HREF=3D"mailto:pkoning@xedia.com">mailto:pkoning@xedia.com</A>]</FONT>
>
> <BR><FONT SIZE=3D2>Sent: Friday, May 12, 2000 1:24 PM</FONT>
>
> <BR><FONT SIZE=3D2>To: Sumi Singh</FONT>
>
> <BR><FONT SIZE=3D2>Cc: ipsec@lists.tislabs.com</FONT>
>
> <BR><FONT SIZE=3D2>Subject: RE: Win2000 IKE and 3des</FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=3D2>>>>>> "Sumi" =3D=3D Sumi =
> Singh <sumis@Exchange.Microsoft.com> writes:</FONT>
> </P>
>
> <P><FONT SIZE=3D2> Sumi> Just to clarify the behaviour of =
> Windows 2000 - Windows 2000</FONT>
>
> <BR><FONT SIZE=3D2> Sumi> weakens 3DES policy to DES if you do =
> not have the strong</FONT>
>
> <BR><FONT SIZE=3D2> Sumi> encryption pack (128-bit) installed. =
> This weakening is</FONT>
>
> <BR><FONT SIZE=3D2> Sumi> announced by an event in the Audit =
> log. So if you have 2 peers</FONT>
>
> <BR><FONT SIZE=3D2> Sumi> with no encryption pack installed, and =
> a policy to use 3DES,</FONT>
>
> <BR><FONT SIZE=3D2> Sumi> they will talk DES since they cannot =
> do 3DES.</FONT>
> </P>
>
> <P><FONT SIZE=3D2>Clearly that's a major design error.</FONT>
> </P>
>
> <P><FONT SIZE=3D2>If you ask for something that's not supported, it =
> should be rejected.</FONT>
>
> <BR><FONT SIZE=3D2>To change it (even with a message in some obscure =
> log) is clearly</FONT>
>
> <BR><FONT SIZE=3D2>wrong. You don't build secure systems that =
> way.</FONT>
> </P>
>
> <P> <FONT SIZE=3D2>paul</FONT>
> </P>
>
> </BODY>
> </HTML>
> ------_=_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" <wprice@cyphers.net>
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 <carney@securecomputing.com>
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 <carney@securecomputing.com>, 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 <carney@securecomputing.com>
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: <akrywani@newbridge.com>
From: "Andrew Krywaniuk" <akrywani@newbridge.com>
To: "'Jan Vilhuber'" <vilhuber@cisco.com>, "'Stephen Kent'" <kent@bbn.com>
Cc: <ipsec@lists.tislabs.com>
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: <Pine.SOL.3.96.1000514113714.24176A-100000@jvilhube-ss20.cisco.com>
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" <skelly@redcreek.com>
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 <qiuying@krdl.org.sg>
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" <pcn@cisco.com>
To: Ari Huttunen <Ari.Huttunen@F-Secure.com>
cc: "Mason, David" <David_Mason@nai.com>, Will Price <wprice@cyphers.net>,
Stephen Kent <kent@bbn.com>, ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
In-Reply-To: <391FB997.4CCE5446@F-Secure.com>
Message-ID: <Pine.GSO.4.10.10005150926510.2352-100000@zipper.cisco.com>
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 <vilhuber@cisco.com>
To: Andrew Krywaniuk <akrywani@newbridge.com>
cc: "'Stephen Kent'" <kent@bbn.com>, ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <000b01bfbe88$2fa49c50$d23e788a@andrewk3.timestep.com>
Message-ID: <Pine.SOL.3.96.1000515100727.26017B-100000@jvilhube-ss20.cisco.com>
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" <pcn@cisco.com>
To: Andrew Krywaniuk <akrywani@newbridge.com>
cc: "'Jan Vilhuber'" <vilhuber@cisco.com>, "'Stephen Kent'" <kent@bbn.com>,
ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <000b01bfbe88$2fa49c50$d23e788a@andrewk3.timestep.com>
Message-ID: <Pine.GSO.4.10.10005151119140.2352-100000@zipper.cisco.com>
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 <declan@wired.com>
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" <wdixon@Exchange.Microsoft.com>
To: "Mike Carney" <carney@securecomputing.com>,
"Chun Ye" <chunye@Exchange.Microsoft.com>
Cc: "Paul Koning" <pkoning@xedia.com>,
"Sumi Singh" <sumis@Exchange.Microsoft.com>, <ipsec@lists.tislabs.com>,
<carney@jumpsrv.stp.securecomputing.com>
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 <sumis@Exchange.Microsoft.com> =
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
> <!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 -->
>=20
> <P><FONT SIZE=3D3D2>This is not a design error. If you have an =
=3D
> export driver, how can you expect to run 3DES?</FONT>
> </P>
>=20
> <P><FONT SIZE=3D3D2>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.</FONT></P>
>=20
> <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>
>=20
> <P><FONT SIZE=3D3D2>--Chun</FONT>
> </P>
>=20
> <P><FONT SIZE=3D3D2>-----Original Message-----</FONT>
>=20
> <BR><FONT SIZE=3D3D2>From: Paul Koning [<A =3D
> =
HREF=3D3D"mailto:pkoning@xedia.com">mailto:pkoning@xedia.com</A>]</FONT>
>=20
> <BR><FONT SIZE=3D3D2>Sent: Friday, May 12, 2000 1:24 PM</FONT>
>=20
> <BR><FONT SIZE=3D3D2>To: Sumi Singh</FONT>
>=20
> <BR><FONT SIZE=3D3D2>Cc: ipsec@lists.tislabs.com</FONT>
>=20
> <BR><FONT SIZE=3D3D2>Subject: RE: Win2000 IKE and 3des</FONT>
> </P>
> <BR>
>=20
> <P><FONT SIZE=3D3D2>>>>>> "Sumi" =3D3D=3D3D =
Sumi =3D
> Singh <sumis@Exchange.Microsoft.com> writes:</FONT>
> </P>
>=20
> <P><FONT SIZE=3D3D2> Sumi> Just to clarify the behaviour of =
=3D
> Windows 2000 - Windows 2000</FONT>
>=20
> <BR><FONT SIZE=3D3D2> Sumi> weakens 3DES policy to DES if you =
do
=3D
> not have the strong</FONT>
>=20
> <BR><FONT SIZE=3D3D2> Sumi> encryption pack (128-bit) =
installed.
=3D
> This weakening is</FONT>
>=20
> <BR><FONT SIZE=3D3D2> Sumi> announced by an event in the Audit =
=3D
> log. So if you have 2 peers</FONT>
>=20
> <BR><FONT SIZE=3D3D2> Sumi> with no encryption pack installed,
and =3D
> a policy to use 3DES,</FONT>
>=20
> <BR><FONT SIZE=3D3D2> Sumi> they will talk DES since they =
cannot
=3D
> do 3DES.</FONT>
> </P>
>=20
> <P><FONT SIZE=3D3D2>Clearly that's a major design error.</FONT>
> </P>
>=20
> <P><FONT SIZE=3D3D2>If you ask for something that's not supported, it =
=3D
> should be rejected.</FONT>
>=20
> <BR><FONT SIZE=3D3D2>To change it (even with a message in some obscure =
=3D
> log) is clearly</FONT>
>=20
> <BR><FONT SIZE=3D3D2>wrong. You don't build secure systems that =
=3D
> way.</FONT>
> </P>
>=20
> <P> <FONT
SIZE=3D3D2>paul</FONT>
> </P>
>=20
> </BODY>
> </HTML>
> ------_=3D_NextPart_001_01BFBC55.58D2F2C8--
------_=_NextPart_001_01BFBE9E.AEC7A836
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4366.0">
<TITLE>RE: Win2000 IKE and 3des </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>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. </FONT></P>
<P><FONT SIZE=3D2>Wm</FONT>
<BR><FONT SIZE=3D2>William Dixon</FONT>
<BR><FONT SIZE=3D2>Program Manager - Internet Protocol Security</FONT>
<BR><FONT SIZE=3D2>Windows Operating Systems Division</FONT>
<BR><FONT SIZE=3D2>Microsoft Corporation</FONT>
<BR><FONT SIZE=3D2>One Microsoft Way</FONT>
<BR><FONT SIZE=3D2>Redmond, WA 98052-6399</FONT>
<BR><FONT SIZE=3D2>Email: WDixon@microsoft.com (preferred), Work: =
425-703-8729</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mike Carney [<A =
HREF=3D"mailto:carney@securecomputing.com">mailto:carney@securecomputing.=
com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, May 15, 2000 7:32 AM</FONT>
<BR><FONT SIZE=3D2>To: Chun Ye</FONT>
<BR><FONT SIZE=3D2>Cc: Paul Koning; Sumi Singh; =
ipsec@lists.tislabs.com;</FONT>
<BR><FONT SIZE=3D2>carney@jumpsrv.stp.securecomputing.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Win2000 IKE and 3des </FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=3D2>> This is not a design error. If you have an =
export driver, how can you</FONT>
<BR><FONT SIZE=3D2>> expect to run 3DES?</FONT>
</P>
<P><FONT SIZE=3D2>You can't.</FONT>
</P>
<P><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Now why we can't reject it. Envision you =
are running a world-wide</FONT>
<BR><FONT SIZE=3D2>> corporation where domain-based policies are =
assigned to clients at</FONT>
<BR><FONT SIZE=3D2>> different sites at different counties. =
Some of them run the export</FONT>
<BR><FONT SIZE=3D2>> version of Win2K. Since it is near =
impossible to know what version of</FONT>
<BR><FONT SIZE=3D2>> Win2K clients are running, so all clients =
policies are set to use 3DES.</FONT>
<BR><FONT SIZE=3D2>> On the corp-side, some servers will be =
configured to accept 3DES only</FONT>
<BR><FONT SIZE=3D2>> and others both DES and 3DES. If you don't =
weaken 3DES on the export</FONT>
<BR><FONT SIZE=3D2>> clients, there is no way to talk to servers with =
DES configured.</FONT>
</P>
<P><FONT SIZE=3D2>Then you need to have configuration option allows the =
administrator</FONT>
<BR><FONT SIZE=3D2>to configure 3DES and DES or 3DES only.</FONT>
</P>
<P><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Having said that, the report mechanism should =
probably be improved and</FONT>
<BR><FONT SIZE=3D2>> we will address this in the next =
release.=3D20</FONT>
</P>
<P><FONT SIZE=3D2>Sorry Chun,</FONT>
<BR><FONT SIZE=3D2> I see the problem you are trying to address, =
but I don't agree</FONT>
<BR><FONT SIZE=3D2>with your solution.</FONT>
</P>
<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Michael Carney</FONT>
</P>
<P><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> --Chun</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Paul Koning [<A =
HREF=3D"mailto:pkoning@xedia.com">mailto:pkoning@xedia.com</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: Friday, May 12, 2000 1:24 PM</FONT>
<BR><FONT SIZE=3D2>> To: Sumi Singh</FONT>
<BR><FONT SIZE=3D2>> Cc: ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: Win2000 IKE and 3des</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> >>>>> "Sumi" =3D3D=3D3D =
Sumi Singh <sumis@Exchange.Microsoft.com> writes:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Sumi> Just to clarify the behaviour of =
Windows 2000 - Windows 2000</FONT>
<BR><FONT SIZE=3D2>> Sumi> weakens 3DES policy to DES if you =
do not have the strong</FONT>
<BR><FONT SIZE=3D2>> Sumi> encryption pack (128-bit) =
installed. This weakening is</FONT>
<BR><FONT SIZE=3D2>> Sumi> announced by an event in the =
Audit log. So if you have 2 peers</FONT>
<BR><FONT SIZE=3D2>> Sumi> with no encryption pack =
installed, and a policy to use 3DES,</FONT>
<BR><FONT SIZE=3D2>> Sumi> they will talk DES since they =
cannot do 3DES.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Clearly that's a major design error.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> If you ask for something that's not supported, =
it should be rejected.</FONT>
<BR><FONT SIZE=3D2>> To change it (even with a message in some =
obscure log) is clearly</FONT>
<BR><FONT SIZE=3D2>> wrong. You don't build secure systems that =
way.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> paul</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> ------_=3D_NextPart_001_01BFBC55.58D2F2C8</FONT>
<BR><FONT SIZE=3D2>> Content-Type: text/html;</FONT>
<BR><FONT SIZE=3D2>> =
charset=3D"us-ascii"</FONT>
<BR><FONT SIZE=3D2>> Content-Transfer-Encoding: =
quoted-printable</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML =
3.2//EN"></FONT>
<BR><FONT SIZE=3D2>> <HTML></FONT>
<BR><FONT SIZE=3D2>> <HEAD></FONT>
<BR><FONT SIZE=3D2>> <META HTTP-EQUIV=3D3D"Content-Type" =
CONTENT=3D3D"text/html; =3D</FONT>
<BR><FONT SIZE=3D2>> charset=3D3Dus-ascii"></FONT>
<BR><FONT SIZE=3D2>> <META NAME=3D3D"Generator" =
CONTENT=3D3D"MS Exchange Server version =3D</FONT>
<BR><FONT SIZE=3D2>> 6.0.4366.0"></FONT>
<BR><FONT SIZE=3D2>> <TITLE>RE: Win2000 IKE and =
3des</TITLE></FONT>
<BR><FONT SIZE=3D2>> </HEAD></FONT>
<BR><FONT SIZE=3D2>> <BODY></FONT>
<BR><FONT SIZE=3D2>> <!-- Converted from text/plain format =
--></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <P><FONT SIZE=3D3D2>This is not a =
design error.&nbsp; If you have an =3D</FONT>
<BR><FONT SIZE=3D2>> export driver, how can you expect to run =
3DES?</FONT></FONT>
<BR><FONT SIZE=3D2>> </P></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <P><FONT SIZE=3D3D2>Now why we can't =
reject it.&nbsp; Envision you are =3D</FONT>
<BR><FONT SIZE=3D2>> running a world-wide corporation where =
domain-based policies are =3D</FONT>
<BR><FONT SIZE=3D2>> assigned to clients at different sites at =
different counties.&nbsp; Some =3D</FONT>
<BR><FONT SIZE=3D2>> of them run the export version of =
Win2K.&nbsp; Since it is near =3D</FONT>
<BR><FONT SIZE=3D2>> impossible to know what version of Win2K clients =
are running, so all =3D</FONT>
<BR><FONT SIZE=3D2>> clients policies are set to use 3DES.&nbsp; =
On the corp-side, some =3D</FONT>
<BR><FONT SIZE=3D2>> servers will be configured to accept 3DES only =
and others both DES and =3D</FONT>
<BR><FONT SIZE=3D2>> 3DES.&nbsp; If you don't weaken 3DES on the =
export clients, there is no =3D</FONT>
<BR><FONT SIZE=3D2>> way to talk to servers with DES =
configured.</FONT></P></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <P><FONT SIZE=3D3D2>Having said =
that, the report mechanism should probably =3D</FONT>
<BR><FONT SIZE=3D2>> be improved and we will address this in the next =
release. </FONT></FONT>
<BR><FONT SIZE=3D2>> </P></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <P><FONT =
SIZE=3D3D2>--Chun</FONT></FONT>
<BR><FONT SIZE=3D2>> </P></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <P><FONT SIZE=3D3D2>-----Original =
Message-----</FONT></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <BR><FONT SIZE=3D3D2>From: Paul =
Koning [<A =3D</FONT>
<BR><FONT SIZE=3D2>> HREF=3D3D"<A =
HREF=3D"mailto:pkoning@xedia.com">mailto:pkoning@xedia.com</A>"><=
A =
HREF=3D"mailto:pkoning@xedia.com">mailto:pkoning@xedia.com</A></A>]=
</FONT></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <BR><FONT SIZE=3D3D2>Sent: Friday, =
May 12, 2000 1:24 PM</FONT></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <BR><FONT SIZE=3D3D2>To: Sumi =
Singh</FONT></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <BR><FONT SIZE=3D3D2>Cc: =
ipsec@lists.tislabs.com</FONT></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <BR><FONT SIZE=3D3D2>Subject: RE: =
Win2000 IKE and 3des</FONT></FONT>
<BR><FONT SIZE=3D2>> </P></FONT>
<BR><FONT SIZE=3D2>> <BR></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <P><FONT =
SIZE=3D3D2>&gt;&gt;&gt;&gt;&gt; =
&quot;Sumi&quot; =3D3D=3D3D Sumi =3D</FONT>
<BR><FONT SIZE=3D2>> Singh =
&lt;sumis@Exchange.Microsoft.com&gt; writes:</FONT></FONT>
<BR><FONT SIZE=3D2>> </P></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <P><FONT =
SIZE=3D3D2>&nbsp;Sumi&gt; Just to clarify the behaviour of =
=3D</FONT>
<BR><FONT SIZE=3D2>> Windows 2000 - Windows 2000</FONT></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <BR><FONT =
SIZE=3D3D2>&nbsp;Sumi&gt; weakens 3DES policy to DES if you =
do =3D</FONT>
<BR><FONT SIZE=3D2>> not have the strong</FONT></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <BR><FONT =
SIZE=3D3D2>&nbsp;Sumi&gt; encryption pack (128-bit) =
installed. =3D</FONT>
<BR><FONT SIZE=3D2>> This weakening is</FONT></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <BR><FONT =
SIZE=3D3D2>&nbsp;Sumi&gt; announced by an event in the Audit =
=3D</FONT>
<BR><FONT SIZE=3D2>> log. So if you have 2 peers</FONT></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <BR><FONT =
SIZE=3D3D2>&nbsp;Sumi&gt; with no encryption pack installed, =
and =3D</FONT>
<BR><FONT SIZE=3D2>> a policy to use 3DES,</FONT></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <BR><FONT =
SIZE=3D3D2>&nbsp;Sumi&gt; they will talk DES since they =
cannot =3D</FONT>
<BR><FONT SIZE=3D2>> do 3DES.</FONT></FONT>
<BR><FONT SIZE=3D2>> </P></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <P><FONT SIZE=3D3D2>Clearly that's a =
major design error.</FONT></FONT>
<BR><FONT SIZE=3D2>> </P></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <P><FONT SIZE=3D3D2>If you ask for =
something that's not supported, it =3D</FONT>
<BR><FONT SIZE=3D2>> should be rejected.</FONT></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <BR><FONT SIZE=3D3D2>To change it =
(even with a message in some obscure =3D</FONT>
<BR><FONT SIZE=3D2>> log) is clearly</FONT></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> <BR><FONT =
SIZE=3D3D2>wrong.&nbsp; You don't build secure systems that =
=3D</FONT>
<BR><FONT SIZE=3D2>> way.</FONT></FONT>
<BR><FONT SIZE=3D2>> </P></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> =
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
;nbsp; <FONT SIZE=3D3D2>paul</FONT></FONT>
<BR><FONT SIZE=3D2>> </P></FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </BODY></FONT>
<BR><FONT SIZE=3D2>> </HTML></FONT>
<BR><FONT SIZE=3D2>> =
------_=3D_NextPart_001_01BFBC55.58D2F2C8--</FONT>
</P>
</BODY>
</HTML>
------_=_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: <C0486E2A50E2D211849D006008119DD01F03E8@NTSRVR5>
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 <declan@well.com>
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: <akrywani@newbridge.com>
To: "'CHINNA N.R. PELLACURU'" <pcn@cisco.com>,
"Andrew Krywaniuk" </o=TimeStepCorporation/ou=TIMESTEP/cn=Recipients/cn=akrywaniuk@ns01.newbridge.com>
Cc: "'Jan Vilhuber'" <vilhuber@cisco.com>, "'Stephen Kent'" <kent@bbn.com>,
<ipsec@lists.tislabs.com>
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: <Pine.GSO.4.10.10005151119140.2352-100000@zipper.cisco.com>
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 <declan@wired.com>
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 <henry@spsystems.net>
To: Declan McCullagh <declan@wired.com>
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: <Pine.BSI.3.91.1000515153333.12225H-100000@spsystems.net>
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 <declan@wired.com>
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" <wdixon@Exchange.Microsoft.com>
To: "Jianying Zhou" <jyzhou@krdl.org.sg>,
"Brian Swander" <briansw@Exchange.Microsoft.com>
Cc: <ipsec@lists.tislabs.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4366.0">
<TITLE>RE: Win2k IKE</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>Jianying, the basic options win2k supports is noted in =
our supported options list on the last bakeoff form:</FONT>
</P>
<P><FONT SIZE=3D2> <A =
HREF=3D"http://www.calbug.org:8080/cgi-bin/vpn/index.cgi">http://www.calb=
ug.org:8080/cgi-bin/vpn/index.cgi</A></FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jianying Zhou [<A =
HREF=3D"mailto:jyzhou@krdl.org.sg">mailto:jyzhou@krdl.org.sg</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, April 19, 2000 6:48 PM</FONT>
<BR><FONT SIZE=3D2>To: Brian Swander</FONT>
<BR><FONT SIZE=3D2>Cc: ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Win2k IKE</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>Thanks, Brian. </FONT>
</P>
<P><FONT SIZE=3D2>A further question. What are the functions or API used =
in Win2k for IPSec</FONT>
<BR><FONT SIZE=3D2>encryption and hash operations?</FONT>
</P>
<P><FONT SIZE=3D2>Jianying Zhou</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>On Mon, 17 Apr 2000, Brian Swander wrote:</FONT>
</P>
<P><FONT SIZE=3D2>> ike and ipsec are in all flavors of win2k.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> bs</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Jianying Zhou [<A =
HREF=3D"mailto:jyzhou@krdl.org.sg">mailto:jyzhou@krdl.org.sg</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: Sunday, April 16, 2000 6:33 PM</FONT>
<BR><FONT SIZE=3D2>> To: ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=3D2>> Subject: Win2k IKE</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Hi,</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Does anyone know whether IKE and IPsec are =
supported in all Win2k versions,</FONT>
<BR><FONT SIZE=3D2>> that is professional, server, and advanced =
server versions?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Thanks.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Jianying Zhou</FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------_=_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" <smb@research.att.com>
To: Declan McCullagh <declan@wired.com>
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" <mhw@wittsend.com>
To: Declan McCullagh <declan@wired.com>
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" <mhw@wittsend.com>
From: David Jablon <dpj@world.std.com>
Subject: Re: Wired query on Windows 2000 and DES/3DES
Cc: Declan McCullagh <declan@wired.com>, 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" <mhw@wittsend.com> 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: <v04220803b545d664ab9b@[128.33.238.53]>
In-Reply-To:
<Pine.SOL.3.96.1000514113714.24176A-100000@jvilhube-ss20.cisco.com>
References:
<Pine.SOL.3.96.1000514113714.24176A-100000@jvilhube-ss20.cisco.com>
Date: Mon, 15 May 2000 12:33:44 -0400
To: Jan Vilhuber <vilhuber@cisco.com>
From: Stephen Kent <kent@bbn.com>
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: <v04220813b54685276ea7@[128.33.238.53]>
In-Reply-To: <Pine.GSO.4.10.10005151119140.2352-100000@zipper.cisco.com>
References: <Pine.GSO.4.10.10005151119140.2352-100000@zipper.cisco.com>
Date: Tue, 16 May 2000 00:56:26 -0400
To: "CHINNA N.R. PELLACURU" <pcn@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: Windows 2000 and Cicsco router interoperability
Cc: Andrew Krywaniuk <akrywani@newbridge.com>,
"'Jan Vilhuber'" <vilhuber@cisco.com>, 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" <pcn@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: Andrew Krywaniuk <akrywani@newbridge.com>,
"'Jan Vilhuber'" <vilhuber@cisco.com>, ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <v04220813b54685276ea7@[128.33.238.53]>
Message-ID: <Pine.GSO.4.10.10005152211290.18885-100000@zipper.cisco.com>
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 <RuheenaR@future.futsoft.com>
Reply-To: "RuheenaR@future.futsoft.com" <RuheenaR@future.futsoft.com>
To: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>,
"'Joern Sierwald'"
<joern.sierwald@F-Secure.com>,
"'Markku Savela'"
<msa@anise.tte.vtt.fi>,
"'Stephen Kent'" <kent@bbn.com>
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" <pcn@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: Andrew Krywaniuk <akrywani@newbridge.com>,
"'Jan Vilhuber'" <vilhuber@cisco.com>, ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <Pine.GSO.4.10.10005152211290.18885-100000@zipper.cisco.com>
Message-ID: <Pine.GSO.4.10.10005152333300.18885-100000@zipper.cisco.com>
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 <CTrobridge@baltimore.com>
To: RuheenaR@future.futsoft.com, ipsec@lists.tislabs.com,
"'Joern Sierwald'"
<joern.sierwald@F-Secure.com>,
"'Markku Savela'" <msa@anise.tte.vtt.fi>,
"'Stephen Kent'" <kent@bbn.com>
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 <CTrobridge@baltimore.com>
To: "CHINNA N.R. PELLACURU" <pcn@cisco.com>, Stephen Kent <kent@bbn.com>
Cc: Andrew Krywaniuk <akrywani@newbridge.com>,
"'Jan Vilhuber'"
<vilhuber@cisco.com>, 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" <Stephen.Waters@cabletron.com>
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: <C5B7AD50B789D31191B400805F9F52CB1FC624@exchange1.abl.ca>
From: Dominique Bastien <Dominique.Bastien@abl.ca>
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 <mjos@cc.jyu.fi>
X-Sender: mjos@tukki
To: Declan McCullagh <declan@well.com>
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: <Pine.GSO.4.10.10005160908420.8366-100000@tukki>
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 <mjos@jyu.fi> 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 <declan@wired.com>
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" <mhw@wittsend.com>
To: Ruheena Rashid <RuheenaR@future.futsoft.com>
Cc: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>,
"'Joern Sierwald'" <joern.sierwald@F-Secure.com>,
"'Markku Savela'" <msa@anise.tte.vtt.fi>,
"'Stephen Kent'" <kent@bbn.com>
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 <henry@spsystems.net>
To: Ruheena Rashid <RuheenaR@future.futsoft.com>
cc: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: Re: Regarding DES/3DES
In-Reply-To: <01BFBF2F.FB121E60.RuheenaR@future.futsoft.com>
Message-ID: <Pine.BSI.3.91.1000516100849.27393B-100000@spsystems.net>
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 <pkoning@xedia.com>
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: <C5B7AD50B789D31191B400805F9F52CB1FC624@exchange1.abl.ca>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Dominique" == Dominique Bastien <Dominique.Bastien@abl.ca> 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" <pcn@cisco.com>
To: Chris Trobridge <CTrobridge@baltimore.com>
cc: Stephen Kent <kent@bbn.com>, Andrew Krywaniuk <akrywani@newbridge.com>,
"'Jan Vilhuber'" <vilhuber@cisco.com>, ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <1FD60AE4DB6CD2118C420008C74C27B854A364@baltimore.com>
Message-ID: <Pine.GSO.4.10.10005160904220.4339-100000@zipper.cisco.com>
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 <CTrobridge@baltimore.com>
To: "CHINNA N.R. PELLACURU" <pcn@cisco.com>
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: <akrywani@newbridge.com>
From: "Andrew Krywaniuk" <akrywani@newbridge.com>
To: "'CHINNA N.R. PELLACURU'" <pcn@cisco.com>
Cc: <ipsec@lists.tislabs.com>
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: <Pine.GSO.4.10.10005152211290.18885-100000@zipper.cisco.com>
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" <pcn@cisco.com>
To: Chris Trobridge <CTrobridge@baltimore.com>
cc: ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <1FD60AE4DB6CD2118C420008C74C27B854A376@baltimore.com>
Message-ID: <Pine.GSO.4.10.10005161006500.6052-100000@zipper.cisco.com>
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" <pcn@cisco.com>
To: Chris Trobridge <CTrobridge@baltimore.com>
cc: ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <Pine.GSO.4.10.10005161006500.6052-100000@zipper.cisco.com>
Message-ID: <Pine.GSO.4.10.10005161018180.6052-100000@zipper.cisco.com>
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 <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Scott G. Kelly" <skelly@redcreek.com>
CC: Qiu Ying <qiuying@krdl.org.sg>, 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" <townsley@cisco.com>
Organization: cisco Systems
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
CC: Jan Vilhuber <vilhuber@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <Pine.SOL.3.96.1000514113714.24176A-100000@jvilhube-ss20.cisco.com> <v04220803b545d664ab9b@[128.33.238.53]>
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" <townsley@cisco.com>
Organization: cisco Systems
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
CC: "CHINNA N.R. PELLACURU" <pcn@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <Pine.GSO.4.10.10005101447140.2714-100000@irp-view5.cisco.com> <v04220804b540d25d02f3@[171.78.30.107]>
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 <vilhuber@cisco.com>
Reply-To: Jan Vilhuber <vilhuber@cisco.com>
To: ipsec@lists.tislabs.com
cc: wdixon@Exchange.Microsoft.com
Subject: more microsoft policy issues?
Message-ID: <Pine.SOL.3.96.1000516135720.28282e-100000@jvilhube-ss20.cisco.com>
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" <townsley@cisco.com>
Organization: cisco Systems
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris Trobridge <CTrobridge@baltimore.com>
CC: "CHINNA N.R. PELLACURU" <pcn@cisco.com>, Stephen Kent <kent@bbn.com>,
Andrew Krywaniuk <akrywani@newbridge.com>,
"'Jan Vilhuber'" <vilhuber@cisco.com>, 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 <will@austin.ibm.com>
To: IETF IPSec <ipsec@lists.tislabs.com>
Subject: HTML in mail on list
Message-ID: <20000516201235.D52068@austin.ibm.com>
Mail-Followup-To: IETF IPSec <ipsec@lists.tislabs.com>
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" <pcn@cisco.com>
To: Andrew Krywaniuk <akrywani@newbridge.com>
cc: ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <000901bfbf56$a6372df0$d23e788a@andrewk3.timestep.com>
Message-ID: <Pine.GSO.4.10.10005161818460.4546-100000@zipper.cisco.com>
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 <will@austin.ibm.com>
To: IETF IPSec <ipsec@lists.tislabs.com>
Subject: Beating the dead horse (responder life notify questions)
Message-ID: <20000516195537.B52068@austin.ibm.com>
Mail-Followup-To: IETF IPSec <ipsec@lists.tislabs.com>
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" <wdixon@Exchange.Microsoft.com>
To: "Jan Vilhuber" <vilhuber@cisco.com>, <ipsec@lists.tislabs.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4366.0">
<TITLE>RE: more microsoft policy issues?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>The news group for Windows 2000 networking =
functionality in general is: microsoft.public.win2000.networking</FONT>
</P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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. =
</FONT></P>
<BR>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jan Vilhuber [<A =
HREF=3D"mailto:vilhuber@cisco.com">mailto:vilhuber@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, May 16, 2000 2:01 PM</FONT>
<BR><FONT SIZE=3D2>To: ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=3D2>Cc: William Dixon</FONT>
<BR><FONT SIZE=3D2>Subject: more microsoft policy issues?</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>From an email I just saw going across my desk:</FONT>
</P>
<P><FONT SIZE=3D2>> Even though the "do not use IPSec" is =
marked in the W2000 configuration the</FONT>
<BR><FONT SIZE=3D2>> W2000 client still uses IPSec. Please note =
in Windows 2000 build 2195</FONT>
<BR><FONT SIZE=3D2>> Microsoft have decided to use IPSec all the =
time.</FONT>
</P>
<P><FONT SIZE=3D2>Come on, guys! Please tell me that THIS at least is a =
bug, and not another one</FONT>
<BR><FONT SIZE=3D2>of those design decisions...</FONT>
</P>
<P><FONT SIZE=3D2>jan</FONT>
<BR><FONT SIZE=3D2>P.S. Caveat: I don't have any idea of build numbers. =
Maybe 2195 is really old</FONT>
<BR><FONT SIZE=3D2>and this is already fixed...</FONT>
<BR><FONT SIZE=3D2> --</FONT>
<BR><FONT SIZE=3D2>Jan =
Vilhuber  =
; =
&=
nbsp; =
vilhuber@cisco.com</FONT>
<BR><FONT SIZE=3D2>Cisco Systems, San =
Jose &nb=
sp; &nbs=
p;  =
; (408) 527-0847</FONT>
</P>
</BODY>
</HTML>
------_=_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 <vilhuber@cisco.com>
To: William Dixon <wdixon@Exchange.Microsoft.com>
cc: ipsec@lists.tislabs.com
Subject: RE: more microsoft policy issues?
In-Reply-To: <6A05D00595BE644E9F435BE5947423F2FFC3E1@fifi.platinum.corp.microsoft.com>
Message-ID: <Pine.SOL.3.96.1000516191300.29293E-100000@jvilhube-ss20.cisco.com>
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: <v04220804b5470a0ff290@[128.33.238.53]>
In-Reply-To: <Pine.GSO.4.10.10005152211290.18885-100000@zipper.cisco.com>
References: <Pine.GSO.4.10.10005152211290.18885-100000@zipper.cisco.com>
Date: Tue, 16 May 2000 23:55:47 -0400
To: "CHINNA N.R. PELLACURU" <pcn@cisco.com>
From: Stephen Kent <kent@bbn.com>
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: <v04220802b547cd3b835b@[128.33.238.73]>
In-Reply-To: <3921B453.E9572D4E@cisco.com>
References: <Pine.GSO.4.10.10005101447140.2714-100000@irp-view5.cisco.com>
<v04220804b540d25d02f3@[171.78.30.107]> <3921B453.E9572D4E@cisco.com>
Date: Wed, 17 May 2000 00:23:13 -0400
To: "W. Mark Townsley" <townsley@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Windows 2000 and Cicsco router interoperability
Cc: "CHINNA N.R. PELLACURU" <pcn@cisco.com>, 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: <v04220805b54733f3f645@[128.33.238.15]>
In-Reply-To: <Pine.GSO.4.10.10005152333300.18885-100000@zipper.cisco.com>
References: <Pine.GSO.4.10.10005152333300.18885-100000@zipper.cisco.com>
Date: Tue, 16 May 2000 13:27:24 -0400
To: "CHINNA N.R. PELLACURU" <pcn@cisco.com>
From: Stephen Kent <kent@bbn.com>
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" <townsley@cisco.com>
Organization: cisco Systems
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
CC: ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <Pine.SOL.3.96.1000514113714.24176A-100000@jvilhube-ss20.cisco.com>
<v04220803b545d664ab9b@[128.33.238.53]> <3921AB39.F854611@cisco.com> <v04220801b547cc534cd2@[128.33.238.73]>
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: <v04220801b547cc534cd2@[128.33.238.73]>
In-Reply-To: <3921AB39.F854611@cisco.com>
References:
<Pine.SOL.3.96.1000514113714.24176A-100000@jvilhube-ss20.cisco.com>
<v04220803b545d664ab9b@[128.33.238.53]> <3921AB39.F854611@cisco.com>
Date: Wed, 17 May 2000 00:14:28 -0400
To: "W. Mark Townsley" <townsley@cisco.com>
From: Stephen Kent <kent@bbn.com>
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: <v04220805b547d15c7c8a@[128.33.238.73]>
In-Reply-To: <39221E67.7C878389@cisco.com>
References: <Pine.GSO.4.10.10005152211290.18885-100000@zipper.cisco.com>
<v04220804b5470a0ff290@[128.33.238.53]> <39221E67.7C878389@cisco.com>
Date: Wed, 17 May 2000 00:39:54 -0400
To: "W. Mark Townsley" <townsley@cisco.com>
From: Stephen Kent <kent@bbn.com>
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" <townsley@cisco.com>
Organization: cisco Systems
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
CC: "CHINNA N.R. PELLACURU" <pcn@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <Pine.GSO.4.10.10005152211290.18885-100000@zipper.cisco.com> <v04220804b5470a0ff290@[128.33.238.53]>
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 <vilhuber@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: "CHINNA N.R. PELLACURU" <pcn@cisco.com>, ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <v04220804b5470a0ff290@[128.33.238.53]>
Message-ID: <Pine.SOL.3.96.1000516215040.29630A-100000@jvilhube-ss20.cisco.com>
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" <townsley@cisco.com>
Organization: cisco Systems
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
CC: "CHINNA N.R. PELLACURU" <pcn@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <Pine.GSO.4.10.10005101447140.2714-100000@irp-view5.cisco.com>
<v04220804b540d25d02f3@[171.78.30.107]> <3921B453.E9572D4E@cisco.com> <v04220802b547cd3b835b@[128.33.238.73]>
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" <townsley@cisco.com>
Organization: cisco Systems
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
CC: ipsec@lists.tislabs.com
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <Pine.GSO.4.10.10005152211290.18885-100000@zipper.cisco.com>
<v04220804b5470a0ff290@[128.33.238.53]> <39221E67.7C878389@cisco.com> <v04220805b547d15c7c8a@[128.33.238.73]>
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" <smb@research.att.com>
To: Jan Vilhuber <vilhuber@cisco.com>
Cc: Stephen Kent <kent@bbn.com>, "CHINNA N.R. PELLACURU" <pcn@cisco.com>,
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 <Pine.SOL.3.96.1000516215040.29630A-100000@jvilhube-ss20.cisco.com>,
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" <pcn@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <v04220804b5470a0ff290@[128.33.238.53]>
Message-ID: <Pine.GSO.4.10.10005162254170.15095-100000@zipper.cisco.com>
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 <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "W. Mark Townsley" <townsley@cisco.com>
CC: Stephen Kent <kent@bbn.com>, "CHINNA N.R. PELLACURU" <pcn@cisco.com>,
ipsec@lists.tislabs.com
Subject: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)
References: <Pine.GSO.4.10.10005101447140.2714-100000@irp-view5.cisco.com> <v04220804b540d25d02f3@[171.78.30.107]> <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." <ra995477@dcc.unicamp.br>
To: ipsec@lists.tislabs.com
Subject: DNSsec
Message-ID: <Pine.GSO.4.10.10005161435020.23959-100000@xingu.dcc.unicamp.br>
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 <CTrobridge@baltimore.com>
To: "CHINNA N.R. PELLACURU" <pcn@cisco.com>
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" <townsley@cisco.com>
Organization: cisco Systems
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ari Huttunen <Ari.Huttunen@F-Secure.com>
CC: Stephen Kent <kent@bbn.com>, "CHINNA N.R. PELLACURU" <pcn@cisco.com>,
ipsec@lists.tislabs.com
Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)
References: <Pine.GSO.4.10.10005101447140.2714-100000@irp-view5.cisco.com> <v04220804b540d25d02f3@[171.78.30.107]> <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 <CTrobridge@baltimore.com>
To: "W. Mark Townsley" <townsley@cisco.com>
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" <townsley@cisco.com>
Organization: cisco Systems
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris Trobridge <CTrobridge@baltimore.com>
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 <CTrobridge@baltimore.com>
To: "W. Mark Townsley" <townsley@cisco.com>, Stephen Kent <kent@bbn.com>
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" <skelly@redcreek.com>
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" <townsley@cisco.com>
CC: Ari Huttunen <Ari.Huttunen@F-Secure.com>, Stephen Kent <kent@bbn.com>,
"CHINNA N.R. PELLACURU" <pcn@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)
References: <Pine.GSO.4.10.10005101447140.2714-100000@irp-view5.cisco.com> <v04220804b540d25d02f3@[171.78.30.107]> <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 <barney@databus.com>
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 <barney@databus.com>
> From: Chris Trobridge <CTrobridge@baltimore.com>
> 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 <paul@mci.net>
Subject: Re: Windows 2000 and Cicsco router interoperability
In-reply-to: <20000517062617.C3FB935DC2@smb.research.att.com>
To: "Steven M. Bellovin" <smb@research.att.com>,
Jan Vilhuber <vilhuber@cisco.com>
Cc: Stephen Kent <kent@bbn.com>, "CHINNA N.R. PELLACURU" <pcn@cisco.com>,
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"
<smb@research.att.com> wrote:
> In message
> <Pine.SOL.3.96.1000516215040.29630A-100000@jvilhube-ss20.cisco.com>, 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" <wdixon@Exchange.Microsoft.com>
To: "Declan McCullagh" <declan@wired.com>, <ipsec@lists.tislabs.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4368.3">
<TITLE>RE: Wired query on Windows 2000 and DES/3DES</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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</FONT></P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Declan McCullagh [<A =
HREF=3D"mailto:declan@wired.com">mailto:declan@wired.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, May 16, 2000 6:02 AM</FONT>
<BR><FONT SIZE=3D2>To: ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Wired query on Windows 2000 and =
DES/3DES</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>My article is here:</FONT>
</P>
<P><FONT SIZE=3D2><A =
HREF=3D"http://www.wired.com/news/technology/0,1282,36336,00.html">http:/=
/www.wired.com/news/technology/0,1282,36336,00.html</A></FONT>
</P>
<P><FONT SIZE=3D2>Thanks, all for the help.</FONT>
</P>
<P><FONT SIZE=3D2>-Declan</FONT>
</P>
</BODY>
</HTML>
------_=_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" <wdixon@Exchange.Microsoft.com>
To: "Jan Vilhuber" <vilhuber@cisco.com>
Cc: <ipsec@lists.tislabs.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4368.3">
<TITLE>RE: more microsoft policy issues?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>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. </FONT></P>
<P><FONT SIZE=3D2>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. </FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jan Vilhuber [<A =
HREF=3D"mailto:vilhuber@cisco.com">mailto:vilhuber@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, May 16, 2000 7:18 PM</FONT>
<BR><FONT SIZE=3D2>To: William Dixon</FONT>
<BR><FONT SIZE=3D2>Cc: ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: more microsoft policy issues?</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>On Tue, 16 May 2000, William Dixon wrote:</FONT>
<BR><FONT SIZE=3D2>> Jan, posting this without context is just =
inflammatory. If it makes you</FONT>
<BR><FONT SIZE=3D2>> happy, send flame to me personally. The =
list isn't here to discuss</FONT>
<BR><FONT SIZE=3D2>> product bugs, postulate on what may be a bug, =
nor complain about the</FONT>
<BR><FONT SIZE=3D2>> wording on dialogs.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>Sorry. That's all the context I had. Maybe I was a =
bit hasty (in view of the</FONT>
<BR><FONT SIZE=3D2>recent thread). If so, I apologize.</FONT>
</P>
<P><FONT SIZE=3D2>Reading the rest below, though, it sounds like if the =
OS can override a local</FONT>
<BR><FONT SIZE=3D2>decision, then you again have a scenario where I =
click on a choice, and win2k</FONT>
<BR><FONT SIZE=3D2>overrides me without telling me. Bad. I mean, what =
would YOU expect, if you</FONT>
<BR><FONT SIZE=3D2>said: Don't do ipsec. *I* would expect that ipsec =
will not be performed. At</FONT>
<BR><FONT SIZE=3D2>all. Ever.</FONT>
</P>
<P><FONT SIZE=3D2>And I wasn't venting about a product bug, either =
(although I was hoping it</FONT>
<BR><FONT SIZE=3D2>would turn out to be one). it's the gratuitous =
overriding of user-selected</FONT>
<BR><FONT SIZE=3D2>policy that was the issue I meant to address.</FONT>
</P>
<P><FONT SIZE=3D2>jan</FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=3D2>> The news group for Windows 2000 networking =
functionality in general is:</FONT>
<BR><FONT SIZE=3D2>> microsoft.public.win2000.networking</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Or you can email NTBUGTRAQ to report verified =
problems or email</FONT>
<BR><FONT SIZE=3D2>> secure@microsoft.com to get a formal corporate =
response to a discovered</FONT>
<BR><FONT SIZE=3D2>> security weakness for any Microsoft =
product.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> This setting is in the advanced properties of =
the TCPIP properties and</FONT>
<BR><FONT SIZE=3D2>> allows a local admin to select a default IPSec =
policy. By default the</FONT>
<BR><FONT SIZE=3D2>> selection is says in text "Do not use =
IPSec". This is a local setting</FONT>
<BR><FONT SIZE=3D2>> which can be overridden by Win2k domain IPSec =
policy, and by OS</FONT>
<BR><FONT SIZE=3D2>> components such as L2TP which require IPSec for =
their operation. And</FONT>
<BR><FONT SIZE=3D2>> once again, the behavior is documented in online =
help and elsewhere.</FONT>
<BR><FONT SIZE=3D2>> The TCPIP properties UI is a quick and easy way =
for an admin to change</FONT>
<BR><FONT SIZE=3D2>> between different custom policies that have been =
created on the local</FONT>
<BR><FONT SIZE=3D2>> system.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> As one of our KB articles notes, we provide the =
default policies as an</FONT>
<BR><FONT SIZE=3D2>> example only, for initial testing only - real =
production use requires</FONT>
<BR><FONT SIZE=3D2>> your own custom designed IPSec policy. =
</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Jan Vilhuber [<A =
HREF=3D"mailto:vilhuber@cisco.com">mailto:vilhuber@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: Tuesday, May 16, 2000 2:01 PM</FONT>
<BR><FONT SIZE=3D2>> To: ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=3D2>> Cc: William Dixon</FONT>
<BR><FONT SIZE=3D2>> Subject: more microsoft policy issues?</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> >From an email I just saw going across my =
desk:</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> > Even though the "do not use =
IPSec" is marked in the W2000</FONT>
<BR><FONT SIZE=3D2>> configuration the</FONT>
<BR><FONT SIZE=3D2>> > W2000 client still uses IPSec. Please =
note in Windows 2000 build 2195</FONT>
<BR><FONT SIZE=3D2>> > Microsoft have decided to use IPSec all the =
time.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Come on, guys! Please tell me that THIS at least =
is a bug, and not</FONT>
<BR><FONT SIZE=3D2>> another one</FONT>
<BR><FONT SIZE=3D2>> of those design decisions...</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> jan</FONT>
<BR><FONT SIZE=3D2>> P.S. Caveat: I don't have any idea of build =
numbers. Maybe 2195 is</FONT>
<BR><FONT SIZE=3D2>> really old</FONT>
<BR><FONT SIZE=3D2>> and this is already fixed...</FONT>
<BR><FONT SIZE=3D2>> --</FONT>
<BR><FONT SIZE=3D2>> Jan Vilhuber</FONT>
<BR><FONT SIZE=3D2>> vilhuber@cisco.com</FONT>
<BR><FONT SIZE=3D2>> Cisco Systems, San =
Jose &nb=
sp; &nbs=
p;  =
; (408)</FONT>
<BR><FONT SIZE=3D2>> 527-0847</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
<P><FONT SIZE=3D2> --</FONT>
<BR><FONT SIZE=3D2>Jan =
Vilhuber  =
; =
&=
nbsp; =
vilhuber@cisco.com</FONT>
<BR><FONT SIZE=3D2>Cisco Systems, San =
Jose &nb=
sp; &nbs=
p;  =
; (408) 527-0847</FONT>
</P>
</BODY>
</HTML>
------_=_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" <pcn@cisco.com>
To: Chris Trobridge <CTrobridge@baltimore.com>
cc: ipsec@lists.tislabs.com
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <1FD60AE4DB6CD2118C420008C74C27B854A38B@baltimore.com>
Message-ID: <Pine.GSO.4.10.10005171344170.15322-100000@zipper.cisco.com>
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" <tytso@mit.edu>
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 <vilhuber@cisco.com>
To: "Scott G. Kelly" <skelly@redcreek.com>
cc: "W. Mark Townsley" <townsley@cisco.com>,
Ari Huttunen <Ari.Huttunen@F-Secure.com>, Stephen Kent <kent@bbn.com>,
"CHINNA N.R. PELLACURU" <pcn@cisco.com>, 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: <Pine.SOL.3.96.1000517154906.1040c-100000@jvilhube-ss20.cisco.com>
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 <vilhuber@cisco.com>
To: "Scott G. Kelly" <skelly@redcreek.com>
cc: "W. Mark Townsley" <townsley@cisco.com>,
Ari Huttunen <Ari.Huttunen@F-Secure.com>, Stephen Kent <kent@bbn.com>,
"CHINNA N.R. PELLACURU" <pcn@cisco.com>, 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: <Pine.SOL.3.96.1000517172400.1040H-100000@jvilhube-ss20.cisco.com>
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" <skelly@redcreek.com>
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 <vilhuber@cisco.com>
CC: "W. Mark Townsley" <townsley@cisco.com>,
Ari Huttunen <Ari.Huttunen@F-Secure.com>, Stephen Kent <kent@bbn.com>,
"CHINNA N.R. PELLACURU" <pcn@cisco.com>, ipsec@lists.tislabs.com
Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)
References: <Pine.SOL.3.96.1000517154906.1040c-100000@jvilhube-ss20.cisco.com>
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" <pcn@cisco.com>
To: "Scott G. Kelly" <skelly@redcreek.com>
cc: Jan Vilhuber <vilhuber@cisco.com>, "W. Mark Townsley" <townsley@cisco.com>,
Ari Huttunen <Ari.Huttunen@F-Secure.com>, Stephen Kent <kent@bbn.com>,
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: <Pine.GSO.4.10.10005171839080.3402-100000@zipper.cisco.com>
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 <ebooth@cisco.com>
To: "Scott G. Kelly" <skelly@redcreek.com>
cc: "W. Mark Townsley" <townsley@cisco.com>,
Ari Huttunen <Ari.Huttunen@F-Secure.com>, Stephen Kent <kent@bbn.com>,
"CHINNA N.R. PELLACURU" <pcn@cisco.com>, 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: <Pine.GSO.4.10.10005172207010.27509-100000@uzura.cisco.com>
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" <Stephen.Waters@cabletron.com>
To: Jan Vilhuber <vilhuber@cisco.com>
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 <declan@wired.com>
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 <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Declan" == Declan McCullagh <declan@wired.com> 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: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
Corporate: <A HREF="mailto:mcr@solidum.com">mcr@solidum.com</A>.
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 <raghava@trinc.com>
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" <mhw@wittsend.com>
To: raghava <raghava@trinc.com>
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 <vilhuber@cisco.com>
To: "Waters, Stephen" <Stephen.Waters@cabletron.com>
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: <Pine.SOL.3.96.1000518090856.4240I-100000@jvilhube-ss20.cisco.com>
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" <skelly@redcreek.com>
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" <pcn@cisco.com>
CC: Jan Vilhuber <vilhuber@cisco.com>, "W. Mark Townsley" <townsley@cisco.com>,
Ari Huttunen <Ari.Huttunen@F-Secure.com>, Stephen Kent <kent@bbn.com>,
ipsec@lists.tislabs.com
Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)
References: <Pine.GSO.4.10.10005171839080.3402-100000@zipper.cisco.com>
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: <v04220800b549cb905940@[128.33.238.32]>
In-Reply-To:
<Pine.SOL.3.96.1000516215040.29630A-100000@jvilhube-ss20.cisco.com>
References:
<Pine.SOL.3.96.1000516215040.29630A-100000@jvilhube-ss20.cisco.com>
Date: Thu, 18 May 2000 12:35:42 -0400
To: Jan Vilhuber <vilhuber@cisco.com>
From: Stephen Kent <kent@bbn.com>
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: <v04220803b549d120a96b@[128.33.238.32]>
In-Reply-To: <Pine.GSO.4.10.10005172207010.27509-100000@uzura.cisco.com>
References: <Pine.GSO.4.10.10005172207010.27509-100000@uzura.cisco.com>
Date: Thu, 18 May 2000 13:02:11 -0400
To: Skip Booth <ebooth@cisco.com>
From: Stephen Kent <kent@bbn.com>
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: <v04220801b549ccf3ad2f@[128.33.238.32]>
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 <barney@databus.com>
From: Stephen Kent <kent@bbn.com>
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: <v04220806b549d77427e2@[128.33.238.32]>
In-Reply-To: <Pine.GSO.4.10.10005162254170.15095-100000@zipper.cisco.com>
References: <Pine.GSO.4.10.10005162254170.15095-100000@zipper.cisco.com>
Date: Thu, 18 May 2000 13:25:13 -0400
To: "CHINNA N.R. PELLACURU" <pcn@cisco.com>
From: Stephen Kent <kent@bbn.com>
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: <v04220805b549d4af80f0@[128.33.238.32]>
In-Reply-To: <3922288D.CD0132BD@cisco.com>
References: <Pine.GSO.4.10.10005101447140.2714-100000@irp-view5.cisco.com>
<v04220804b540d25d02f3@[171.78.30.107]> <3921B453.E9572D4E@cisco.com>
<v04220802b547cd3b835b@[128.33.238.73]> <3922288D.CD0132BD@cisco.com>
Date: Thu, 18 May 2000 13:22:24 -0400
To: "W. Mark Townsley" <townsley@cisco.com>
From: Stephen Kent <kent@bbn.com>
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 <ebooth@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: ipsec@lists.tislabs.com
Subject: Re: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)
In-Reply-To: <v04220803b549d120a96b@[128.33.238.32]>
Message-ID: <Pine.GSO.4.10.10005181547310.17880-100000@uzura.cisco.com>
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 <barney@databus.com>
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" <wdixon@Exchange.Microsoft.com>
To: "William Dixon" <wdixon@Exchange.Microsoft.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4368.3">
<TITLE>L2TP-IPSec features list</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>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)</FONT></P>
<P><FONT SIZE=3D2>L2TP benefits ---------</FONT>
<BR><FONT SIZE=3D2>1) L2TP supports 4 VPN scenarios</FONT>
<BR><FONT SIZE=3D2> a.) legacy client PPP dial to NAS - NAS PPP =
user auth, NAS forwards PPP through L2TP tunnel to L2TP gateway </FONT>
<BR><FONT SIZE=3D2> b.) L2TP/IPSec capable client PPP dial to NAS =
- voluntary L2TP/IPSec to L2TP gateway</FONT>
<BR><FONT SIZE=3D2> c.) L2TP/IPSec capable client directly on IP =
network - user voluntary L2TP/IPSec tunnel to L2TP gateway</FONT>
<BR><FONT SIZE=3D2> d.) L2TP/IPSec gateway to gateway</FONT>
<BR><FONT SIZE=3D2> (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</FONT></P>
<P><FONT SIZE=3D2> (1) idea of a user for tunnel =
helps scalable management of remote tunnel end-points via radius.</FONT>
<BR><FONT SIZE=3D2>2) can have multiple L2TP tunnel sessions inside 1 =
IPSec SA pair for efficiency</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>4) keep alives for L2TP</FONT>
<BR><FONT SIZE=3D2>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</FONT></P>
<P><FONT SIZE=3D2>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</FONT></P>
<P><FONT SIZE=3D2>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</FONT></P>
<P><FONT SIZE=3D2>8) extensibility of L2TP with Attrib Value (AV) pairs, =
avoid extending, complicating IKE key management protocol</FONT>
<BR><FONT SIZE=3D2> a.) AV delivered dynamic redirection of =
gateway dest IP for global load balancing</FONT>
<BR><FONT SIZE=3D2> b.) AV delivered QOS values</FONT>
<BR><FONT SIZE=3D2>9) can use IPSec tunnel and transport filters which =
apply to assigned tunnel IP address above L2TP/PPP interface</FONT>
<BR><FONT SIZE=3D2> a.) enables tunnel within a tunnel with full =
interface support</FONT>
<BR><FONT SIZE=3D2> b.) enables static filtering & routes =
applied via Radius policy to tunnel interfaces</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>11) more vendors testing L2TP/IPSec interop (14) at =
last bakeoff than testing XAUTH/IKECFG (7)</FONT>
<BR><FONT SIZE=3D2>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. </FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2> a.) can run routing protocols across tunnel =
interoperable with other vendors</FONT>
<BR><FONT SIZE=3D2> b.) can carry standard, routable IP across =
tunnel, e.g. multicast, broadcast, unicast IP</FONT>
<BR><FONT SIZE=3D2>14) L2TP can be used in clear text mode without IPSec =
and get all of the tunneling benefits when security is not a =
problem.</FONT></P>
<P><FONT SIZE=3D2>15) Without IPSec, L2TP over IP can go through NATs =
because it uses UDP 1701.</FONT>
<BR><FONT SIZE=3D2>16) L2TP/IPSec </FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>18) Most remote access implementations support both =
machine auth first with either preshared key, or much stronger =
certificate auth, then user auth</FONT></P>
<P><FONT SIZE=3D2>19) L2TP/IPSec fully replaces and is a superset of =
PPTP functionality and is much more secure</FONT>
<BR><FONT SIZE=3D2>20) L2TP/IPSec today offers more features as RFC =
standard than IPSec tunnel mode does currently</FONT>
<BR><FONT SIZE=3D2>21) L2TP is defined to run over ATM, frame relay and =
X.25 non-IP transports</FONT>
<BR><FONT SIZE=3D2>22) IPSec encryption & integrity protection and =
IPCOMP can be hardware accelerated</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>PPP Benefits ---------- all RFC standard methods, I =
believe</FONT>
<BR><FONT SIZE=3D2>1) IP/DNS/WINs assignment through IPCP</FONT>
<BR><FONT SIZE=3D2>2) User authentication</FONT>
<BR><FONT SIZE=3D2> a.) userid/password</FONT>
<BR><FONT SIZE=3D2> b.) EAP and EAP/TLS - for certificate, =
smartcard, SecurID, token card, biometric</FONT>
<BR><FONT SIZE=3D2>3) AAA integration - with existing AAA servers, =
RADIUS TACACS</FONT>
<BR><FONT SIZE=3D2>4) multi-protocol support</FONT>
<BR><FONT SIZE=3D2>5) Link layer negotiation for MRU (this may help in =
the fragmentation arena)</FONT>
<BR><FONT SIZE=3D2>6) Keepalives for both PPP</FONT>
<BR><FONT SIZE=3D2>7) Multilink PPP for bundling bandwidth</FONT>
<BR><FONT SIZE=3D2>8) Routable interface</FONT>
<BR><FONT SIZE=3D2>9) PPP compression</FONT>
<BR><FONT SIZE=3D2>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 </FONT></P>
<P><FONT SIZE=3D2>11) supports idea of persistent and autostart =
connections, so links can come up automatically and be maintained</FONT>
</P>
<P><FONT SIZE=3D2>Wm</FONT>
</P>
</BODY>
</HTML>
------_=_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: <v04220816b54a19af9182@[128.33.238.33]>
In-Reply-To: <Pine.GSO.4.10.10005181547310.17880-100000@uzura.cisco.com>
References: <Pine.GSO.4.10.10005181547310.17880-100000@uzura.cisco.com>
Date: Thu, 18 May 2000 20:45:33 -0400
To: Skip Booth <ebooth@cisco.com>
From: Stephen Kent <kent@bbn.com>
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: <v04220817b54a3f52a358@[128.33.238.33]>
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 <barney@databus.com>
From: Stephen Kent <kent@bbn.com>
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 <claudio.lordello@innovation.siemens.ca>
To: Skip Booth <ebooth@cisco.com>
Cc: ipsec@lists.tislabs.com, Stephen Kent <kent@bbn.com>
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)
>
<text deleted>
> > 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" <robt@Exchange.Microsoft.com>
To: <tcosenza@us.ibm.com>, <ipsec@lists.tislabs.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4368.3">
<TITLE>RE: Windows 2000 and Cicsco router interoperability</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>Hi Thomas,</FONT>
</P>
<P><FONT SIZE=3D2>You might want to check out <A =
HREF=3D"http://www.microsoft.com/windows2000/library/planning/walkthrough=
s/default.asp">http://www.microsoft.com/windows2000/library/planning/walk=
throughs/default.asp</A>. There are guides there on how to install =
certificates and to configure IPSEC in Windows 2000 under the security =
services section.</FONT></P>
<P><FONT SIZE=3D2>Thanks!!</FONT>
</P>
<P><FONT SIZE=3D2>Rob Trace</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: tcosenza@us.ibm.com [<A =
HREF=3D"mailto:tcosenza@us.ibm.com">mailto:tcosenza@us.ibm.com</A>]</FONT=
>
<BR><FONT SIZE=3D2>Sent: Friday, May 19, 2000 7:14 AM</FONT>
<BR><FONT SIZE=3D2>To: ipsec@lists.tislabs.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Windows 2000 and Cicsco router =
interoperability</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<P><FONT SIZE=3D2>I apologise for sending this to the list but I need to =
find how I can</FONT>
<BR><FONT SIZE=3D2>contact Microsoft for some technical help with the =
Windows 2000 IPSec and</FONT>
<BR><FONT SIZE=3D2>how to request and install Certificates from Third =
Party CA? I know from</FONT>
<BR><FONT SIZE=3D2>the last couple of days that there are some Microsoft =
Techs that read the</FONT>
<BR><FONT SIZE=3D2>forum.</FONT>
</P>
<P><FONT SIZE=3D2>Thanks</FONT>
<BR><FONT SIZE=3D2>Thomas</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>Mr. Thomas Cosenza</FONT>
<BR><FONT SIZE=3D2>Software Eng. IBM</FONT>
<BR><FONT SIZE=3D2>T/L 441-8782</FONT>
<BR><FONT SIZE=3D2>Outside Line 919-543-8782</FONT>
<BR><FONT SIZE=3D2>"Everyone Fights, No one Quits! If you =
Quit I will shoot you myself!"</FONT>
<BR><FONT SIZE=3D2>Michael Irons in Starship Troopers</FONT>
</P>
<BR>
<BR>
</BODY>
</HTML>
------_=_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: <vinod.porwal@ishoni.com>
From: "Vinod Porwal" <vinod.porwal@ishoni.com>
To: <ipsec@lists.tislabs.com>
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 <greg.carter@entrust.com>
To: "'vinod.porwal@ishoni.com'" <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: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Stephen Kent" <kent@bbn.com>, "W. Mark Townsley" <townsley@cisco.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Windows 2000 and Cicsco router interoperability
Date: Mon, 22 May 2000 10:43:41 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPAECCCFAA.gwz@cisco.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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <v04220801b547cc534cd2@[128.33.238.73]>
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 <henry@spsystems.net>
To: IP Security List <ipsec@lists.tislabs.com>
Subject: RE: Windows 2000 and Cicsco router interoperability
In-Reply-To: <NDBBIHMPILAAGDHPCIOPAECCCFAA.gwz@cisco.com>
Message-ID: <Pine.BSI.3.91.1000522161304.13901A-100000@spsystems.net>
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: <v04220802b5505da9dd1a@[171.78.30.107]>
In-Reply-To: <NDBBIHMPILAAGDHPCIOPAECCCFAA.gwz@cisco.com>
References: <NDBBIHMPILAAGDHPCIOPAECCCFAA.gwz@cisco.com>
Date: Tue, 23 May 2000 12:12:13 -0400
To: <gwz@cisco.com>
From: Stephen Kent <kent@bbn.com>
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
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: <D76D503DE976D1119C7E00A0C944D87501CA7FC9@RSYS002A>
From: "Gallagher, Mick" <mick.gallagher@roke.co.uk>
To: "'aboba@internaut.com'" <aboba@internaut.com>,
"'Stephane Beaulieu'"
<stephane@cisco.com>,
"'Waters, Stephen'" <Stephen.Waters@cabletron.com>
Cc: "'ietf-ipsra@vpnc.org'" <ietf-ipsra@vpnc.org>,
"'ipsec@lists.tislabs.com'" <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: <vinod.porwal@ishoni.com>, <ipsec@lists.tislabs.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
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" <wdixon@Exchange.Microsoft.com>
To: <ipsec@lists.tislabs.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4368.3">
<TITLE>L2TP-IPSec feature list</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P><FONT SIZE=3D2 FACE=3D"Courier New">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. </FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">L2TP benefits ---------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">1) L2TP supports 4 VPN =
scenarios</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> a.) legacy client PPP =
dial to NAS - NAS PPP user auth, NAS forwards PPP through L2TP tunnel to =
L2TP gateway </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> b.) L2TP/IPSec capable =
client PPP dial to NAS - voluntary L2TP/IPSec to L2TP gateway</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> c.) L2TP/IPSec capable =
client directly on IP network - user voluntary L2TP/IPSec tunnel to L2TP =
gateway</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> d.) L2TP/IPSec gateway to =
gateway</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> (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</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New"> (1) idea =
of a user for tunnel helps scalable management of remote tunnel =
end-points via radius.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">2) can have multiple L2TP tunnel =
sessions inside 1 IPSec SA pair for efficiency</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">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.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">4) keep alives for L2TP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">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</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">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</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">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</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">8) extensibility of L2TP with =
Attrib Value (AV) pairs, avoid extending, complicating IKE key =
management protocol</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> a.) AV delivered dynamic =
redirection of gateway dest IP for global load balancing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> b.) AV delivered QOS =
values</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">9) can use IPSec tunnel and =
transport filters which apply to assigned tunnel IP address above =
L2TP/PPP interface</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> a.) enables tunnel within =
a tunnel with full interface support</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> b.) enables static =
filtering & routes applied via Radius policy to tunnel =
interfaces</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">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.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">11) more vendors testing =
L2TP/IPSec interop (14) at last bakeoff than testing XAUTH/IKECFG =
(7)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">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. </FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">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.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New"> a.) can run routing =
protocols across tunnel interoperable with other vendors</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> b.) can carry standard, =
routable IP across tunnel, e.g. multicast, broadcast, unicast IP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">14) L2TP can be used in clear =
text mode without IPSec and get all of the tunneling benefits when =
security is not a problem.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">15) Without IPSec, L2TP over IP =
can go through NATs because it uses UDP 1701.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">16) L2TP/IPSec </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">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.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">18) Most remote access =
implementations support both machine auth first with either preshared =
key, or much stronger certificate auth, then user auth</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">19) L2TP/IPSec fully replaces and =
is a superset of PPTP functionality and is much more secure</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">20) L2TP/IPSec today offers more =
features as RFC standard than IPSec tunnel mode does currently</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">21) L2TP is defined to run over =
ATM, frame relay and X.25 non-IP transports</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">22) IPSec encryption & =
integrity protection and IPCOMP can be hardware accelerated</FONT>
</P>
<BR>
<P><FONT SIZE=3D2 FACE=3D"Courier New">PPP Benefits ---------- all RFC =
standard methods, I believe</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">1) IP/DNS/WINs assignment =
through IPCP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">2) User authentication</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> a.) =
userid/password</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> b.) EAP and EAP/TLS - for =
certificate, smartcard, SecurID, token card, biometric</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">3) AAA integration - with =
existing AAA servers, RADIUS TACACS</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">4) multi-protocol support</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">5) Link layer negotiation for =
MRU (this may help in the fragmentation arena)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">6) Keepalives for both =
PPP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">7) Multilink PPP for bundling =
bandwidth</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">8) Routable interface</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">9) PPP compression</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">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 =
</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">11) supports idea of persistent =
and autostart connections, so links can come up automatically and be =
maintained</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Courier New">Wm</FONT>
</P>
<BR>
<P><I><FONT SIZE=3D1 FACE=3D"Arial">William Dixon</FONT></I>
<BR><I><FONT SIZE=3D1 FACE=3D"Arial">Program Manager - Internet Protocol =
Security</FONT></I>
<BR><I><FONT SIZE=3D1 FACE=3D"Arial">Windows Operating Systems =
Division</FONT></I>
<BR><I><FONT SIZE=3D1 FACE=3D"Arial">Microsoft Corporation</FONT></I>
<BR><I><FONT SIZE=3D1 FACE=3D"Arial">One Microsoft Way</FONT></I>
<BR><I><FONT SIZE=3D1 FACE=3D"Arial">Redmond, WA 98052-6399</FONT></I>
<BR><I><FONT SIZE=3D1 FACE=3D"Arial">Email: WDixon@microsoft.com =
(preferred), Work: 425-703-8729</FONT></I>
</P>
<P><I><FONT SIZE=3D1 FACE=3D"Arial">Newly updated Windows 2000 IPSec =
end-to-end walkthrough & mini-whitepaper (which covers IKE's use of =
certificates): <A =
HREF=3D"http://www.microsoft.com/windows2000/library/technologies/securit=
y/default.asp">http://www.microsoft.com/windows2000/library/technologies/=
security/default.asp</A> </FONT></I></P>
<BR>
</BODY>
</HTML>
------_=_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 <yael@radguard.com>
Organization: Radguard
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,hebrew
Mime-Version: 1.0
To: ipsra <ietf-ipsra@vpnc.org>
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" <Stephen.Waters@cabletron.com>
To: Yael Dayan <yael@radguard.com>
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 <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" <Stephen.Waters@cabletron.com>
To: William Dixon <wdixon@Exchange.Microsoft.com>
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 <mailto: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
<http://www.microsoft.com/windows2000/library/technologies/security/default.
asp>
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: <aboba@internaut.com>
From: "Bernard Aboba" <aboba@internaut.com>
To: "'Gallagher, Mick'" <mick.gallagher@roke.co.uk>,
"'Stephane Beaulieu'" <stephane@cisco.com>,
"'Waters, Stephen'" <Stephen.Waters@cabletron.com>
Cc: <ietf-ipsra@vpnc.org>, <ipsec@lists.tislabs.com>
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: <D76D503DE976D1119C7E00A0C944D87501CA7FC9@RSYS002A>
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: <v04220801b551a16e2c8f@[171.78.30.107]>
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" <Stephen.Waters@cabletron.com>
From: Stephen Kent <kent@bbn.com>
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 <claudio.lordello@innovation.siemens.ca>
To: aboba@internaut.com, "'Gallagher, Mick'" <mick.gallagher@roke.co.uk>,
"'Stephane Beaulieu'" <stephane@cisco.com>,
"'Waters, Stephen'"
<Stephen.Waters@cabletron.com>
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" <Mike_Borella@mw.3com.com>
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" <aboba@internaut.com> on 05/24/2000 08:38:36 AM
Please respond to aboba@internaut.com
Sent by: "Bernard Aboba" <aboba@internaut.com>
To: "'Gallagher, Mick'" <mick.gallagher@roke.co.uk>, "'Stephane Beaulieu'"
<stephane@cisco.com>, "'Waters, Stephen'" <Stephen.Waters@cabletron.com>
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 <CTrobridge@baltimore.com>
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: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Henry Spencer" <henry@spsystems.net>,
"IP Security List" <ipsec@lists.tislabs.com>
Subject: RE: Windows 2000 and Cicsco router interoperability
Date: Wed, 24 May 2000 12:38:59 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPMEGCCFAA.gwz@cisco.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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <Pine.BSI.3.91.1000522161304.13901A-100000@spsystems.net>
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).
<text deleted>
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" <skelly@redcreek.com>
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 <henry@spsystems.net>,
IP Security List <ipsec@lists.tislabs.com>
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <NDBBIHMPILAAGDHPCIOPMEGCCFAA.gwz@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Glen Zorn wrote:
<trimmed...>
> 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: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Stephen Kent" <kent@bbn.com>,
"Waters, Stephen" <Stephen.Waters@cabletron.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: L2TP+IPsec and IKE authentication
Date: Wed, 24 May 2000 14:41:31 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPOEGGCFAA.gwz@cisco.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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <v04220801b551a16e2c8f@[171.78.30.107]>
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: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Waters, Stephen" <Stephen.Waters@cabletron.com>,
"Jan Vilhuber" <vilhuber@cisco.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: PPP over IPSec (Re: Windows 2000 and Cicsco router interoperability)
Date: Wed, 24 May 2000 14:26:29 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPOEGFCFAA.gwz@cisco.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 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: <v04220806b5520273e334@[171.78.30.107]>
In-Reply-To: <NDBBIHMPILAAGDHPCIOPOEGGCFAA.gwz@cisco.com>
References: <NDBBIHMPILAAGDHPCIOPOEGGCFAA.gwz@cisco.com>
Date: Wed, 24 May 2000 18:12:22 -0400
To: <gwz@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: L2TP+IPsec and IKE authentication
Cc: <ipsec@lists.tislabs.com>
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,
> <snip>
> > 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,
<excerpt> <<snip>
</excerpt>
<excerpt>> 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.
</excerpt>
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
<italic>standards</italic> 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 <vilhuber@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: gwz@cisco.com, ipsec@lists.tislabs.com
Subject: RE: L2TP+IPsec and IKE authentication
In-Reply-To: <v04220806b5520273e334@[171.78.30.107]>
Message-ID: <Pine.SOL.3.96.1000524231806.11703C-100000@jvilhube-ss20.cisco.com>
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,
>
> > <snip>
>
>
>
> > > 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 <vilhuber@cisco.com>
To: "Scott G. Kelly" <skelly@redcreek.com>
cc: gwz@cisco.com, Henry Spencer <henry@spsystems.net>,
IP Security List <ipsec@lists.tislabs.com>
Subject: Re: Windows 2000 and Cicsco router interoperability
In-Reply-To: <392C4DF4.D6EEA3AA@redcreek.com>
Message-ID: <Pine.SOL.3.96.1000524231410.11703B-100000@jvilhube-ss20.cisco.com>
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:
>
> <trimmed...>
>
> > 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 <foo>? 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 <prateek@arx.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Cc: Amir Shahal <amir@arx.com>
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 <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Waters, Stephen" <Stephen.Waters@cabletron.com>
CC: Yael Dayan <yael@radguard.com>, 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 <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 <vilhuber@cisco.com>
To: "Scott G. Kelly" <skelly@redcreek.com>
cc: gwz@cisco.com, Henry Spencer <henry@spsystems.net>,
IP Security List <ipsec@lists.tislabs.com>
Subject: Re: Windows 2000 and Cicsco router interoperability
In-Reply-To: <392D54DE.32206B3@redcreek.com>
Message-ID: <Pine.SOL.3.96.1000525093945.12317D-100000@jvilhube-ss20.cisco.com>
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:
> <trimmed...>
> > 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 <foo>? 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" <skelly@redcreek.com>
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 <vilhuber@cisco.com>
CC: gwz@cisco.com, Henry Spencer <henry@spsystems.net>,
IP Security List <ipsec@lists.tislabs.com>
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <Pine.SOL.3.96.1000524231410.11703B-100000@jvilhube-ss20.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Jan,
Jan Vilhuber wrote:
<trimmed...>
> 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 <foo>? 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" <pcn@cisco.com>
To: "Scott G. Kelly" <skelly@redcreek.com>
cc: gwz@cisco.com, Henry Spencer <henry@spsystems.net>,
IP Security List <ipsec@lists.tislabs.com>
Subject: Re: Windows 2000 and Cicsco router interoperability
In-Reply-To: <392C4DF4.D6EEA3AA@redcreek.com>
Message-ID: <Pine.GSO.4.10.10005251004490.6648-100000@zipper.cisco.com>
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:
>
> <trimmed...>
>
> > 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" <skelly@redcreek.com>
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" <pcn@cisco.com>
CC: gwz@cisco.com, Henry Spencer <henry@spsystems.net>,
IP Security List <ipsec@lists.tislabs.com>
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <Pine.GSO.4.10.10005251004490.6648-100000@zipper.cisco.com>
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:
> >
> > <trimmed...>
> >
> > > 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" <skelly@redcreek.com>
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 <vilhuber@cisco.com>
CC: gwz@cisco.com, Henry Spencer <henry@spsystems.net>,
IP Security List <ipsec@lists.tislabs.com>
Subject: Re: Windows 2000 and Cicsco router interoperability
References: <Pine.SOL.3.96.1000525093945.12317D-100000@jvilhube-ss20.cisco.com>
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:
> > <trimmed...>
> > > 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 <foo>? 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" <wdixon@Exchange.Microsoft.com>
To: "Stephen Kent" <kent@bbn.com>, <gwz@cisco.com>
Cc: <ipsec@lists.tislabs.com>
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
<snip>=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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D395160617-25052000>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.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D395160617-25052000></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D395160617-25052000>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D395160617-25052000>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. </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D395160617-25052000></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D395160617-25052000>It's=20
not clear how long the remote access model VPN model will meet business=20
communication requirements. </SPAN></FONT><FONT color=3D#0000ff =
face=3DArial=20
size=3D2><SPAN class=3D395160617-25052000>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...</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D395160617-25052000></SPAN></FONT> </DIV></SPAN></FONT></DIV>=
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D395160617-25052000>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. </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D395160617-25052000></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D395160617-25052000>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.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D395160617-25052000></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D395160617-25052000></SPAN></FONT><FONT color=3D#0000ff =
face=3DArial=20
size=3D2><SPAN class=3D395160617-25052000>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. </SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D395160617-25052000></SPAN></FONT><FONT color=3D#0000ff =
face=3DArial=20
size=3D2><SPAN class=3D395160617-25052000></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D395160617-25052000>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.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D395160617-25052000></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D395160617-25052000></SPAN></FONT> </DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D395160617-25052000></SPAN></FONT><FONT face=3DTahoma =
size=3D2>-----Original=20
Message-----<BR><B>From:</B> Stephen Kent =
[mailto:kent@bbn.com]<BR><B>Sent:</B>=20
Wednesday, May 24, 2000 3:12 PM<BR><B>To:</B> =
gwz@cisco.com<BR><B>Cc:</B>=20
ipsec@lists.tislabs.com<BR><B>Subject:</B> RE: L2TP+IPsec and IKE=20
authentication<BR><BR></DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px"></FONT>
<P>Glen, </P><BR>
<P><snip> </P><BR><BR><BR>
<P>> So, what is disturbing </P>
<P>> about this argument is that we're making architectural =
accommodations=20
</P>
<P>> for what would normally not be subject to an IETF standard. =
This is=20
</P>
<P>> even more surprising because in most (if not all) of the other =
</P>
<P>> security standards I can think of, we are amazingly silent =
about </P>
<P>> these sorts of assurance issues. Thus I am forced to conclude =
that=20
</P>
<P>> the departure from this precedent is driven more by =
market(ing) </P>
<P>> forces than by technology or security concerns. </P><BR>
<P>God forbid we would allow reality to impinge upon the =
standardization </P>
<P>process. </P><BR>
<P>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<I> =
standards</I> need=20
not undergo the scrutiny that the IETF usually imposes on proposals, =
making=20
life easier for the developers, if not, ultimately, users. </P><BR>
<P>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. </P><BR>
<P>Steve </P></BLOCKQUOTE></BODY></HTML>
------_=_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 <wdixon@Exchange.Microsoft.com>, Stephen Kent <kent@bbn.com>,
gwz@cisco.com
From: Mark Baugher <mbaugher@passedge.com>
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 <dchen@indusriver.com>
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" <neo@silkroad.com>
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" <wdixon@Exchange.Microsoft.com>
To: "Prateek Kapadia" <prateek@arx.com>, <ipsec@lists.tislabs.com>
Cc: "Amir Shahal" <amir@arx.com>
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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4368.4">
<TITLE>RE: Configuring W2K Server in Tunnel Mode</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>Prateek, please direct all Win2k questions to the =
Windows 2000 newsgroup where our support engineers and others doing =
similar things will see it.</FONT></P>
<P><FONT SIZE=3D2>It appears to me on the inside as: =
ms.beta.win2000.networking, or it could be advertised as =
microsoft.public.win2000.networking</FONT></P>
<P><FONT SIZE=3D2>This KB article, Q252735, describes how to configure =
Win2k tunnel mode</FONT>
<BR><FONT SIZE=3D2> <A =
HREF=3D"http://support.microsoft.com/support/kb/articles/Q252/7/35.ASP?LN=
=3DEN-US&SD=3Dgn&FR=3D0">http://support.microsoft.com/support/kb/articles=
/Q252/7/35.ASP?LN=3DEN-US&SD=3Dgn&FR=3D0</A></FONT>
</P>
<P><FONT SIZE=3D2>Win2k supports address based filters only:</FONT>
<BR><FONT SIZE=3D2> <A =
HREF=3D"http://support.microsoft.com/support/kb/articles/Q248/9/83.ASP?LN=
=3DEN-US&SD=3Dgn&FR=3D0">http://support.microsoft.com/support/kb/articles=
/Q248/9/83.ASP?LN=3DEN-US&SD=3Dgn&FR=3D0</A></FONT>
</P>
<P><FONT SIZE=3D2>Use the win2k support tool command "netdiag =
/test:ipsec /v debug" to dump policy & filter state.</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Prateek Kapadia [<A =
HREF=3D"mailto:prateek@arx.com">mailto:prateek@arx.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 25, 2000 6:12 AM</FONT>
<BR><FONT SIZE=3D2>To: 'ipsec@lists.tislabs.com'</FONT>
<BR><FONT SIZE=3D2>Cc: Amir Shahal</FONT>
<BR><FONT SIZE=3D2>Subject: Configuring W2K Server in Tunnel Mode</FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=3D2>We have a W2K Server configured as a VPN Gateway on =
which we have defined</FONT>
<BR><FONT SIZE=3D2>the policy for an IPsec tunnel from the W2K machine =
to a proprietary IPsec</FONT>
<BR><FONT SIZE=3D2>gateway. However, we cannot seem to get the W2K =
server negotiate tunnel</FONT>
<BR><FONT SIZE=3D2>mode. As initiator, it just silently drops traffic. =
As responder, Phase II</FONT>
<BR><FONT SIZE=3D2>fails with the message "Expecting Transport =
Mode" in the oakley log.</FONT>
</P>
<P><FONT SIZE=3D2>The same scenario was tested at the last =
interoperability workshop where it</FONT>
<BR><FONT SIZE=3D2>worked smoothly. We presume that some vendors must =
have come across a</FONT>
<BR><FONT SIZE=3D2>similar scenario and symptoms in W2K configuration =
for IPsec</FONT>
<BR><FONT SIZE=3D2>interoperability testing. We'd appreciate any leads =
or pointers to parts of</FONT>
<BR><FONT SIZE=3D2>the configuration that we may have missed.</FONT>
</P>
<P><FONT SIZE=3D2>Thanking you in anticipation,</FONT>
<BR><FONT SIZE=3D2>Prateek & Amir</FONT>
<BR><FONT SIZE=3D2>Algorithmic Research.</FONT>
</P>
</BODY>
</HTML>
------_=_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==?= <gwen815@mail1.sjtu.edu.cn>
To: <ipsec@lists.tislabs.com>
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: <p04320304b5542fbfe4ea@[165.227.249.13]>
Date: Fri, 26 May 2000 06:44:05 -0700
To: ipsec@lists.tislabs.com
From: Paul Hoffman <phoffman@vpnc.org>
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: <http://www.ietf.org/ietf/IPR/HALL-IPSEC>. 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" <neo@silkroad.com>
From: David Chen <dchen@indusriver.com>
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" <skelly@redcreek.com>
From: David Chen <dchen@indusriver.com>
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" <john.shriver@intel.com>
To: "'Paul Hoffman'" <phoffman@vpnc.org>, 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: <http://www.ietf.org/ietf/IPR/HALL-IPSEC>. 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" <law@sgi.com>
To: "David Chen" <dchen@indusriver.com>, "Mr. Anderson" <neo@silkroad.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: Is "Denial Of Service attack" a security issue?
Date: Fri, 26 May 2000 09:14:53 -0700
Message-ID: <NBBBJGOOMDFADJDGDCPHOEKHCGAA.law@sgi.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 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" <skelly@redcreek.com>
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 <dchen@indusriver.com>
CC: "Mr. Anderson" <neo@silkroad.com>, 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" <skelly@redcreek.com>
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 <dchen@indusriver.com>
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" <skelly@redcreek.com>
From: David Chen <dchen@indusriver.com>
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 <chrisw@insight-corp.com>
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" <smb@research.att.com>
To: "Shriver, John" <john.shriver@intel.com>
Cc: "'Paul Hoffman'" <phoffman@vpnc.org>, 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 <km.ang@student.qut.edu.au>
Subject: Reasons for AH & ESP
To: ipsec@lists.tislabs.com
Message-id: <Pine.OSF.4.10.10005281122430.29651-100000@sparrow.qut.edu.au>
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 <per.persson@ausys.se>
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 <km.ang@student.qut.edu.au>, ipsec@lists.tislabs.com
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Subject: Re: Reasons for AH & ESP
In-Reply-To: <Pine.OSF.4.10.10005281122430.29651-100000@sparrow.qut.edu.
au>
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." <tporter@dtool.com>
Subject: Re: Reasons for AH & ESP
In-Reply-To: <Pine.OSF.4.10.10005281122430.29651-100000@sparrow.qut.edu.
au>
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 <joern.sierwald@F-Secure.com>
Subject: Re: Reasons for AH & ESP
In-Reply-To: <Pine.OSF.4.10.10005281122430.29651-100000@sparrow.qut.edu.
au>
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 <K.Matsuura@ccsr.cam.ac.uk>
X-Mailer: Mozilla 4.6 [ja] (Win98; I)
X-Accept-Language: ja
MIME-Version: 1.0
To: "Scott G. Kelly" <skelly@redcreek.com>
CC: David Chen <dchen@indusriver.com>, "Mr. Anderson" <neo@silkroad.com>,
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: <v04220802b5594bcb9a2e@[192.168.1.151]>
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 <rgm-sec@htt-consult.com>
From: Stephen Kent <kent@bbn.com>
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" <ipntrq@free.fr>
To: "Joern Sierwald" <joern.sierwald@F-Secure.com>, <ipsec@lists.tislabs.com>
Subject: RE: Reasons for AH & ESP
Date: Tue, 30 May 2000 22:36:16 +0200
Message-ID: <NDBBJDFPGLMLFHLNEEOMMEMKFKAA.ipntrq@free.fr>
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 <pkoning@xedia.com>
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>
<NDBBJDFPGLMLFHLNEEOMMEMKFKAA.ipntrq@free.fr>
X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "mouss" == mouss <ipntrq@free.fr> 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