From owner-ipsec@lists.tislabs.com Mon Oct 1 01:43:00 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f918h0D27863;
Mon, 1 Oct 2001 01:43:00 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA01042
Mon, 1 Oct 2001 03:31:18 -0400 (EDT)
Message-ID: <00ea01c14a4c$47441a60$cbce1dd5@mahdavi>
From: "mahdavi" <mahdavi@sepahan.iut.ac.ir>
To: "ipsec" <ipsec@lists.tislabs.com>
Subject: Excuse me. wrong mail.
Date: Mon, 1 Oct 2001 11:09:56 +0330
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_00E7_01C14A69.9A67CD00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.3825.400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.3825.400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_00E7_01C14A69.9A67CD00
Content-Type: text/plain;
charset="windows-1256"
Content-Transfer-Encoding: quoted-printable
hi all.=20
I sent a wrong mail to the group.=20
please ignore my last Email.
bye=20
many thanks before=20
------=_NextPart_000_00E7_01C14A69.9A67CD00
Content-Type: text/html;
charset="windows-1256"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1256">
<META content=3D"MSHTML 5.50.3825.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hi all. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I sent a wrong mail to the group. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>please ignore my last =
Email.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>bye </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>many thanks before </FONT></DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_00E7_01C14A69.9A67CD00--
From owner-ipsec@lists.tislabs.com Mon Oct 1 01:43:05 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f918h4D27876;
Mon, 1 Oct 2001 01:43:04 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA01035
Mon, 1 Oct 2001 03:25:08 -0400 (EDT)
Content-Type: text/plain;
charset="iso-8859-1"
From: Rajesh Bhattacharya <rajub@intotoinc.com>
Reply-To: Rajesh Bhattacharya <rajub@intotoinc.com>
Organization: Intoto Inc, india
To: ipsec@lists.tislabs.com
Subject: Initial Contact Message in IKE
Date: Mon, 1 Oct 2001 13:06:53 +0530
X-Mailer: KMail [version 1.2]
MIME-Version: 1.0
Message-Id: <01100113065302.02877@scorpio>
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Guys,
Any pointer on ike's initial contact message?
IKE or related rfcs don't give enough detail on that.
Regards,
Rajesh.
--
Rajesh Bhattacharya <rajub@intotoinc.com>
Yesterday is not ours to recover,
But today is ours to win or lose.
So let's not waste today!!
From owner-ipsec@lists.tislabs.com Mon Oct 1 05:01:35 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f91C1YD11568;
Mon, 1 Oct 2001 05:01:34 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA01280
Mon, 1 Oct 2001 06:56:02 -0400 (EDT)
Message-Id: <200110011104.HAA10805@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-cbc-02.txt
Date: Mon, 01 Oct 2001 07:04:13 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : The AES Cipher Algorithms and Their Use With IPsec
Author(s) : S. Frankel, S. Kelly, R. Glenn
Filename : draft-ietf-ipsec-ciph-aes-cbc-02.txt
Pages : 16
Date : 28-Sep-01
This document describes the use of the AES Cipher Algorithm in Cipher
Block Chaining Mode, with an explicit IV, as a confidentiality mecha-
nism within the context of the IPsec Encapsulating Security Payload
(ESP).
This Internet Draft also describes the use of the four other AES fi-
nalist candidate algorithms in the ESP Header.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-02.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-ciph-aes-cbc-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010928122510.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ciph-aes-cbc-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010928122510.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Mon Oct 1 08:15:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f91FFVD25657;
Mon, 1 Oct 2001 08:15:31 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01718
Mon, 1 Oct 2001 09:43:43 -0400 (EDT)
content-class: urn:content-classes:message
Subject: RE: Does an outbound packet need to be reroute?
Date: Mon, 1 Oct 2001 09:51:52 -0400
Message-ID: <DC504E9C3384054C8506D3E6BB01246005AFD3@bsebe001.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="gb2312"
Thread-Topic: Does an outbound packet need to be reroute?
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFIhrM1zm+04LR1EdWpWgBQi2kYTQB+Pyew
From: "Sharma Atul (NVO/Boston)" <Atul.Sharma@nokia.com>
To: <sleepy-cat@263.net>, <ipsec@lists.tislabs.com>
X-OriginalArrivalTime: 01 Oct 2001 13:51:58.0660 (UTC) FILETIME=[3D3A8840:01C14A80]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA01715
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Since there is a new IP header, a new route shall be
needed. The route can be checked evrytime or cached
with the first packet.
The selectors for the new packet shall decide whether
further IPsec processing is required or not. It may be
possible to still go for IPsec processing, if let us say
we have the case of nested tunnels.
Atul
-----Original Message-----
From: ext dxh [mailto:sleepy-cat@263.net]
Sent: Friday, September 28, 2001 8:58 PM
To: ipsec@lists.tislabs.com
Subject: Does an outbound packet need to be reroute?
Since in tunnel mode, it get a new ip header which has a
different
destination ip address. Does the packet need to be reroute to a new
interface (may be the same) and bypass this interface's ipsec
processing?
Best regard!
Dong Xiaohu
From owner-ipsec@lists.tislabs.com Mon Oct 1 08:32:15 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f91FWFD26058;
Mon, 1 Oct 2001 08:32:15 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA01734
Mon, 1 Oct 2001 09:47:56 -0400 (EDT)
Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0C5E@MAIL.NetOctave.com>
From: Mark Winstead <Mark.Winstead@NetOctave.com>
To: ipsec@lists.tislabs.com
Subject: RE: I-D ACTION:draft-ietf-ipsec-ciph-aes-cbc-02.txt
Date: Mon, 1 Oct 2001 09:54:14 -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
Paragraph 4.4.1 of this document, the table lists exponent and modulus sizes
for MODP and EC2N groups, what of ECP groups? The context suggests that
perhaps EC2N was intended to be simply EC.
Thanks
Mark Winstead
NetOctave,Inc
www.netoctave.com
-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Monday, October 01, 2001 7:04 AM
Cc: ipsec@lists.tislabs.com
Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-cbc-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Security Protocol Working Group of the
IETF.
Title : The AES Cipher Algorithms and Their Use With IPsec
Author(s) : S. Frankel, S. Kelly, R. Glenn
Filename : draft-ietf-ipsec-ciph-aes-cbc-02.txt
Pages : 16
Date : 28-Sep-01
This document describes the use of the AES Cipher Algorithm in Cipher
Block Chaining Mode, with an explicit IV, as a confidentiality mecha-
nism within the context of the IPsec Encapsulating Security Payload
(ESP).
This Internet Draft also describes the use of the four other AES fi-
nalist candidate algorithms in the ESP Header.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-02.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-ciph-aes-cbc-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
From owner-ipsec@lists.tislabs.com Mon Oct 1 14:28:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f91LSuD20638;
Mon, 1 Oct 2001 14:28:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02568
Mon, 1 Oct 2001 16:27:33 -0400 (EDT)
From: "Geoffrey Huang" <ghuang@cisco.com>
To: "Rajesh Bhattacharya" <rajub@intotoinc.com>, <ipsec@lists.tislabs.com>
Subject: RE: Initial Contact Message in IKE
Date: Mon, 1 Oct 2001 13:35:24 -0700
Message-ID: <IPEELPDEHHIGHOAKJNDKAEIJCAAA.ghuang@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)
Importance: Normal
In-Reply-To: <01100113065302.02877@scorpio>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is from RFC2407:
4.6.3.3 INITIAL-CONTACT
The INITIAL-CONTACT status message may be used when one side wishes
to inform the other that this is the first SA being established with
the remote system. The receiver of this Notification Message might
then elect to delete any existing SA's it has for the sending system
under the assumption that the sending system has rebooted and no
longer has access to the original SA's and their associated keying
material. When used, the content of the Notification Data field
SHOULD be null (i.e. the Payload Length should be set to the fixed
length of Notification Payload).
When present, the Notification Payload MUST have the following
format:
o Payload Length - set to length of payload + size of data (0)
o DOI - set to IPSEC DOI (1)
o Protocol ID - set to selected Protocol ID from chosen SA
o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies)
o Notify Message Type - set to INITIAL-CONTACT
o SPI - set to the two ISAKMP cookies
o Notification Data - <not included>
Is this not enough information?
-g
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Rajesh Bhattacharya
> Sent: Monday, October 01, 2001 12:37 AM
> To: ipsec@lists.tislabs.com
> Subject: Initial Contact Message in IKE
>
>
> Hi Guys,
>
> Any pointer on ike's initial contact message?
> IKE or related rfcs don't give enough detail on that.
>
> Regards,
> Rajesh.
> --
> Rajesh Bhattacharya <rajub@intotoinc.com>
>
> Yesterday is not ours to recover,
> But today is ours to win or lose.
> So let's not waste today!!
>
From owner-ipsec@lists.tislabs.com Mon Oct 1 17:09:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9209KD26201;
Mon, 1 Oct 2001 17:09:21 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02748
Mon, 1 Oct 2001 19:23:37 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: <joern@dfintra.f-secure.com>, <ipsec@lists.tislabs.com>
Subject: RE: AES with SHA-2
Date: Mon, 1 Oct 2001 19:30:36 -0400
Message-Id: <002101c14ad1$14537a80$1e72788a@andrewk3.ca.newbridge.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 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
In-Reply-To: <5.1.0.14.0.20010925230916.01eb4c90@dfintra.f-secure.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Well, the RFC does recommend that HMACs be truncated, so I wouldn't say that
the only advantage of sha-2 over sha-1 is the longer output. However, sha-1
does seem to be strong enough at present. As I have pointed out before,
people sometimes get too hung up on matching other algorithms to the
strength of AES. It's okay to use AES just for the added speed and not for
the (presumed) added security.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of
> joern@dfintra.f-secure.com
> Sent: Tuesday, September 25, 2001 5:17 PM
> To: ipsec@lists.tislabs.com
> Subject: Re: AES with SHA-2
>
>
> At 15:15 25.09.2001 -0400, you wrote:
>
> >Hi all&
> >
> >
> >
> > I wonder what the consensus is on using SHA-2
> with AES for
> > ESP. Are you all implementing such a transform? Do you plan to?
> >
> >
> >
> >Thanks!
> >
> >
> >
> >Josh Shaul
>
> No, we're not. What's the point of using sha-2 in ESP anyway?
> We are using a truncated (96 bits) output of sha-1 or md5 today.
> Using sha-2-96 would be utterly pointless, because the only
> advantage of sha-2 over sha-1 is the longer output.
>
> Before you plan anything, you should wonder how many bits you want.
> More than 96 bit, apparently. But how much more? Then, wouldn't
> sha-1-128 or sha-1-160 be enough for you?
>
> I'm happy with 96 bits.....
>
> Jörn Sierwald
>
>
>
>
From owner-ipsec@lists.tislabs.com Tue Oct 2 04:51:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f92BpAD21453;
Tue, 2 Oct 2001 04:51:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA03490
Tue, 2 Oct 2001 06:22:56 -0400 (EDT)
Date: Tue, 2 Oct 2001 13:19:58 +0300
To: ipsec@lists.tislabs.com
Subject: Re: Does an outbound packet need to be reroute?
Message-ID: <20011002131958.A12213@terrapin>
Mail-Followup-To: ipsec@lists.tislabs.com
References: <DC504E9C3384054C8506D3E6BB01246005AFD3@bsebe001.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <DC504E9C3384054C8506D3E6BB01246005AFD3@bsebe001.NOE.Nokia.com>
User-Agent: Mutt/1.3.22i
From: alexey.vyskubov@nokia.com (Alexey Vyskubov)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Since there is a new IP header, a new route shall be
> needed. The route can be checked evrytime or cached
> with the first packet.
>
> The selectors for the new packet shall decide whether
> further IPsec processing is required or not. It may be
> possible to still go for IPsec processing, if let us say
> we have the case of nested tunnels.
As far as I understand RFC 2401 says that only one SP should be applied
to the packet. Nested tunnels are implemented using nested SAs not SPs.
Am I wrong?
--
Alexey
From owner-ipsec@lists.tislabs.com Tue Oct 2 06:33:43 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f92DXgD04177;
Tue, 2 Oct 2001 06:33:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA03681
Tue, 2 Oct 2001 08:43:42 -0400 (EDT)
From: Steve.Robinson@psti.com
Subject: Re: Does an outbound packet need to be reroute?
To: alexey.vyskubov@nokia.com (Alexey Vyskubov)
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000
Message-ID: <OFA9EBFBD8.DCE8C2F8-ON80256AD9.00464B08@psti.com>
Date: Tue, 2 Oct 2001 08:57:01 -0400
X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at
10/02/2001 01:57:38 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
alexey.vyskubov@nok
ia.com (Alexey To: ipsec@lists.tislabs.com
Vyskubov) cc:
Sent by: Subject: Re: Does an outbound packet need to be reroute?
owner-ipsec@lists.t
islabs.com
10/02/01 06:19 AM
> Since there is a new IP header, a new route shall be
> needed. The route can be checked evrytime or cached
> with the first packet.
>
> The selectors for the new packet shall decide whether
> further IPsec processing is required or not. It may be
> possible to still go for IPsec processing, if let us say
> we have the case of nested tunnels.
As far as I understand RFC 2401 says that only one SP should be applied
to the packet. Nested tunnels are implemented using nested SAs not SPs.
Am I wrong?
Not really, but remember that a policy does not have to be a really well
defined entity. All a policy needs to do is define what behaviour you
should have while processing IP packets, that's all. So, you could easily
say that doing multiple IPsec processing using lots of different tunnels on
a single packet, and multiple SA's and SP's (depending on how your
databases are set up) is still exercising a single policy, if the behaviour
is what the system administrator intended.
Really, you don't have to use an explicit single SADB either, as long as
the behaviour of the system is correct with respect to proper packet
processing and behaviour dealing with other hosts.
Steve R.
--
Alexey
From owner-ipsec@lists.tislabs.com Tue Oct 2 08:30:15 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f92FUED11907;
Tue, 2 Oct 2001 08:30:14 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04035
Tue, 2 Oct 2001 10:23:39 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: <'=SMTP:dharkins@lounge.org'>, <'=SMTP:andrew.krywaniuk@alcatel.com'>
Cc: <'=SMTP:ipsec@lists.tislabs.com'>
Subject: RE: Notify SPI field specifications
Date: Tue, 2 Oct 2001 10:24:30 -0400
Message-Id: <000201c14b4e$abbfa380$1e72788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
In-Reply-To: <200109041732.f84HWQ000659@dharkins@lounge.orgatty.lounge.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> Which group of documents were both consolidated and split up
> to "clarify
> things"? It would be very interesting to compare the
> outcomes. A hint on
> the mindset ("reactionary and/or idealistic") for both
> outcomes would also
> be quite interesting. Please provide pointers to these documents.
I'm not talking specifically about IETF RFCs here. The document that was
both consolidated and split up wasn't an IETF RFC. I was merely commenting
that this was a fairly universal problem. There are always competing
motivations. If a document is too long then it can be hard to find the
pertinent information amidst all the clutter. On the other hand, if you
create too many small documents, then you can spend a lot of time flipping
back and forth between them. Another solution is to just make the document
shorter, in which case it is also likely to be vague.
Despite the fact that KINK was a reaction to IKE, remember that the original
charter specified that they would in effect support multiple DOIs. BTW, I
believe that the SASL charter says that they will split up the RFC into
multiple documents. And while the IPSP WG is espousing the dogma that they
can't change IKE because IKE is too complicated, they are themselves
developing two instantiations of a framework which is built upon yet another
framework.
As we know, prevailing attitudes can be very fickle. It is human nature to
believe that the grass really is greener on the other side. People tend to
upplay the problems they have right now and downplay the problems that
others had in the past. It is a well known fact that every programmer who
takes over a project always believes that the existing codebase needs to be
redesigned from scratch. And after he does this, the next programmer who
comes along believes the exact same thing. There is always a tradeoff; you
have to pick your poison. If you make a protocol too flexible, it can be
hard to implement. If you make it too specific, you will find yourself
reimplementing the same thing over and over again. Given the similarity of
the problems, I think it would be ridiculous if MSec didn't reuse most of
the existing IKE specifications.
I think if there is a single best way to organize a set of documents, it is
by target audience. I think the existing set of documents does that pretty
well, for the most part, although there is still room for improvement.
[ISAKMP] is an explanatory document which is of interest to someone who
wants to know how to design a security protocol. [DOI] takes care of some
bland housekeeping stuff that would only be of interest to an implementer.
My comment was that [IKE] does not appear to be focused on a particular
audience. It ought to be readable by someone who merely wants to use IKE and
not implement it. Merging all the documents together doesn't solve that
problem.
This philosophical discussion is a bit off-topic for the list. I don't want
to start a big debate about it. We can discuss it offline if you like.
> I don't think you understand....
>
> IKE was supposed to be a generic exchange under which
> multiple DOIs could
> be implemented. It has to create its own SA which is
> different than the
> DOI-defined SA and therefore has to be able to do this
> independent of any
> DOI. The DH groups are critical to establishing the IKE SA!
> They cannot
> just be referenced in a DOI! If there were copied from
> anywhere they were
> copied from Oakley, not ISAKMP (or even [ISAKMP]). Similarly
> the ciphers
> necessary to construct the IKE SA are defined in IKE. They
> are not "just
> referenced in the DOI".
Yes, the DH groups are copied from Oakley. But the assigned numbers in IKE
are merely distractions. I often wondered why there wasn't an ISAKMP DOI
document (or why this wasn't just a section in the IPsec DOI RFC).
The fact is, no one really wants to define a new DOI just to define a
different numbering scheme for the cryptographic algorithms. The main
benefit is the ability to add selectors or transport for non-IP packets.
Some might argue that we are the IETF, so why should we help people in
defining non-IP security, but I think that's being overly zealous.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@lounge.org]
> Sent: Tuesday, September 04, 2001 1:32 PM
> To: andrew.krywaniuk@alcatel.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Notify SPI field specifications
>
>
> On Tue, 04 Sep 2001 11:07:05 EDT you wrote
> >
> > I've seen documentation split up in order to "clarify
> things," and I've seen
> > the same documents consolidated in order to "clarify
> things." The second
> > generation of documents is rarely any better than the
> first, usually because
> > it was written with a reactionary and/or idealistic
> mindset. The same result
> > usually applies to second generation code as well, mostly
> for the same
> > reasons.
>
> Which group of documents were both consolidated and split up
> to "clarify
> things"? It would be very interesting to compare the
> outcomes. A hint on
> the mindset ("reactionary and/or idealistic") for both
> outcomes would also
> be quite interesting. Please provide pointers to these documents.
>
> > Instead of being a focused protocol description, [IKE] is
> more of a mishmash
> > of all the bits and pieces that were left open by [ISAKMP].
> Why are the DH
> > groups copied here, and not just referenced in the DOI like
> the ciphers?
>
> I don't think you understand....
>
> IKE was supposed to be a generic exchange under which
> multiple DOIs could
> be implemented. It has to create its own SA which is
> different than the
> DOI-defined SA and therefore has to be able to do this
> independent of any
> DOI. The DH groups are critical to establishing the IKE SA!
> They cannot
> just be referenced in a DOI! If there were copied from
> anywhere they were
> copied from Oakley, not ISAKMP (or even [ISAKMP]). Similarly
> the ciphers
> necessary to construct the IKE SA are defined in IKE. They
> are not "just
> referenced in the DOI".
>
> I think it is safe to say that there are more people than
> just you who did
> not or do not understand how these things were done so let me
> point out
> again that if these layers go away these misunderstandings
> about the layers
> do too.
>
> Dan.
>
> "I personally think it is very dangerous to organize
> referendums when you're not sure to win them"
> -- Louis Michel, President of the European Union
>
>
From owner-ipsec@lists.tislabs.com Tue Oct 2 11:40:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f92IegD25143;
Tue, 2 Oct 2001 11:40:42 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04651
Tue, 2 Oct 2001 13:36:01 -0400 (EDT)
To: <andrew.krywaniuk@alcatel.com>
Cc: <joern@dfintra.f-secure.com>, <ipsec@lists.tislabs.com>
Subject: Re: AES with SHA-2
References: <002101c14ad1$14537a80$1e72788a@andrewk3.ca.newbridge.com>
From: "Perry E. Metzger" <perry@piermont.com>
Date: 02 Oct 2001 13:44:18 -0400
In-Reply-To: <002101c14ad1$14537a80$1e72788a@andrewk3.ca.newbridge.com>
Message-ID: <87vghydjil.fsf@snark.piermont.com>
Lines: 11
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
"Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com> writes:
> Well, the RFC does recommend that HMACs be truncated, so I wouldn't say that
> the only advantage of sha-2 over sha-1 is the longer output.
Truncation can actually increase security against brute force attack
depending on how it is used. Mere use of truncation to the same number
of bits does not mean that SHA-1 is necessarily the same security as
the newer hashes.
Perry
From owner-ipsec@lists.tislabs.com Thu Oct 4 04:56:02 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f94Bu1D11367;
Thu, 4 Oct 2001 04:56:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08600
Thu, 4 Oct 2001 06:54:58 -0400 (EDT)
Message-Id: <200110041103.HAA05209@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-isakmp-di-mon-mib-04.txt
Date: Thu, 04 Oct 2001 07:03:15 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : ISAKMP DOI-Independent Monitoring MIB
Author(s) : T. Jenkins, J. Shriver
Filename : draft-ietf-ipsec-isakmp-di-mon-mib-04.txt
Pages : 27
Date : 03-Oct-01
This document defines a DOI (domain of interpretation) independent
monitoring MIB for ISAKMP.
The purpose of this MIB is to be used as the basis for protocol
specific MIBs that use ISAKMP as the basis for key exchanges or
security association negotiation.
As such, it has no DOI-dependent objects.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-04.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-isakmp-di-mon-mib-04.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-04.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20011003105747.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-isakmp-di-mon-mib-04.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20011003105747.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Thu Oct 4 04:56:07 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f94Bu6D11381;
Thu, 4 Oct 2001 04:56:06 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08594
Thu, 4 Oct 2001 06:54:53 -0400 (EDT)
Message-Id: <200110041103.HAA05193@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-doi-tc-mib-05.txt
Date: Thu, 04 Oct 2001 07:03:10 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : IPsec DOI Textual Conventions MIB
Author(s) : J. Shriver
Filename : draft-ietf-ipsec-doi-tc-mib-05.txt
Pages : 23
Date : 03-Oct-01
This memo defines textual conventions for use in monitoring, status,
and configuration MIBs for IPSec. It includes a MIB module that
defines those textual conventions.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-doi-tc-mib-05.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-doi-tc-mib-05.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-05.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20011003105737.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-doi-tc-mib-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-doi-tc-mib-05.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20011003105737.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Thu Oct 4 04:56:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f94BuBD11402;
Thu, 4 Oct 2001 04:56:11 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08606
Thu, 4 Oct 2001 06:55:04 -0400 (EDT)
Message-Id: <200110041103.HAA05249@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-udp-encaps-01.txt
Date: Thu, 04 Oct 2001 07:03:21 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : UDP Encapsulation of IPsec Packets
Author(s) : A. Huttunen et al.
Filename : draft-ietf-ipsec-udp-encaps-01.txt
Pages :
Date : 03-Oct-01
This draft defines methods to encapsulate and decapsulate ESP
packets inside UDP packets for the purpose of traversing NATs.
ESP encapsulation as defined in this document is capable of being
used in both IPv4 and IPv6 scenarios.
The encapsulation is used whenever negotiated using IKE, as
defined in [Kiv00], or another key management protocol. The
design choices are documented in [Dixon00].
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-01.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-udp-encaps-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20011003105756.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-udp-encaps-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-udp-encaps-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20011003105756.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Thu Oct 4 04:57:39 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f94BvcD11476;
Thu, 4 Oct 2001 04:57:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08580
Thu, 4 Oct 2001 06:54:42 -0400 (EDT)
Message-Id: <200110041102.HAA05161@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-ike-monitor-mib-03.txt
Date: Thu, 04 Oct 2001 07:02:58 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : IKE Monitoring MIB
Author(s) : T. Jenkins, J. Shriver
Filename : draft-ietf-ipsec-ike-monitor-mib-03.txt
Pages : 75
Date : 03-Oct-01
This document defines monitoring and status MIBs for use when the
(Internet Key Exchange) IKE protocol [IKE] is used to create IPsec
security associations (SAs). As such, the MIBs provide the linkage
between IKE (phase 1) SAs and the IPsec (phase 2) SAs created by
those SAs.
It does not define MIBs that may be used for configuring IPsec
implementations or for providing low-level diagnostic or debugging
information. It assumes no specific use of IPsec SAs, except that
they were created using IKE. Further, it does not provide policy
information.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-monitor-mib-03.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-ike-monitor-mib-03.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-ike-monitor-mib-03.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20011003105717.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-ike-monitor-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-ike-monitor-mib-03.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20011003105717.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Thu Oct 4 05:01:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f94C1TD11601;
Thu, 4 Oct 2001 05:01:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA08586
Thu, 4 Oct 2001 06:54:48 -0400 (EDT)
Message-Id: <200110041103.HAA05177@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-monitor-mib-05.txt
Date: Thu, 04 Oct 2001 07:03:04 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : IPSec Monitoring MIB
Author(s) : T. Jenkins, J. Shriver
Filename : draft-ietf-ipsec-monitor-mib-05.txt
Pages : 77
Date : 03-Oct-01
This document defines low level monitoring and status MIBs for IPsec
security associations (SAs). It does not define MIBs that may be used
for configuring IPsec implementations or for providing low-level
diagnostic or debugging information. It assumes no specific use of
IPsec. Further, it does not provide policy information.
The purpose of the MIBs is to allow system administrators to
determine operating conditions and perform system operational level
monitoring of the IPsec portion of their network. Statistics are
provided as well. Additionally, it may be used as the basis for
application specific MIBs for specific uses of IPsec SAs.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-monitor-mib-05.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-monitor-mib-05.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-monitor-mib-05.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20011003105727.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-monitor-mib-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-monitor-mib-05.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20011003105727.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Fri Oct 5 09:41:14 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f95GfDD05219;
Fri, 5 Oct 2001 09:41:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11388
Fri, 5 Oct 2001 11:24:00 -0400 (EDT)
Message-ID: <522FDAAFD532D511A0AB0002A51390EB2F6FBD@cat01s2.catena.com>
From: Tim Jenkins <TJenkins@Catena.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Monitor MIBs Status
Date: Fri, 5 Oct 2001 08:55:27 -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
All,
The latest versions of all monitoring MIB drafts have been submitted. These
contain very few changes from the previous versions, and are intended to
make the documents ready for last call.
Tim
From owner-ipsec@lists.tislabs.com Fri Oct 5 10:18:01 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f95HI1D06498;
Fri, 5 Oct 2001 10:18:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA11483
Fri, 5 Oct 2001 12:35:36 -0400 (EDT)
Message-Id: <3.0.3.32.20011005095011.00faed98@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Fri, 05 Oct 2001 09:50:11 -0700
To: ipsec@lists.tislabs.com
From: Alex Alten <Alten@home.com>
Subject: IPSec still too slow?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Does anyone have any real-world numbers for IPSec performance?
I just saw an article up on Network World Fusion that states
the performance drops off dramatically with large numbers of
SA's (500 in this case), basically down to simple Ethernet II
speeds (<10Mbps). Even with 6 SA's full duplex fast Ethernet
doesn't seem possible yet (at least not cheaply, under $200/NIC).
Here's the URL for the latest Network Fusion IPSec VPN review.
http://www.nwfusion.com/reviews/2001/1001rev.html
I excerpted the preformance part of the review below.
- Alex
> We ran three sets of performance numbers, evaluating behavior
> in best-case and worst-case packet flows, as well as with a
> typical Internet mix (see graphic, page 47). For the Internet
> mix, we used data collected from an Internet backbone to build
> a profile of approximately 50% small packets (96 octets or less),
> 10% large packets (1,518 octets, the Ethernet maximum transmission
> unit), 20% 576 octets (a common WAN MTU) and 20% assorted between
> 192 and 1,024 octets.
>
> We discovered that for line speeds of up to 10M bit/sec (full duplex,
> about a quarter of a DS-3/T-3 circuit), any of the products can keep
> up - but Avaya, Nortel, RapidStream and Microsoft give you excellent
> price/performance ratios.
>
> If you want to push to a full DS-3 circuit (45M bit/sec, full duplex),
> again using "real world" packet sizes, only Lucent's Access Point with
> dual cryptographic accelerators and the one-two punch of Win 2000
> combined with Intel's Pro/100S cryptographic network interface cards
> (NIC) beat the 90M bit/sec needed to handle that circuit. By adding less
> than $200 worth of hardware to our system, we drove total IPSec performance
> of Win 2000 up to more than 160M bit/sec in the best case (large packets).
> Given the low cost of Pentium-based PCs, Win 2000 Server software and the
> Intel NICs, this particular packaging achieved price/performance ratios
> between 10 and 20 times better than the other vendors'. However, we note
> that our performance tests were done with only six IPSec security
associations.
> As a central site system with 500 security associations, we saw total
> performance of our Win 2000 system drop dramatically to less than 8M bit/sec
> for the Internet mix.
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Fri Oct 5 12:49:55 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f95JnsD12566;
Fri, 5 Oct 2001 12:49:54 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11882
Fri, 5 Oct 2001 14:53:21 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: IPSec still too slow?
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Date: Fri, 5 Oct 2001 12:04:00 -0700
Message-ID: <4EBB5C35607E7F48B4AE162D956666EF7D45DB@guam.corp.axcelerant.com>
Thread-Topic: IPSec still too slow?
Thread-Index: AcFNzmjU9UAi23HYT7+XNHrdlAwchQAAYvbg
From: "Christopher Gripp" <cgripp@axcelerant.com>
To: "Alex Alten" <Alten@home.com>
Cc: <ipsec@lists.tislabs.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA11879
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Those numbers would be vendor implementation specific not related to
IPSec in general.
-----Original Message-----
From: Alex Alten [mailto:Alten@home.com]
Sent: Friday, October 05, 2001 9:50 AM
To: ipsec@lists.tislabs.com
Subject: IPSec still too slow?
Does anyone have any real-world numbers for IPSec performance?
I just saw an article up on Network World Fusion that states
the performance drops off dramatically with large numbers of
SA's (500 in this case), basically down to simple Ethernet II
speeds (<10Mbps). Even with 6 SA's full duplex fast Ethernet
doesn't seem possible yet (at least not cheaply, under $200/NIC).
Here's the URL for the latest Network Fusion IPSec VPN review.
http://www.nwfusion.com/reviews/2001/1001rev.html
I excerpted the preformance part of the review below.
- Alex
> We ran three sets of performance numbers, evaluating behavior
> in best-case and worst-case packet flows, as well as with a
> typical Internet mix (see graphic, page 47). For the Internet
> mix, we used data collected from an Internet backbone to build
> a profile of approximately 50% small packets (96 octets or less),
> 10% large packets (1,518 octets, the Ethernet maximum transmission
> unit), 20% 576 octets (a common WAN MTU) and 20% assorted between
> 192 and 1,024 octets.
>
> We discovered that for line speeds of up to 10M bit/sec (full duplex,
> about a quarter of a DS-3/T-3 circuit), any of the products can keep
> up - but Avaya, Nortel, RapidStream and Microsoft give you excellent
> price/performance ratios.
>
> If you want to push to a full DS-3 circuit (45M bit/sec, full duplex),
> again using "real world" packet sizes, only Lucent's Access Point with
> dual cryptographic accelerators and the one-two punch of Win 2000
> combined with Intel's Pro/100S cryptographic network interface cards
> (NIC) beat the 90M bit/sec needed to handle that circuit. By adding
less
> than $200 worth of hardware to our system, we drove total IPSec
performance
> of Win 2000 up to more than 160M bit/sec in the best case (large
packets).
> Given the low cost of Pentium-based PCs, Win 2000 Server software and
the
> Intel NICs, this particular packaging achieved price/performance
ratios
> between 10 and 20 times better than the other vendors'. However, we
note
> that our performance tests were done with only six IPSec security
associations.
> As a central site system with 500 security associations, we saw total
> performance of our Win 2000 system drop dramatically to less than 8M
bit/sec
> for the Internet mix.
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Fri Oct 5 13:05:54 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f95K5rD13114;
Fri, 5 Oct 2001 13:05:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11954
Fri, 5 Oct 2001 15:19:03 -0400 (EDT)
From: ji@research.att.com
Date: Fri, 5 Oct 2001 15:27:25 -0400 (EDT)
Message-Id: <200110051927.PAA03860@amontillado.research.att.com>
To: Alten@home.com, ipsec@lists.tislabs.com
Subject: Re: IPSec still too slow?
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
People who do not understand how to take and interpret performance
measurements should just shut up.
/ji
From owner-ipsec@lists.tislabs.com Fri Oct 5 14:30:33 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f95LUXD15820;
Fri, 5 Oct 2001 14:30:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA12102
Fri, 5 Oct 2001 16:19:41 -0400 (EDT)
From: "Davenport Michael" <davenport_michael@bah.com>
To: <ji@research.att.com>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: IPSec still too slow?
Date: Fri, 5 Oct 2001 16:28:03 -0400
Message-ID: <NFBBKDFGMKODILIOLBDHAEFFCGAA.davenport_michael@bah.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: <200110051927.PAA03860@amontillado.research.att.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
There is no reason to get nasty with people. If you have something
constructive to say then offer it, otherwise don't try to put people down to
boast your own intelligence - show a little professionalism. That's just
rude...
-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ji@research.att.com
Sent: Friday, October 05, 2001 3:27 PM
To: Alten@home.com; ipsec@lists.tislabs.com
Subject: Re: IPSec still too slow?
People who do not understand how to take and interpret performance
measurements should just shut up.
/ji
From owner-ipsec@lists.tislabs.com Fri Oct 5 17:01:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9601FD19972;
Fri, 5 Oct 2001 17:01:15 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12304
Fri, 5 Oct 2001 19:01:11 -0400 (EDT)
Message-Id: <3.0.3.32.20011005161540.00b82d40@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Fri, 05 Oct 2001 16:15:40 -0700
To: ji@research.att.com, ipsec@lists.tislabs.com
From: Alex Alten <Alten@home.com>
Subject: Re: IPSec still too slow?
In-Reply-To: <200110051927.PAA03860@amontillado.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dr. John Ioannidis,
I have a great deal of respect for your contributions to the Internet
community. This kind of nasty response greatly surprises me and indicates
to me that the problems with IPSec are very serious. I did not take these
numbers at face value. That is why I requested confirmation. However,
the fact of the matter is, IPSec will always be at least 10x behind the
communications price/performance curve. You, of all people, know that.
And you know that fact will eventually kill off IPSec.
- Alex
At 03:27 PM 10/5/2001 -0400, ji@research.att.com wrote:
>People who do not understand how to take and interpret performance
>measurements should just shut up.
>
>/ji
>
--
Alex Alten
Alten@Home.Com
***********************
* Just Say NO to RC4. *
***********************
From owner-ipsec@lists.tislabs.com Fri Oct 5 17:10:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f960AKD20194;
Fri, 5 Oct 2001 17:10:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12360
Fri, 5 Oct 2001 19:21:39 -0400 (EDT)
Message-Id: <5.0.0.25.0.20011005162321.00abfb20@192.168.1.10>
X-Sender: pravin@192.168.1.10
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 05 Oct 2001 16:28:37 -0700
To: "Christopher Gripp" <cgripp@axcelerant.com>, "Alex Alten" <Alten@home.com>
From: Pravin Kantak <pravin@intotoinc.com>
Subject: RE: IPSec still too slow?
Cc: <ipsec@lists.tislabs.com>
In-Reply-To: <4EBB5C35607E7F48B4AE162D956666EF7D45DB@guam.corp.axceleran
t.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
the point is: without paying a fortune, it is not possible to
deploy a system which can take full 3 digit remote users at the general
speed todays i'net connections are.
architectural suggestion with some numbers backing them, if
possible, to change this facts are anticipated in response of this post.
- pravin
At 12:04 PM 10/5/01 -0700, Christopher Gripp wrote:
>Those numbers would be vendor implementation specific not related to
>IPSec in general.
>
>-----Original Message-----
>From: Alex Alten [mailto:Alten@home.com]
>Sent: Friday, October 05, 2001 9:50 AM
>To: ipsec@lists.tislabs.com
>Subject: IPSec still too slow?
>
>
>
>Does anyone have any real-world numbers for IPSec performance?
>
>I just saw an article up on Network World Fusion that states
>the performance drops off dramatically with large numbers of
>SA's (500 in this case), basically down to simple Ethernet II
>speeds (<10Mbps). Even with 6 SA's full duplex fast Ethernet
>doesn't seem possible yet (at least not cheaply, under $200/NIC).
>
>Here's the URL for the latest Network Fusion IPSec VPN review.
>http://www.nwfusion.com/reviews/2001/1001rev.html
>
>I excerpted the preformance part of the review below.
>
>- Alex
From owner-ipsec@lists.tislabs.com Fri Oct 5 17:17:38 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f960HcD20353;
Fri, 5 Oct 2001 17:17:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12383
Fri, 5 Oct 2001 19:37:31 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Subject: RE: IPSec still too slow?
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Date: Fri, 5 Oct 2001 16:48:12 -0700
Message-ID: <4EBB5C35607E7F48B4AE162D956666EF7D45E6@guam.corp.axcelerant.com>
Thread-Topic: IPSec still too slow?
Thread-Index: AcFN9fr34a1f7EASTJ+jJwENbMAqtwAAaylw
From: "Christopher Gripp" <cgripp@axcelerant.com>
To: "Pravin Kantak" <pravin@intotoinc.com>, "Alex Alten" <Alten@home.com>
Cc: <ipsec@lists.tislabs.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id TAA12380
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I guess it depends on what one considers 'a fortune'. We have multiple
clients with multi hundreds of users on both software and hardware based
vpns without performance issues.
-----Original Message-----
From: Pravin Kantak [mailto:pravin@intotoinc.com]
Sent: Friday, October 05, 2001 4:29 PM
To: Christopher Gripp; Alex Alten
Cc: ipsec@lists.tislabs.com
Subject: RE: IPSec still too slow?
the point is: without paying a fortune, it is not possible to
deploy a system which can take full 3 digit remote users at the general
speed todays i'net connections are.
architectural suggestion with some numbers backing them, if
possible, to change this facts are anticipated in response of this post.
- pravin
At 12:04 PM 10/5/01 -0700, Christopher Gripp wrote:
>Those numbers would be vendor implementation specific not related to
>IPSec in general.
>
>-----Original Message-----
>From: Alex Alten [mailto:Alten@home.com]
>Sent: Friday, October 05, 2001 9:50 AM
>To: ipsec@lists.tislabs.com
>Subject: IPSec still too slow?
>
>
>
>Does anyone have any real-world numbers for IPSec performance?
>
>I just saw an article up on Network World Fusion that states
>the performance drops off dramatically with large numbers of
>SA's (500 in this case), basically down to simple Ethernet II
>speeds (<10Mbps). Even with 6 SA's full duplex fast Ethernet
>doesn't seem possible yet (at least not cheaply, under $200/NIC).
>
>Here's the URL for the latest Network Fusion IPSec VPN review.
>http://www.nwfusion.com/reviews/2001/1001rev.html
>
>I excerpted the preformance part of the review below.
>
>- Alex
From owner-ipsec@lists.tislabs.com Fri Oct 5 18:03:45 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9613jD21402;
Fri, 5 Oct 2001 18:03:45 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA12471
Fri, 5 Oct 2001 20:18:46 -0400 (EDT)
Date: Fri, 05 Oct 2001 17:20:34 -0700 (MST)
From: Joel M Snyder <JMS+ipsec@Opus1.COM>
Subject: RE: IPSec still too slow?
To: ipsec@lists.tislabs.com
Message-id: <01K95EUA0SZQ9ED93E@Opus1.COM>
Organization: Opus One - +1 520 324 0494
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Alex has misinterpreted what I wrote. The performance drop I
saw was exclusively with the Microsoft implementation. I only
brought that statistic out because they have such incredibly good
performance (with $90 Intel NICs) with small numbers of SAs.
I did not test all the products in that review with hundreds of
SAs, but I have tested Cisco, Nokia, and Netscreen and seen
negligible performance degradation as the size of the SPD/SAD
tables get large. In this case, I think that we're seeing an
implementation issue with the card---it's just not designed to handle
hundreds of SAs (on the other hand, it costs less than $100, so
it's really an incredible solution for some branch office environments).
In general, IPSEC performance in labs looks great because we don't
cause fragmentation. When fragmentation rears its ugly head, performance
can go to hell (or even cause connectivity failure) very quickly. Or not,
depending on the design of your application. Encryption performance is
generally not the problem.
I do get pissed off at people who throw around latency claims, though.
One major firewall vendor (who should remain nameless) claims that one
of the big advantages of co-locating the IPSEC and firewall function
inside of the same box is that two boxes add too much latency. In the
lab, even with the slowest and stupidest of VPN products, I rarely see
more than 1ms latency---completely indistinguishable across the general
purpose Internet.
http://www.nwfusion.com/reviews/2001/1001rev.html
jms
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX)
jms@Opus1.COM http://www.opus1.com/jms Opus One
From owner-ipsec@lists.tislabs.com Fri Oct 5 22:12:17 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f965CGD27436;
Fri, 5 Oct 2001 22:12:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA12701
Sat, 6 Oct 2001 00:10:55 -0400 (EDT)
Message-Id: <3.0.3.32.20011005212527.00e7b4e8@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Fri, 05 Oct 2001 21:25:27 -0700
To: Joel M Snyder <JMS+ipsec@Opus1.COM>, ipsec@lists.tislabs.com
From: Alex Alten <Alten@home.com>
Subject: RE: IPSec still too slow?
In-Reply-To: <01K95EUA0SZQ9ED93E@Opus1.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Joel are you willing to post all the raw test results to the IPSEC
mailing list? It's really hard to understand what the numbers really
mean in your article. I for one wouldn't mind if you change vendor/product
names to something like vendor A/product X (although some indication of
processor speed would help here).
What I'm looking for is raw throughput (various packet sizes), latency (SA
setup costs), error rates (%dropped packets, lost fragments), timing delays.
BTW, did you test with various legacy protocol/apps? For example did anything
break if they didn't get the expected TCP segement handed to them in the app
layer?
- Alex
At 05:20 PM 10/5/2001 -0700, Joel M Snyder wrote:
>Alex has misinterpreted what I wrote. The performance drop I
>saw was exclusively with the Microsoft implementation. I only
>brought that statistic out because they have such incredibly good
>performance (with $90 Intel NICs) with small numbers of SAs.
>
>I did not test all the products in that review with hundreds of
>SAs, but I have tested Cisco, Nokia, and Netscreen and seen
>negligible performance degradation as the size of the SPD/SAD
>tables get large. In this case, I think that we're seeing an
>implementation issue with the card---it's just not designed to handle
>hundreds of SAs (on the other hand, it costs less than $100, so
>it's really an incredible solution for some branch office environments).
>
>In general, IPSEC performance in labs looks great because we don't
>cause fragmentation. When fragmentation rears its ugly head, performance
>can go to hell (or even cause connectivity failure) very quickly. Or not,
>depending on the design of your application. Encryption performance is
>generally not the problem.
>
>I do get pissed off at people who throw around latency claims, though.
>One major firewall vendor (who should remain nameless) claims that one
>of the big advantages of co-locating the IPSEC and firewall function
>inside of the same box is that two boxes add too much latency. In the
>lab, even with the slowest and stupidest of VPN products, I rarely see
>more than 1ms latency---completely indistinguishable across the general
>purpose Internet.
>
>http://www.nwfusion.com/reviews/2001/1001rev.html
>
>jms
>
>
>Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
>Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX)
>jms@Opus1.COM http://www.opus1.com/jms Opus One
>
--
Alex Alten
Alten@Home.Com
***********************
* Just Say NO to RC4. *
***********************
From owner-ipsec@lists.tislabs.com Sat Oct 6 06:09:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f96D9TD11616;
Sat, 6 Oct 2001 06:09:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13179
Sat, 6 Oct 2001 08:09:39 -0400 (EDT)
X-Mailer: exmh version 2.1.1 10/15/1999
From: "Steven M. Bellovin" <smb@research.att.com>
To: Alex Alten <Alten@home.com>
Cc: Joel M Snyder <JMS+ipsec@Opus1.COM>, ipsec@lists.tislabs.com
Subject: Re: IPSec still too slow?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 06 Oct 2001 08:17:12 -0400
Message-Id: <20011006121718.771E97BFE@berkshire.research.att.com>
X-OriginalArrivalTime: 06 Oct 2001 14:19:44.0578 (UTC) FILETIME=[F2423220:01C14E71]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <3.0.3.32.20011005212527.00e7b4e8@mail>, Alex Alten writes:
>
>Joel are you willing to post all the raw test results to the IPSEC
>mailing list? It's really hard to understand what the numbers really
>mean in your article. I for one wouldn't mind if you change vendor/product
>names to something like vendor A/product X (although some indication of
>processor speed would help here).
>
>What I'm looking for is raw throughput (various packet sizes), latency (SA
>setup costs), error rates (%dropped packets, lost fragments), timing delays.
>
>BTW, did you test with various legacy protocol/apps? For example did anything
>break if they didn't get the expected TCP segement handed to them in the app
>layer?
Since TCP always hands a simple stream to upper layers -- error or
missing packets retransmitted -- and this happens above IPsec (and
regardless of its presence), any flaw there would be indicative of a
bug in TCP, and would have nothing to do with IPsec.
As for the question of performance -- from Joel's article, it sounds
like that hardware-based implemeentation doesn't have a large enough
cache of security associations. This isn't a surprising result for a
low-end hardware implementation. A lot may depend on the test setup.
For some comparatively casual measurements of the requirements for
cache size, see http://www.research.att.com/~smb/talks/key-agility.ps
(or http://www.research.att.com/~smb/talks/key-agility.pdf). Also see
a text version of the analysis at
http://www.research.att.com/~smb/talks/key-agility.email.txt,
which was posted to the IPsec mailing list several years ago. Although
I was mostly concerned with the cache size requirements for the
encryption engine, the measurements would apply equally well to any
other per-SA data.
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Sat Oct 6 13:00:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f96K0JD04376;
Sat, 6 Oct 2001 13:00:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13618
Sat, 6 Oct 2001 15:14:03 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
x-mimeole: Produced By Microsoft Exchange V6.0.4712.0
Subject: RE: IPSec still too slow?
Date: Sat, 6 Oct 2001 15:21:58 -0400
Message-ID: <AF2378CBE7016247BC0FD5261F1EEB2109CE77@EXCHANGE01.domain.ecutel.com>
Thread-Topic: IPSec still too slow?
Thread-Index: AcFOaXaGXXce/Za8TRqC3cT0fL5IAAAO4y7Q
From: "Qiang Zhang" <qzhang@ecutel.com>
To: <ipsec@lists.tislabs.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA13615
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Again, is it IPsec or IPSec? remember it should be IPsec?...
-----Original Message-----
From: Steven M. Bellovin [mailto:smb@research.att.com]
Sent: Saturday, October 06, 2001 7:17 AM
To: Alex Alten
Cc: Joel M Snyder; ipsec@lists.tislabs.com
Subject: Re: IPSec still too slow?
In message <3.0.3.32.20011005212527.00e7b4e8@mail>, Alex Alten writes:
>
>Joel are you willing to post all the raw test results to the IPSEC
>mailing list? It's really hard to understand what the numbers really
>mean in your article. I for one wouldn't mind if you change
vendor/product
>names to something like vendor A/product X (although some indication of
>processor speed would help here).
>
>What I'm looking for is raw throughput (various packet sizes), latency
(SA
>setup costs), error rates (%dropped packets, lost fragments), timing
delays.
>
>BTW, did you test with various legacy protocol/apps? For example did
anything
>break if they didn't get the expected TCP segement handed to them in
the app
>layer?
Since TCP always hands a simple stream to upper layers -- error or
missing packets retransmitted -- and this happens above IPsec (and
regardless of its presence), any flaw there would be indicative of a
bug in TCP, and would have nothing to do with IPsec.
As for the question of performance -- from Joel's article, it sounds
like that hardware-based implemeentation doesn't have a large enough
cache of security associations. This isn't a surprising result for a
low-end hardware implementation. A lot may depend on the test setup.
For some comparatively casual measurements of the requirements for
cache size, see http://www.research.att.com/~smb/talks/key-agility.ps
(or http://www.research.att.com/~smb/talks/key-agility.pdf). Also see
a text version of the analysis at
http://www.research.att.com/~smb/talks/key-agility.email.txt,
which was posted to the IPsec mailing list several years ago. Although
I was mostly concerned with the cache size requirements for the
encryption engine, the measurements would apply equally well to any
other per-SA data.
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at
http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Sat Oct 6 13:00:22 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f96K0LD04387;
Sat, 6 Oct 2001 13:00:21 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13575
Sat, 6 Oct 2001 14:53:19 -0400 (EDT)
Message-ID: <3BBF54EA.BC336475@americasm01.nt.com>
Date: Sat, 06 Oct 2001 15:00:58 -0400
From: "Wei-Jen Yeh" <weijyeh@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.10.20 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: "Steven M. Bellovin" <smb@research.att.com>
CC: Alex Alten <Alten@home.com>, Joel M Snyder <JMS+ipsec@Opus1.COM>,
ipsec@lists.tislabs.com
Subject: Re: IPSec still too slow?
References: <20011006121718.771E97BFE@berkshire.research.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Steve is correct on the TCP issue. One additional minor issue to TCP&IPSec is
the connection set-up delay/retransmission related to SA negotiation.
As for degradation seen with increased number of SAs, I can think of a few possible
explanations...
1. granularity of resource locks on SADB or similar data structs
2. SADB (input and output) management scheme
3. timer system issues
4. size of hardware context memory on the crypto board itself
5. size of `hardware session' memory on the host
#4/#5 above may be the cache issue that Steve referred to.
--Wei Jen
"Steven M. Bellovin" wrote:
>
> In message <3.0.3.32.20011005212527.00e7b4e8@mail>, Alex Alten writes:
> >
> >Joel are you willing to post all the raw test results to the IPSEC
> >mailing list? It's really hard to understand what the numbers really
> >mean in your article. I for one wouldn't mind if you change vendor/product
> >names to something like vendor A/product X (although some indication of
> >processor speed would help here).
> >
> >What I'm looking for is raw throughput (various packet sizes), latency (SA
> >setup costs), error rates (%dropped packets, lost fragments), timing delays.
> >
> >BTW, did you test with various legacy protocol/apps? For example did anything
> >break if they didn't get the expected TCP segement handed to them in the app
> >layer?
>
> Since TCP always hands a simple stream to upper layers -- error or
> missing packets retransmitted -- and this happens above IPsec (and
> regardless of its presence), any flaw there would be indicative of a
> bug in TCP, and would have nothing to do with IPsec.
>
> As for the question of performance -- from Joel's article, it sounds
> like that hardware-based implemeentation doesn't have a large enough
> cache of security associations. This isn't a surprising result for a
> low-end hardware implementation. A lot may depend on the test setup.
> For some comparatively casual measurements of the requirements for
> cache size, see http://www.research.att.com/~smb/talks/key-agility.ps
> (or http://www.research.att.com/~smb/talks/key-agility.pdf). Also see
> a text version of the analysis at
> http://www.research.att.com/~smb/talks/key-agility.email.txt,
> which was posted to the IPsec mailing list several years ago. Although
> I was mostly concerned with the cache size requirements for the
> encryption engine, the measurements would apply equally well to any
> other per-SA data.
>
> --Steve Bellovin, http://www.research.att.com/~smb
> Full text of "Firewalls" book now at http://www.wilyhacker.com
--
Wei-Jen Yeh
weijyeh@nortelnetworks.com Nortel, RTP, NC
Office Phone: (919) 991-2707, ESN: 35-12707
Fax: (919) 991-8073
From owner-ipsec@lists.tislabs.com Sat Oct 6 16:14:00 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f96NDxD07956;
Sat, 6 Oct 2001 16:13:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13847
Sat, 6 Oct 2001 18:22:41 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011006152013.0358ded8@mira-sjcd-4.cisco.com>
X-Sender: ntimms@mira-sjcd-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 06 Oct 2001 15:29:41 -0700
To: Alex Alten <Alten@home.com>, Joel M Snyder <JMS+ipsec@Opus1.COM>,
ipsec@lists.tislabs.com
From: Natalie Timms <ntimms@cisco.com>
Subject: RE: IPSec still too slow?
In-Reply-To: <3.0.3.32.20011005212527.00e7b4e8@mail>
References: <01K95EUA0SZQ9ED93E@Opus1.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I just wanted to let you all know (sorry to those not particularly interested), that the Cisco 7140 numbers are inaccurate due to a miss-configuration of the device. The 42 Mb/sec quoted is less than half of what this device is capable of. Although this much throughput running process switching only actually rocks, its not what we'd be recommending to customers!
In our own internal testing we've found that raw throughput tests are somewhat meaningless as they are not indicative of the real world. It would be great to see stats based on other things running on the box - firewalling, NAT, keepalives, routing, etc.....
-Natalie
At 09:25 PM 10/5/2001 -0700, Alex Alten wrote:
>Joel are you willing to post all the raw test results to the IPSEC
>mailing list? It's really hard to understand what the numbers really
>mean in your article. I for one wouldn't mind if you change vendor/product
>names to something like vendor A/product X (although some indication of
>processor speed would help here).
>
>What I'm looking for is raw throughput (various packet sizes), latency (SA
>setup costs), error rates (%dropped packets, lost fragments), timing delays.
>
>BTW, did you test with various legacy protocol/apps? For example did anything
>break if they didn't get the expected TCP segement handed to them in the app
>layer?
>
>- Alex
>
>
>At 05:20 PM 10/5/2001 -0700, Joel M Snyder wrote:
>>Alex has misinterpreted what I wrote. The performance drop I
>>saw was exclusively with the Microsoft implementation. I only
>>brought that statistic out because they have such incredibly good
>>performance (with $90 Intel NICs) with small numbers of SAs.
>>
>>I did not test all the products in that review with hundreds of
>>SAs, but I have tested Cisco, Nokia, and Netscreen and seen
>>negligible performance degradation as the size of the SPD/SAD
>>tables get large. In this case, I think that we're seeing an
>>implementation issue with the card---it's just not designed to handle
>>hundreds of SAs (on the other hand, it costs less than $100, so
>>it's really an incredible solution for some branch office environments).
>>
>>In general, IPSEC performance in labs looks great because we don't
>>cause fragmentation. When fragmentation rears its ugly head, performance
>>can go to hell (or even cause connectivity failure) very quickly. Or not,
>>depending on the design of your application. Encryption performance is
>>generally not the problem.
>>
>>I do get pissed off at people who throw around latency claims, though.
>>One major firewall vendor (who should remain nameless) claims that one
>>of the big advantages of co-locating the IPSEC and firewall function
>>inside of the same box is that two boxes add too much latency. In the
>>lab, even with the slowest and stupidest of VPN products, I rarely see
>>more than 1ms latency---completely indistinguishable across the general
>>purpose Internet.
>>
>>http://www.nwfusion.com/reviews/2001/1001rev.html
>>
>>jms
>>
>>
>>Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
>>Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX)
>>jms@Opus1.COM http://www.opus1.com/jms Opus One
>>
>--
>
>Alex Alten
>Alten@Home.Com
>
>***********************
>* Just Say NO to RC4. *
>***********************
--------------------------------------------------------------------------------------
Natalie Timms Ph Office : 408 527 5114
Technical Leader Email : ntimms@cisco.com
Strategic VPN Projects
VSEC BU Pager : 1 800 365 4578 or
Cisco Systems ntimms@epage.cisco.com
---------------------------------------------------------------------------------------
From owner-ipsec@lists.tislabs.com Sun Oct 7 14:23:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f97LNFD22598;
Sun, 7 Oct 2001 14:23:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15263
Sun, 7 Oct 2001 16:06:06 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
Content-Class: urn:content-classes:message
Subject: RE: IPSec still too slow?
Date: Sun, 7 Oct 2001 13:06:09 -0700
Message-ID: <2E33960095B58E40A4D3345AB9F65EC102EE6816@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: IPSec still too slow?
Thread-Index: AcFOuJVh6XkgDUu6RCS1QQWWR0W5MgAq3QLg
From: "William Dixon" <wdixon@windows.microsoft.com>
To: "Natalie Timms" <ntimms@cisco.com>, "Alex Alten" <Alten@home.com>,
"Joel M Snyder" <JMS+ipsec@Opus1.COM>, <ipsec@lists.tislabs.com>
X-OriginalArrivalTime: 07 Oct 2001 20:06:10.0001 (UTC) FILETIME=[81BFCC10:01C14F6B]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
We all have probably suffered the custom crafted perf study - either
from competition or laymen. I'd suggest that we (vendors at least) need
an equivalent to the web perf metrics like SPECWEB, WEBCAT, etc - a well
defined and peer-reviewed performance study technique for IPsec
transport mode client-server, and IPSec tunnel mode gw-to-gw that could
be applied across all implementations. Could we take one of the web
metrics and define the details of the IPsec policies under it ? I'd
think the gw-to-gw tunnel products would need something of their own.
Some Windows 2000 comments:
The scaling of hardware acceleration performance cited for Windows 2000
is partly due to how the offload NIC vendor decides to manage the
in-hardware SA state. Windows 2000 itself will offload to hardware as
many IPsec SA pairs as the NIC driver will accept. How the NIC driver
and it's hardware manage that state is transparent to the Win2k ipsec
driver. Each offload vendor has a different driver<->NIC offload
design. Each offload design will result in different performance
results on the same Win2k system. And of course both Intel and 3Com
have "client" and "server" versions of their NICs.
Win2k dependent issues for scaling perf are the number of different
filters in the filter list, and number of active SAs, and CPU. Of
course the application data flow across all active SAs determines how
much the host CPU is needed. Since we idle IPsec SAs out by default at
5 minutes (configurable), scaling again depends also on the application
traffic pattern. The implementation choice of IKE as a non-kernel mode
IPsec SA manager, combined with relative-to-data-rate short IPsec SA
lifetimes may impact scaling as well. Certainly the choice of
encryption and hash algorithms matters. An IPsec policy may specify
filters that are all traffic or port specific or with actions to permit,
block, or secure.
Ultimately, this means observable perf for a deployment depends exactly
on the hw config, the IPsec policy config and the apps.
Wm
Program Manager, network security, IPsec
Windows OS Division
-----Original Message-----
From: Natalie Timms [mailto:ntimms@cisco.com]
Sent: Saturday, October 06, 2001 3:30 PM
To: Alex Alten; Joel M Snyder; ipsec@lists.tislabs.com
Subject: RE: IPSec still too slow?
I just wanted to let you all know (sorry to those not particularly
interested), that the Cisco 7140 numbers are inaccurate due to a
miss-configuration of the device. The 42 Mb/sec quoted is less than half
of what this device is capable of. Although this much throughput running
process switching only actually rocks, its not what we'd be recommending
to customers!
In our own internal testing we've found that raw throughput tests are
somewhat meaningless as they are not indicative of the real world. It
would be great to see stats based on other things running on the box -
firewalling, NAT, keepalives, routing, etc.....
-Natalie
At 09:25 PM 10/5/2001 -0700, Alex Alten wrote:
>Joel are you willing to post all the raw test results to the IPSEC
>mailing list? It's really hard to understand what the numbers really
>mean in your article. I for one wouldn't mind if you change
>vendor/product names to something like vendor A/product X (although
>some indication of processor speed would help here).
>
>What I'm looking for is raw throughput (various packet sizes), latency
>(SA
>setup costs), error rates (%dropped packets, lost fragments), timing
delays.
>
>BTW, did you test with various legacy protocol/apps? For example did
>anything break if they didn't get the expected TCP segement handed to
>them in the app layer?
>
>- Alex
>
>
>At 05:20 PM 10/5/2001 -0700, Joel M Snyder wrote:
>>Alex has misinterpreted what I wrote. The performance drop I
>>saw was exclusively with the Microsoft implementation. I only
>>brought that statistic out because they have such incredibly good
>>performance (with $90 Intel NICs) with small numbers of SAs.
>>
>>I did not test all the products in that review with hundreds of SAs,
>>but I have tested Cisco, Nokia, and Netscreen and seen negligible
>>performance degradation as the size of the SPD/SAD tables get large.
>>In this case, I think that we're seeing an implementation issue with
>>the card---it's just not designed to handle hundreds of SAs (on the
>>other hand, it costs less than $100, so it's really an incredible
>>solution for some branch office environments).
>>
>>In general, IPSEC performance in labs looks great because we don't
>>cause fragmentation. When fragmentation rears its ugly head,
>>performance can go to hell (or even cause connectivity failure) very
>>quickly. Or not, depending on the design of your application.
>>Encryption performance is generally not the problem.
>>
>>I do get pissed off at people who throw around latency claims, though.
>>One major firewall vendor (who should remain nameless) claims that one
>>of the big advantages of co-locating the IPSEC and firewall function
>>inside of the same box is that two boxes add too much latency. In the
>>lab, even with the slowest and stupidest of VPN products, I rarely see
>>more than 1ms latency---completely indistinguishable across the
>>general purpose Internet.
>>
>>http://www.nwfusion.com/reviews/2001/1001rev.html
>>
>>jms
>>
>>
>>Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
>>Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX)
>>jms@Opus1.COM http://www.opus1.com/jms Opus One
>>
>--
>
>Alex Alten
>Alten@Home.Com
>
>***********************
>* Just Say NO to RC4. *
>***********************
------------------------------------------------------------------------
--------------
Natalie Timms Ph Office : 408 527 5114
Technical Leader Email : ntimms@cisco.com
Strategic VPN Projects
VSEC BU Pager : 1 800 365 4578 or
Cisco Systems ntimms@epage.cisco.com
------------------------------------------------------------------------
---------------
From owner-ipsec@lists.tislabs.com Sun Oct 7 18:14:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f981EuD26335;
Sun, 7 Oct 2001 18:14:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA15459
Sun, 7 Oct 2001 20:19:48 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011007201949.00b8f008@dingdong.cisco.com>
X-Sender: snsrao@dingdong.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 07 Oct 2001 20:24:26 -0400
To: ji@research.att.com
From: Suresh Subbarao <snsrao@cisco.com>
Subject: RE: IPSec still too slow?
Cc: <ipsec@lists.tislabs.com>
In-Reply-To: <NFBBKDFGMKODILIOLBDHAEFFCGAA.davenport_michael@bah.com>
References: <200110051927.PAA03860@amontillado.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I agree with Mike. The question was *not* directed specifically to you and
you are under no obligation to respond; however, you do have an obligation
to be civil. Please refrain from such boorish behavior.
At 04:28 PM 10/5/2001 -0400, Davenport Michael wrote:
>There is no reason to get nasty with people. If you have something
>constructive to say then offer it, otherwise don't try to put people down to
>boast your own intelligence - show a little professionalism. That's just
>rude...
>
>-----Original Message-----
>From: owner-ipsec@lists.tislabs.com
>[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ji@research.att.com
>Sent: Friday, October 05, 2001 3:27 PM
>To: Alten@home.com; ipsec@lists.tislabs.com
>Subject: Re: IPSec still too slow?
>
>
>People who do not understand how to take and interpret performance
>measurements should just shut up.
>
>/ji
From owner-ipsec@lists.tislabs.com Mon Oct 8 06:57:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f98DvSD23746;
Mon, 8 Oct 2001 06:57:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA16364
Mon, 8 Oct 2001 08:59:34 -0400 (EDT)
Date: Fri, 05 Oct 2001 11:34:18 -0700
From: Joel Snyder <Joel.Snyder@Opus1.COM>
Subject: Re: IPSec still too slow?
To: Alex Alten <Alten@home.com>
Cc: ipsec@lists.tislabs.com
Message-id: <3BBDFD2B.8FBD643E@opus1.com>
Organization: Opus One
MIME-version: 1.0
X-Mailer: Mozilla 4.77 (Macintosh; U; PPC)
Content-type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=sha1; boundary="------------ms0397EF80FA2DFB2712284A62"
X-Accept-Language: en
References: <3.0.3.32.20011005095011.00faed98@mail>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a cryptographically signed message in MIME format.
--------------ms0397EF80FA2DFB2712284A62
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
You may be misinterpreting those numbers. The slow-down ONLY occurred
with the Microsoft product. I didn't test all the other products with
that many SAs, but I have done testing with Cisco, Nokia, and NetScreen
which shows very low slow-down as the number of SAs rises.
None of this solves the fragementation problem, of course, which will
dramatically affect 'real world' performance. The numbers you see below
are all using 1440 octet packets.
jms
Alex Alten wrote:
>
> Does anyone have any real-world numbers for IPSec performance?
>
> I just saw an article up on Network World Fusion that states
> the performance drops off dramatically with large numbers of
> SA's (500 in this case), basically down to simple Ethernet II
> speeds (<10Mbps). Even with 6 SA's full duplex fast Ethernet
> doesn't seem possible yet (at least not cheaply, under $200/NIC).
>
> Here's the URL for the latest Network Fusion IPSec VPN review.
> http://www.nwfusion.com/reviews/2001/1001rev.html
>
> I excerpted the preformance part of the review below.
>
> - Alex
>
> > We ran three sets of performance numbers, evaluating behavior
> > in best-case and worst-case packet flows, as well as with a
> > typical Internet mix (see graphic, page 47). For the Internet
> > mix, we used data collected from an Internet backbone to build
> > a profile of approximately 50% small packets (96 octets or less),
> > 10% large packets (1,518 octets, the Ethernet maximum transmission
> > unit), 20% 576 octets (a common WAN MTU) and 20% assorted between
> > 192 and 1,024 octets.
> >
> > We discovered that for line speeds of up to 10M bit/sec (full duplex,
> > about a quarter of a DS-3/T-3 circuit), any of the products can keep
> > up - but Avaya, Nortel, RapidStream and Microsoft give you excellent
> > price/performance ratios.
> >
> > If you want to push to a full DS-3 circuit (45M bit/sec, full duplex),
> > again using "real world" packet sizes, only Lucent's Access Point with
> > dual cryptographic accelerators and the one-two punch of Win 2000
> > combined with Intel's Pro/100S cryptographic network interface cards
> > (NIC) beat the 90M bit/sec needed to handle that circuit. By adding less
> > than $200 worth of hardware to our system, we drove total IPSec performance
> > of Win 2000 up to more than 160M bit/sec in the best case (large packets).
> > Given the low cost of Pentium-based PCs, Win 2000 Server software and the
> > Intel NICs, this particular packaging achieved price/performance ratios
> > between 10 and 20 times better than the other vendors'. However, we note
> > that our performance tests were done with only six IPSec security
> associations.
> > As a central site system with 500 security associations, we saw total
> > performance of our Win 2000 system drop dramatically to less than 8M bit/sec
> > for the Internet mix.
>
> --
>
> Alex Alten
>
> Alten@Home.Com
--------------ms0397EF80FA2DFB2712284A62
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIDwYJKoZIhvcNAQcCoIIIADCCB/wCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeIwggKxMIICGqADAgECAgMEn8swDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA0MTcyMTIxMjVaFw0wMjA0MTcyMTIxMjVa
MGUxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxJDAiBgkqhkiG9w0BCQEWFUpv
ZWwuU255ZGVyQE9wdXMxLkNPTTEcMBoGCSqGSIb3DQEJARYNam1zQG9wdXMxLmNvbTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAztQImTggsNj0jzqWit2QLeDn7yblZtCrVSbx+SSR
EnrHzy0vTinr7KnIVn9yOojf4Z1OKqKfNtw245p2HGAzeDceXIjuogpPCV71eOXrPEkAmHSC
OoY/MNzOihQWRAP9NerDVRg6rp3VaFKWqyYMEI/9mv9yOQJFGZ25JI+vdz8CAwEAAaNBMD8w
LwYDVR0RBCgwJoEVSm9lbC5TbnlkZXJAT3B1czEuQ09NgQ1qbXNAb3B1czEuY29tMAwGA1Ud
EwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAq+tjn2/B4BsyX7vkbcUdaHLdVCN+Jb59ZDCM
k0Tn/9gYT1nRu8OM4ZJGH7nmM4rBopxIxSdYDxig0Kd7mITNEqBsm5UiSwSfhyhMKsi7mk0M
EeeNWOXaUEO0KHgq31a+kBDI0wZ/G0R5vVKtxBDpzP3gF2MfkAfMoh5VHGanWSEwggMpMIIC
kqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz
dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0
aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQD
ExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFs
LWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB
kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU
b3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgw
JgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRv
MLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AY
A6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAg
pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADAL
BgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kN
aiYqYoQfuIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4
tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gxggH1
MIIB8QIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG
A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl
IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgME
n8swCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0wMTEwMDUxODM0MThaMCMGCSqGSIb3DQEJBDEWBBTEpJn0oTpkcnFl1J6b/56kdqXQ
lTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC
BzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgAibBMF0
UQr1vh6RGXW50V8sAd5J7WYPNjhzfLLY9MMjsOVhPn57+7lstjE45TO2fCuMPwr42OQEdP48
DLGTJtK/G+suAyOiXnjj864IOkJyklMvzfInalkhFFq/sDgJiZnoHAXnLhTco+S7G3Cyn9eM
m51a7SbL4TkcZYz7XddZ
--------------ms0397EF80FA2DFB2712284A62--
From owner-ipsec@lists.tislabs.com Mon Oct 8 06:57:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f98DvSD23745;
Mon, 8 Oct 2001 06:57:28 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16376
Mon, 8 Oct 2001 09:00:35 -0400 (EDT)
Message-Id: <200110052324.f95NOg228203@coredump.cs.columbia.edu>
X-Mailer: exmh version 2.0.2 2/24/98
To: Alex Alten <Alten@home.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: IPSec still too slow?
In-reply-to: Your message of "Fri, 05 Oct 2001 16:15:40 PDT."
<3.0.3.32.20011005161540.00b82d40@mail>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 05 Oct 2001 19:24:42 -0400
From: "Angelos D. Keromytis" <angelos@cs.columbia.edu>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <3.0.3.32.20011005161540.00b82d40@mail>, Alex Alten writes:
>Dr. John Ioannidis,
>
>I have a great deal of respect for your contributions to the Internet
>community. This kind of nasty response greatly surprises me and indicates
>to me that the problems with IPSec are very serious. I did not take these
>numbers at face value. That is why I requested confirmation. However,
>the fact of the matter is, IPSec will always be at least 10x behind the
>communications price/performance curve. You, of all people, know that.
>And you know that fact will eventually kill off IPSec.
Fortunately, some people factor *security* in their price/performance curve.
Sure, if you want the highest possible throughput AND you're not worried about
attacks on your communication links, you don't need IPsec (or any other security
protocol).
If you *are* worried about the security of your traffic, your curve is no longer
the same.
That said: I can easily achieve more than 200 Mbit/sec throughput (on a Gbit
ethernet; on a 100Mbit, I simply saturate it) with a $300 PCI crypto
accelerator on OpenBSD. There are ethernet/ IPsec combo cards (I know of at
least one, with another one possibly under development) that can easily handle
100Mbit full duplex. And these leave the host machine (server) virtually idle.
As to the magic number of 6 SAs, I can't figure out why that is so; most crypto
cards either have enough memory for over 100 SAs, or don't need to cache
key context (the 200Mbit/s card is one of the latter). For those that do need
key context kept on the card, it's just a matter of more memory --- hardly an
architectural problem with IPsec.
The more important problems are elsewhere: how much state does a server need to
keep per SA (busy web servers might be overwhelmed this way); and how many
public key operations are needed per SA (this is a function of certificates).
Some public key crypto accelerators claim to achieve close to 1000 RSA sign/
verify cycles/second --- somewhat less if one adds a DH exchange; I haven't
personally measured this, but I expect the real performance to be close to
the marketing performance :-)
Finally, as others pointed out, there's nothing inherent in IPsec that makes it
slower compared to other security protocols. Crypto is just slow.
Before posting random-looking numbers on a technical mailing list, it's good
to consider what the numbers mean. That was JI's point, even if he put it a
bit forcefully :-)
-Angelos
From owner-ipsec@lists.tislabs.com Mon Oct 8 06:57:33 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f98DvWD23770;
Mon, 8 Oct 2001 06:57:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16375
Mon, 8 Oct 2001 09:00:35 -0400 (EDT)
Date: Sat, 06 Oct 2001 17:40:30 -0700
From: Joel Snyder <Joel.Snyder@Opus1.COM>
Subject: Re: IPSec still too slow?
To: ipsec@lists.tislabs.com
Cc: Natalie Timms <ntimms@cisco.com>
Message-id: <3BBFA47E.A2EF9325@opus1.com>
Organization: Opus One
MIME-version: 1.0
X-Mailer: Mozilla 4.78C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <01K95EUA0SZQ9ED93E@Opus1.COM>
<4.3.2.7.2.20011006152013.0358ded8@mira-sjcd-4.cisco.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
"inaccurate" is ... well, "inaccurate." The numbers are perfectly
correct and represent the actual thruput of the 7140 as configured by an
experienced Cisco-employed engineer at our site. There is no
inaccuracy.
It may possibly be true that there are other configurations of the
device which will present different thruput numbers, both faster and
slower. However, the numbers in that article are by no means
inaccurate.
It is perhaps a reaffirmation of my point about the complexity and
difficulty of configuring and managing Cisco VPN configurations that the
device, as it comes out of the box, does not offer the end user optimal
performance.
In short, the numbers are perfectly correct and accurate; they represent
a perfectly correct and valid configuration.
It may also be true that there are other perfectly correct and valid
configurations which offer greater thruput and have the same security
parameters and functionality.
The point of the very basic raw testing done in that article was to
offer a baseline apples-to-apples comparison which would let buyers
scale whatever the vendors actually claim versus reality in order to
compare real system thruput. By offering a baseline from which vendor
numbers can be scaled up or down, all the vendors who participated have
at least put themselves on an equal footing.
For example, Cisco commonly promises lower throughput than their devices
are capable of doing, probably as a conservative approach to network
engineering and management. Other vendors offer the highest possible
numbers to make themselves look good. With the research in that article
at hand, a buyer can properly scale things so that different vendor
performance numbers can at least be put into the same ballpark of
relevence.
I agree totally that raw throughput numbers are only a part of the whole
picture and that other features of the product will vary performance.
This is why end user organizations must test products _in situ_ to see
real performance. Given that of the 13 products tested no two have the
same functionality, it is simply impossible to come up with any more
complex benchmark that is applicable across more than two or three
products.
jms
Natalie Timms wrote:
>
> I just wanted to let you all know (sorry to those not particularly interested), that the Cisco 7140 numbers are inaccurate due to a miss-configuration of the device. The 42 Mb/sec quoted is less than half of what this device is capable of. Although this much throughput running process switching only actually rocks, its not what we'd be recommending to customers!
>
> In our own internal testing we've found that raw throughput tests are somewhat meaningless as they are not indicative of the real world. It would be great to see stats based on other things running on the box - firewalling, NAT, keepalives, routing, etc.....
>
> -Natalie
>
> At 09:25 PM 10/5/2001 -0700, Alex Alten wrote:
>
> >Joel are you willing to post all the raw test results to the IPSEC
> >mailing list? It's really hard to understand what the numbers really
> >mean in your article. I for one wouldn't mind if you change vendor/product
> >names to something like vendor A/product X (although some indication of
> >processor speed would help here).
> >
> >What I'm looking for is raw throughput (various packet sizes), latency (SA
> >setup costs), error rates (%dropped packets, lost fragments), timing delays.
> >
> >BTW, did you test with various legacy protocol/apps? For example did anything
> >break if they didn't get the expected TCP segement handed to them in the app
> >layer?
> >
> >- Alex
> >
> >
> >At 05:20 PM 10/5/2001 -0700, Joel M Snyder wrote:
> >>Alex has misinterpreted what I wrote. The performance drop I
> >>saw was exclusively with the Microsoft implementation. I only
> >>brought that statistic out because they have such incredibly good
> >>performance (with $90 Intel NICs) with small numbers of SAs.
> >>
> >>I did not test all the products in that review with hundreds of
> >>SAs, but I have tested Cisco, Nokia, and Netscreen and seen
> >>negligible performance degradation as the size of the SPD/SAD
> >>tables get large. In this case, I think that we're seeing an
> >>implementation issue with the card---it's just not designed to handle
> >>hundreds of SAs (on the other hand, it costs less than $100, so
> >>it's really an incredible solution for some branch office environments).
> >>
> >>In general, IPSEC performance in labs looks great because we don't
> >>cause fragmentation. When fragmentation rears its ugly head, performance
> >>can go to hell (or even cause connectivity failure) very quickly. Or not,
> >>depending on the design of your application. Encryption performance is
> >>generally not the problem.
> >>
> >>I do get pissed off at people who throw around latency claims, though.
> >>One major firewall vendor (who should remain nameless) claims that one
> >>of the big advantages of co-locating the IPSEC and firewall function
> >>inside of the same box is that two boxes add too much latency. In the
> >>lab, even with the slowest and stupidest of VPN products, I rarely see
> >>more than 1ms latency---completely indistinguishable across the general
> >>purpose Internet.
> >>
> >>http://www.nwfusion.com/reviews/2001/1001rev.html
> >>
> >>jms
> >>
> >>
> >>Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
> >>Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX)
> >>jms@Opus1.COM http://www.opus1.com/jms Opus One
> >>
> >--
> >
> >Alex Alten
> >Alten@Home.Com
> >
> >***********************
> >* Just Say NO to RC4. *
> >***********************
>
> --------------------------------------------------------------------------------------
> Natalie Timms Ph Office : 408 527 5114
> Technical Leader Email : ntimms@cisco.com
> Strategic VPN Projects
> VSEC BU Pager : 1 800 365 4578 or
> Cisco Systems ntimms@epage.cisco.com
> ---------------------------------------------------------------------------------------
--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
+1 520 324 0494 x101 (voice) +1 520 324 0495 (FAX)
jms@Opus1.COM http://www.opus1.com/jms Opus One
Electronic mail is always the best way to contact me.
From owner-ipsec@lists.tislabs.com Mon Oct 8 07:34:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f98EYqD24589;
Mon, 8 Oct 2001 07:34:52 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16680
Mon, 8 Oct 2001 09:49:24 -0400 (EDT)
Message-Id: <200110081357.JAA21819@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-jenkins-ipsec-tun-mon-mib-00.txt
Date: Mon, 08 Oct 2001 09:57:44 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : IPsec Tunnel Monitoring MIB
Author(s) : T. Jenkins
Filename : draft-jenkins-ipsec-tun-mon-mib-00.txt
Pages : 52
Date : 05-Oct-01
This document defines monitoring and status MIBs for specific
applications of IPsec's security associations (SAs). The specific
applications are for the purposes of virtual private networking (VPN)
and secure remote access (SRA) applications. The MIB allows system
administrators to determine operating conditions and perform system
operational level monitoring of the VPN and SRA part of the network.
Statistics and traps are provided as well.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jenkins-ipsec-tun-mon-mib-00.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-jenkins-ipsec-tun-mon-mib-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-jenkins-ipsec-tun-mon-mib-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20011008095823.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-jenkins-ipsec-tun-mon-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-jenkins-ipsec-tun-mon-mib-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20011008095823.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Mon Oct 8 09:39:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f98GdvD07630;
Mon, 8 Oct 2001 09:39:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16961
Mon, 8 Oct 2001 11:55:18 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15297.52795.766521.375014@thomasm-u1.cisco.com>
Date: Mon, 8 Oct 2001 09:03:07 -0700 (PDT)
To: Joel Snyder <Joel.Snyder@Opus1.COM>
Cc: ipsec@lists.tislabs.com, Natalie Timms <ntimms@cisco.com>
Subject: Re: IPSec still too slow?
In-Reply-To: <3BBFA47E.A2EF9325@opus1.com>
References: <01K95EUA0SZQ9ED93E@Opus1.COM>
<4.3.2.7.2.20011006152013.0358ded8@mira-sjcd-4.cisco.com>
<3BBFA47E.A2EF9325@opus1.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Joel Snyder writes:
> "inaccurate" is ... well, "inaccurate." The numbers are perfectly
> correct and represent the actual thruput of the 7140 as configured by an
> experienced Cisco-employed engineer at our site. There is no
> inaccuracy.
As we all know -- and many lament -- routers
aren't the simple L3 forwarders of years
past. QoS, security, link layer kruftiness, etc,
etc add considerable complexity; dealing with the
combinatorics can be pretty daunting. That means
that you pretty much get to guess which cross
section of features are likely to be used at any
one time so that you can optimize for
it. Sometimes that guessing goes wrong, but it's
also the case that rags have a tendency to use
combinations which are indicative of the rag's
idea of the real world (or their own biases),
which doesn't necessarily correspond to what
squeaky wheels the vendors hear.
The moral of the story: s/inaccurate/misleading
(which is how I understood Natalie's comment).
Mike
From owner-ipsec@lists.tislabs.com Mon Oct 8 20:12:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f993CKD23835;
Mon, 8 Oct 2001 20:12:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18257
Mon, 8 Oct 2001 22:03:23 -0400 (EDT)
Message-Id: <200110090203.KAA15413@csnet1>
Date: Tue, 9 Oct 2001 10:12:20 +0800
From: dxh <sleepy-cat@263.net>
Reply-To: sleepy-cat@263.net
To: Alexey Vyskubov <alexey.vyskubov@nokia.com>,
"ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: Re: Re: Does an outbound packet need to be reroute?
X-mailer: FoxMail 3.11 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>
>As far as I understand RFC 2401 says that only one SP should be applied
>to the packet. Nested tunnels are implemented using nested SAs not SPs.
>
>Am I wrong?
>
>--
>Alexey
I agree with you. What is your opinion about my question ?
Dong Xiaohu
From owner-ipsec@lists.tislabs.com Mon Oct 8 22:54:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f995srD26602;
Mon, 8 Oct 2001 22:54:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA18703
Tue, 9 Oct 2001 01:09:33 -0400 (EDT)
Message-ID: <00e901c15082$16bc3c10$f50cfe81@etri.re.kr>
From: =?ks_c_5601-1987?B?udq/+MHW?= <wjpark@etri.re.kr>
To: <ipsec@lists.tislabs.com>
Subject: What is DVPN(Dynamic VPN) ?
Date: Tue, 9 Oct 2001 14:20:19 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_00E6_01C150CD.8697AF10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_00E6_01C150CD.8697AF10
Content-Type: text/plain;
charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64
SGkgYWxsLi4NCg0KT24gc3VydmV5aW5nIHRoZSBWUE4gbWFya2VyIHJlc2VyY2gsIEkgZm91bmQg
dGhlIHRlcm0sIkRWUE4oRHluYW1pYyBWUE4pIi4NCldoYXQgaXMgRFZQTj8gDQpJZiB5b3Uga25v
dyB3aGF0IERWUE4gaXMsIGxldCBtZSBrbm93biB0aGUgcmVsYXRpb24gb2YgRFZQTiwgQUFBIGFu
ZCBQS0kuLg0KDQotIC0NCldvbmpvbw0KDQoNCg0K
------=_NextPart_000_00E6_01C150CD.8697AF10
Content-Type: text/html;
charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjUwLjQ4MDcuMjMwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIGFsbC4u
PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ
Vj48Rk9OVCBzaXplPTI+T24mbmJzcDtzdXJ2ZXlpbmcgdGhlIFZQTiBtYXJrZXIgcmVzZXJjaCwg
SSBmb3VuZCB0aGUgDQp0ZXJtLCJEVlBOKER5bmFtaWMgVlBOKSIuPC9GT05UPjwvRElWPg0KPERJ
Vj48Rk9OVCBzaXplPTI+V2hhdCBpcyBEVlBOPyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNp
emU9Mj5JZiB5b3Uga25vdyB3aGF0IERWUE4gaXMsJm5ic3A7bGV0IG1lJm5ic3A7a25vd24mbmJz
cDt0aGUgDQpyZWxhdGlvbiBvZiBEVlBOLCBBQUEgYW5kIFBLSS4uPC9GT05UPjwvRElWPg0KPERJ
Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+LSAt
PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+V29uam9vPC9GT05UPjwvRElWPg0KPERJ
Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9G
T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwv
Qk9EWT48L0hUTUw+DQo=
------=_NextPart_000_00E6_01C150CD.8697AF10--
From owner-ipsec@lists.tislabs.com Tue Oct 9 07:48:39 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f99EmdD15108;
Tue, 9 Oct 2001 07:48:39 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19962
Tue, 9 Oct 2001 09:48:58 -0400 (EDT)
Message-ID: <75A3CEA84682D311AAC70008C791823201E6FEE1@zbl6c016.corpeast.baynetworks.com>
From: "Jerome Freedman Jr" <jefreed@nortelnetworks.com>
To: ipsec@lists.tislabs.com
Subject: who is implementing rekey and how
Date: Tue, 9 Oct 2001 06:56:06 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C150CA.24425F70"
X-Orig: <JEFREED@AmericasM06.nt.com>
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_01C150CA.24425F70
Content-Type: text/plain;
charset="iso-8859-1"
What vendors are implementing IKE rekey and how are they doing it? (
establishing n SA's in one swell foop, just-in-time , etc).
Jerry Freedman
>\ | /<
(@) (@)
------ o00o-(_)-o00o---------------
------_=_NextPart_001_01C150CA.24425F70
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 =
5.5.2654.89">
<TITLE>who is implementing rekey and how</TITLE>
</HEAD>
<BODY>
<BR>
<P><FONT SIZE=3D2 FACE=3D"Arial">What vendors are implementing IKE =
rekey and how are they doing it? ( establishing n SA's in one swell =
foop, just-in-time , etc). </FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Jerry Freedman</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Courier =
New"> >\ =
| /<</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New"> (@) =
(@)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New"> ------ =
o00o-(_)-o00o---------------</FONT>
</P>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01C150CA.24425F70--
From owner-ipsec@lists.tislabs.com Tue Oct 9 07:55:14 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f99EtDD16524;
Tue, 9 Oct 2001 07:55:14 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19940
Tue, 9 Oct 2001 09:38:11 -0400 (EDT)
Date: Tue, 9 Oct 2001 15:45:34 +0200
From: Marco Ender <marco.ender@dungeonmaster.at>
X-Mailer: The Bat! (v1.53bis) Educational
Reply-To: Marco Ender <marco.ender@dungeonmaster.at>
X-Priority: 3 (Normal)
Message-ID: <411389049.20011009154534@dungeonmaster.at>
To: ipsec@lists.tislabs.com
Subject: Q: Calculating Cookies for ISAKMP - Header in IKE
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
just a small question about the Cookie - Generation as mentioned under
3.3 in RFC 2522 "Photuris: Session-Key Management Protocol" (RFC 2408
"ISAKMP" points to it with [Karn]):
First the Initiator Cookie is calculated with a rather complicated
method (MD5 over some attributes like a secret value, the source - and
destination ip adress etc.). Then, when receiving the answer from the
responder, the initiator - cookie in that message is compared to a
recalculated cookie, or alternatively the cached sent cookie. This is
to deny DoS - Attacks on the later Diffie-Hellman calculation.
Now my question: Why not just generate a random cookie? I can check
this cookie just as i do it with the more complex cookie and have the
same result, either i sent the cookie or i didn´t?
What do i miss to understand?
thank you in advance for your patience to read (and answer) my
question,
Marco
From owner-ipsec@lists.tislabs.com Tue Oct 9 12:18:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f99JIlD03694;
Tue, 9 Oct 2001 12:18:47 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20335
Tue, 9 Oct 2001 14:01:59 -0400 (EDT)
Message-ID: <80B684C5E29FD211AA8000A0C9CDD91909D38682@il0015exch005u.ih.lucent.com>
From: "Kopeikin, Roy A (Roy)" <rkopeikin@lucent.com>
To: ??? <wjpark@etri.re.kr>, ipsec@lists.tislabs.com
Subject: RE: What is DVPN(Dynamic VPN) ?
Date: Tue, 9 Oct 2001 13:09:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C150ED.974928F0"
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_01C150ED.974928F0
Content-Type: text/plain;
charset="KS_C_5601-1987"
The AAA and PKI are industry standard means of subscriber authentication
for access into the VPN
Roy Kopeikin
Lucent Technologies
rkopeikin@lucent.com
-----Original Message-----
From: wjpark@etri.re.kr [mailto:wjpark@etri.re.kr]
Sent: Tuesday, October 09, 2001 12:20 AM
To: ipsec@lists.tislabs.com
Subject: What is DVPN(Dynamic VPN) ?
Hi all..
On surveying the VPN marker reserch, I found the term,"DVPN(Dynamic VPN)".
What is DVPN?
If you know what DVPN is, let me known the relation of DVPN, AAA and PKI..
- -
Wonjoo
------_=_NextPart_001_01C150ED.974928F0
Content-Type: text/html;
charset="KS_C_5601-1987"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=KS_C_5601-1987">
<META content="MSHTML 5.00.3315.2870" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=809450818-09102001>The
AAA and PKI are industry standard means of subscriber authentication for access
into the VPN</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=809450818-09102001>Roy
Kopeikin</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=809450818-09102001>Lucent
Technologies </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=809450818-09102001>rkopeikin@lucent.com</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> wjpark@etri.re.kr
[mailto:wjpark@etri.re.kr]<BR><B>Sent:</B> Tuesday, October 09, 2001 12:20
AM<BR><B>To:</B> ipsec@lists.tislabs.com<BR><B>Subject:</B> What is
DVPN(Dynamic VPN) ?<BR><BR></DIV></FONT>
<DIV><FONT size=2>Hi all..</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>On surveying the VPN marker reserch, I found the
term,"DVPN(Dynamic VPN)".</FONT></DIV>
<DIV><FONT size=2>What is DVPN? </FONT></DIV>
<DIV><FONT size=2>If you know what DVPN is, let me known the
relation of DVPN, AAA and PKI..</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>- -</FONT></DIV>
<DIV><FONT size=2>Wonjoo</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2></FONT> </DIV></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C150ED.974928F0--
From owner-ipsec@lists.tislabs.com Tue Oct 9 12:39:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f99JdrD04307;
Tue, 9 Oct 2001 12:39:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20521
Tue, 9 Oct 2001 14:53:01 -0400 (EDT)
To: Alex Alten <Alten@home.com>
From: dharkins@lounge.org
Cc: ipsec@lists.tislabs.com
Subject: Re: IPSec still too slow?
In-Reply-To: Your message of "Fri, 05 Oct 2001 16:15:40 PDT."
<3.0.3.32.20011005161540.00b82d40@mail>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10236.1002654084.1@SailPix.com>
Date: Tue, 09 Oct 2001 12:01:24 -0700
Message-Id: <20011009190124.D8D3F54C44@tailor.sailpix.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Alex,
Since all you do is spread FUD you shouldn't be surprised that someone
would get nasty. Your agenda is quite obvious, you've had it in for IPsec
ever since your product was described on this list as snake-oil.
Dan.
"I personally think it is very dangerous to organize
referendums when you're not sure to win them"
-- Louis Michel, President of the European Union
On Fri, 05 Oct 2001 16:15:40 PDT you wrote
> Dr. John Ioannidis,
>
> I have a great deal of respect for your contributions to the Internet
> community. This kind of nasty response greatly surprises me and indicates
> to me that the problems with IPSec are very serious. I did not take these
> numbers at face value. That is why I requested confirmation. However,
> the fact of the matter is, IPSec will always be at least 10x behind the
> communications price/performance curve. You, of all people, know that.
> And you know that fact will eventually kill off IPSec.
>
> - Alex
>
>
> At 03:27 PM 10/5/2001 -0400, ji@research.att.com wrote:
> >People who do not understand how to take and interpret performance
> >measurements should just shut up.
> >
> >/ji
> >
>
>
> --
>
> Alex Alten
> Alten@Home.Com
>
> ***********************
> * Just Say NO to RC4. *
> ***********************
From owner-ipsec@lists.tislabs.com Tue Oct 9 13:44:51 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f99KipD05859;
Tue, 9 Oct 2001 13:44:51 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20689
Tue, 9 Oct 2001 15:54:56 -0400 (EDT)
Message-ID: <522FDAAFD532D511A0AB0002A51390EB2F6FD3@cat01s2.catena.com>
From: Tim Jenkins <TJenkins@Catena.com>
To: ipsec@lists.tislabs.com
Subject: RE: I-D ACTION:draft-jenkins-ipsec-tun-mon-mib-00.txt
Date: Tue, 9 Oct 2001 13:28:01 -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
All,
I have submitted this document as an illustration of how the IPsec MIBs can
be used as a base for MIBS that are for application specific uses of IPsec.
I will not be working on it any further; if anyone wants to continue with
it, feel free to use it.
Tim
> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Monday, October 08, 2001 9:58 AM
> Cc: ipsec@lists.tislabs.com
> Subject: I-D ACTION:draft-jenkins-ipsec-tun-mon-mib-00.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
> Title : IPsec Tunnel Monitoring MIB
> Author(s) : T. Jenkins
> Filename : draft-jenkins-ipsec-tun-mon-mib-00.txt
> Pages : 52
> Date : 05-Oct-01
>
> This document defines monitoring and status MIBs for specific
> applications of IPsec's security associations (SAs). The specific
> applications are for the purposes of virtual private networking (VPN)
> and secure remote access (SRA) applications. The MIB allows system
> administrators to determine operating conditions and perform system
> operational level monitoring of the VPN and SRA part of the network.
> Statistics and traps are provided as well.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jenkins-ipsec-tun-mo
n-mib-00.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-jenkins-ipsec-tun-mon-mib-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-jenkins-ipsec-tun-mon-mib-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
From owner-ipsec@lists.tislabs.com Tue Oct 9 14:08:37 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f99L8aD06415;
Tue, 9 Oct 2001 14:08:36 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20778
Tue, 9 Oct 2001 16:18:12 -0400 (EDT)
Reply-To: <peter.onufryk@idt.com>
From: "Peter Onufryk" <peter.onufryk@idt.com>
To: <ipsec@lists.tislabs.com>
Subject: Sample Packets
Date: Tue, 9 Oct 2001 16:35:50 -0400
Message-ID: <023f01c15101$fcdb9270$6560a59d@corp3cr5601>
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.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
We are working on an IPSec implementation and are looking for examples of
good IPSec AH (MD5, SHA-1) and ESP {(MD5, SHA-1) x (DES, 3DES, AES)}
packets? Does anyone know where we can find some? I apologize if this has
been asked before but I can't find any examples on the net.
Thanks,
Peter
From owner-ipsec@lists.tislabs.com Tue Oct 9 15:47:45 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f99MliD09297;
Tue, 9 Oct 2001 15:47:44 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20905
Tue, 9 Oct 2001 18:06:33 -0400 (EDT)
From: rks@cisco.com
Date: Tue, 9 Oct 2001 15:13:58 -0700 (PDT)
Message-Id: <200110092213.PAA18821@miranda-ultra.cisco.com>
To: byfraser@cisco.com, tytso@mit.edu
Cc: bbruins@cisco.com, ipsec@lists.tislabs.com, leot@cisco.com
Subject: Status of ID: IPsec Flow Monitoring MIB
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
We proposed the IPsec Flow Monitor MIB in 1999 to aid
IPsec monitoring applications designed to evaluate the
connectivity and performance and troubleshoot connectivity
failures. The MIB has evolved ever since based on comments
from early of VPN deployers. We would like to standardize
this MIB and want the WG chairs to advance the ID in the
standards track.
History:
The MIB was first defined because the MIBs available during
that time in the area were insufficient in providing the
abstractions that are desirable to make IPsec manageable.
Tivoli Systems (a multi-vendor management company) refined
the MIB with Cisco Systems to make it a multi-vendor/standard
MIB for managing IPsec networks. After successful deployment in
the field, it was revised and the revision was submitted to
the WG early this year.
The MIB has since been adopted by a few VPN service providers,
management vendors and users. Their comments were helpful in
further refining the MIB definition.
Highlights of the MIB:
Defining a MIB to merely export bits of the protocol serves no
management purpose. We defined the MIB with the following features:
1. Build abstractions that may be used by the network administrators
to identify traffic flows in IPsec networks. This would allow the
correlation of the performance of the application traffic with
that of the underlying IPsec networks.
2. Help define SLAs to qualify the performance and failures.
3. History and failure tables for trending and troubleshooting.
4. SA tables to aid low level troubleshooting.
5. Separation of IKE and IPsec groups to allow later extensions for
other keying protocols to be used with IPsec (such as KINK).
I'd very much like to hear comments on this from administrators
or NMS developers who are facing the problem of monitoring
and troubleshooting IPsec-based VPNs.
Coexistence with other MIB drafts:
Our proposal may be regarded as being competing or complementary to
the low level MIBs proposed by Jenkins et al. To that extent,
we are willing to layer our MIB on top of the basic definitions
provided by the Jenkins drafts.
In 1999, it was proposed that we use the ISAKMP and IPsec textual
conventions proposed by Jenkins drafts. This is quite feasible
since there is little difference between the TCs proposed by
the two drafts.
Please advise us on what we need to do in order to advance this MIB
in the standards track.
Thanks,
Leo Temoshenko, Cisco Systems Inc.
Cheryl Madson, Cisco Systems Inc.
Chinna Pellacuru, Cisco Systems Inc.
Bret Harrison, Tivoli Systems Inc.
S Ramakrishnan, Cisco Systems Inc.
From owner-ipsec@lists.tislabs.com Tue Oct 9 18:32:56 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9A1WuD18167;
Tue, 9 Oct 2001 18:32:56 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA21205
Tue, 9 Oct 2001 20:42:40 -0400 (EDT)
Message-Id: <3.0.3.32.20011009175628.011a2670@mail>
X-Sender: alten@mail
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
Date: Tue, 09 Oct 2001 17:56:28 -0700
To: dharkins@lounge.org
From: Alex Alten <Alten@home.com>
Subject: Re: IPSec still too slow?
Cc: ipsec@lists.tislabs.com
In-Reply-To: <20011009190124.D8D3F54C44@tailor.sailpix.com>
References: <Your message of "Fri, 05 Oct 2001 16:15:40 PDT." <3.0.3.32.20011005161540.00b82d40@mail>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dan,
LOL. You need to re-read the archives to get your facts straight.
I've been very clear about my concerns with IPsec prior to that,
starting with a detailed response to the last call 3 years ago.
- Alex
At 12:01 PM 10/9/2001 -0700, dharkins@lounge.org wrote:
> Alex,
>
> Since all you do is spread FUD you shouldn't be surprised that someone
>would get nasty. Your agenda is quite obvious, you've had it in for IPsec
>ever since your product was described on this list as snake-oil.
>
> Dan.
>
>"I personally think it is very dangerous to organize
> referendums when you're not sure to win them"
> -- Louis Michel, President of the European Union
>
>On Fri, 05 Oct 2001 16:15:40 PDT you wrote
>> Dr. John Ioannidis,
>>
>> I have a great deal of respect for your contributions to the Internet
>> community. This kind of nasty response greatly surprises me and indicates
>> to me that the problems with IPSec are very serious. I did not take these
>> numbers at face value. That is why I requested confirmation. However,
>> the fact of the matter is, IPSec will always be at least 10x behind the
>> communications price/performance curve. You, of all people, know that.
>> And you know that fact will eventually kill off IPSec.
>>
>> - Alex
>>
>>
>> At 03:27 PM 10/5/2001 -0400, ji@research.att.com wrote:
>> >People who do not understand how to take and interpret performance
>> >measurements should just shut up.
>> >
>> >/ji
>> >
>>
>>
>> --
>>
>> Alex Alten
>> Alten@Home.Com
>>
>> ***********************
>> * Just Say NO to RC4. *
>> ***********************
>
--
Alex Alten
Alten@Home.Com
From owner-ipsec@lists.tislabs.com Tue Oct 9 23:24:38 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9A6ObD10692;
Tue, 9 Oct 2001 23:24:38 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA21573
Wed, 10 Oct 2001 01:20:55 -0400 (EDT)
Date: Wed, 10 Oct 2001 10:59:28 +0530 (IST)
From: Puja Puri <puja.puri@cdac.ernet.in>
To: dxh <sleepy-cat@263.net>
cc: Alexey Vyskubov <alexey.vyskubov@nokia.com>,
"ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: Re: Re: Does an outbound packet need to be reroute?
In-Reply-To: <200110090203.KAA15413@csnet1>
Message-ID: <Pine.GSO.4.10.10110101044210.11724-100000@mailhub.cdac.ernet.in>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
i think Nested Tunnels can be implemented using both nested SAs and SPs.
Just have a look at RFC 2401 "Basic Combinations of Security
Associations",case 3. In this case nested SPs will also be required.
rgds
puja
Puja Puri
Member of Technical Staff
Networking and Internet Software Group
C-DAC
Pune
On Tue, 9 Oct 2001, dxh wrote:
> >
> >As far as I understand RFC 2401 says that only one SP should be applied
> >to the packet. Nested tunnels are implemented using nested SAs not SPs.
> >
> >Am I wrong?
> >
> >--
> >Alexey
> I agree with you. What is your opinion about my question ?
>
>
>
> Dong Xiaohu
>
>
From owner-ipsec@lists.tislabs.com Wed Oct 10 06:06:22 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9AD6LD20213;
Wed, 10 Oct 2001 06:06:21 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA22192
Wed, 10 Oct 2001 07:58:20 -0400 (EDT)
From: Steve.Robinson@psti.com
Subject: Re: Sample Packets
To: <peter.onufryk@idt.com>
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com
X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000
Message-ID: <OF42AE3B64.6119F3A7-ON80256AE1.0042B824@psti.com>
Date: Wed, 10 Oct 2001 08:11:39 -0400
X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at
10/10/2001 01:12:16 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
If you have a packet sniffer, you can go to the NIST website at
http://ipsec-wit.antd.nist.gov and generate the scenarios you describe
below. Run the tests and capture the NIST output. They are simple ping
packets.
Steve
"Peter Onufryk"
<peter.onufryk@idt. To: <ipsec@lists.tislabs.com>
com> cc:
Sent by: Subject: Sample Packets
owner-ipsec@lists.t
islabs.com
10/09/01 04:35 PM
Please respond to
peter.onufryk
We are working on an IPSec implementation and are looking for examples of
good IPSec AH (MD5, SHA-1) and ESP {(MD5, SHA-1) x (DES, 3DES, AES)}
packets? Does anyone know where we can find some? I apologize if this has
been asked before but I can't find any examples on the net.
Thanks,
Peter
From owner-ipsec@lists.tislabs.com Wed Oct 10 07:51:23 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9AEpND26538;
Wed, 10 Oct 2001 07:51:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22534
Wed, 10 Oct 2001 09:40:35 -0400 (EDT)
Message-ID: <3BC451CD.F321817D@nist.gov>
Date: Wed, 10 Oct 2001 09:49:01 -0400
From: Doug Montgomery <dougm@nist.gov>
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve.Robinson@psti.com, ipsec@lists.tislabs.com
CC: peter.onufryk@idt.com
Subject: Re: Sample Packets
References: <OF42AE3B64.6119F3A7-ON80256AE1.0042B824@psti.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Steve.Robinson@psti.com wrote:
>
> If you have a packet sniffer, you can go to the NIST website at
> http://ipsec-wit.antd.nist.gov and generate the scenarios you describe
> below. Run the tests and capture the NIST output. They are simple ping
> packets.
>
> Steve
>
Actually, IPsec-WIT will display full inbound and outboad packet dumps, both
before and after ipsec, by itself. Go to the "CONFIGURE TEST" screen and make
sure that packet dumps are on.
dougm
--
+-----------------------------------------------------------------------------+
| Doug Montgomery Manager, Internetworking Technologies Group |
| National Institute of Standards and Technology Email: dougm@nist.gov |
| Building 820, Room 457 Voice: +1-301-975-3630 |
| 820 West Diamond Avenue Fax: +1-301-590-0932 |
| Gaithersburg, MD 20899 USA WWW: http://www.antd.nist.gov/itg/ |
+-----------------------------------------------------------------------------+
From owner-ipsec@lists.tislabs.com Wed Oct 10 10:23:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9AHNvD11263;
Wed, 10 Oct 2001 10:23:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22869
Wed, 10 Oct 2001 12:05:56 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Jerome Freedman Jr'" <jefreed@nortelnetworks.com>,
<ipsec@lists.tislabs.com>
Subject: RE: who is implementing rekey and how
Date: Wed, 10 Oct 2001 12:12:59 -0400
Message-Id: <001c01c151a6$6f394610$1e72788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_001D_01C15184.E827A610"
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: <75A3CEA84682D311AAC70008C791823201E6FEE1@zbl6c016.corpeast.baynetworks.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_001D_01C15184.E827A610
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
who is implementing rekey and howI think most people are either using
pre-setup or on-demand negotiation. I'm interested: Does anyone do the
multiple SA pre-setup method which is mentioned in the RFC? That strikes me
as a superior technique (once you solve any black-hole problems), but I
haven't seen anyone asking about it at any of the last few bakeoffs.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jerome Freedman Jr
Sent: Tuesday, October 09, 2001 9:56 AM
To: ipsec@lists.tislabs.com
Subject: who is implementing rekey and how
What vendors are implementing IKE rekey and how are they doing it?
establishing n SA's in one swell foop, just-in-time , etc).
Jerry Freedman
>\ | /<
(@) (@)
------ o00o-(_)-o00o---------------
------=_NextPart_000_001D_01C15184.E827A610
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>who is implementing rekey and how</TITLE>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#008000 face=3DVerdana size=3D2><SPAN =
class=3D712300316-10102001>I=20
think most people are either using pre-setup or on-demand negotiation. =
I'm=20
interested: Does anyone do the multiple SA pre-setup method which =
is=20
mentioned in the RFC? That strikes me as a superior technique (once you =
solve=20
any black-hole problems), but I haven't seen anyone asking about it at =
any of=20
the last few bakeoffs.</SPAN></FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#008000 face=3DVerdana size=3D2><SPAN=20
class=3D712300316-10102001>Andrew</SPAN></FONT></DIV>
<DIV><FONT color=3D#008000 face=3DVerdana size=3D2><SPAN=20
class=3D712300316-10102001></SPAN></FONT><I><FONT color=3D#800080 =
face=3D"Courier New"=20
size=3D2>-------------------------------------------</FONT></I> =
<BR><I><FONT=20
color=3D#800080 face=3D"Courier New" size=3D2>Upon closer inspection, I =
saw that the=20
line </FONT></I><BR><I><FONT color=3D#800080 face=3D"Courier New" =
size=3D2>dividing=20
black from white was in fact a shade</FONT></I> <BR><I><FONT =
color=3D#800080=20
face=3D"Courier New" size=3D2>of grey. As I drew nearer still, the grey=20
area</FONT></I> <BR><I><FONT color=3D#800080 face=3D"Courier New" =
size=3D2>grew=20
larger. And then I was enlightened.</FONT></I> </DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #008000 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
<DIV class=3DOutlookMessageHeader><FONT face=3D"Times New Roman"=20
size=3D2>-----Original Message-----<BR><B>From:</B>=20
owner-ipsec@lists.tislabs.com =
[mailto:owner-ipsec@lists.tislabs.com]<B>On=20
Behalf Of</B> Jerome Freedman Jr<BR><B>Sent:</B> Tuesday, October 09, =
2001=20
9:56 AM<BR><B>To:</B> ipsec@lists.tislabs.com<BR><B>Subject:</B> who =
is=20
implementing rekey and how<BR><BR></DIV></FONT><BR>
<P><FONT face=3DArial size=3D2>What vendors are implementing IKE rekey =
and how are=20
they doing it? ( establishing n SA's in one swell foop, =
just-in-time ,=20
etc). </FONT></P>
<P><FONT face=3DArial size=3D2>Jerry Freedman</FONT> </P>
<P><FONT face=3D"Courier New"=20
size=3D2> =
>\ =20
| /<</FONT> <BR><FONT face=3D"Courier New"=20
size=3D2> =
(@)=20
(@)</FONT> <BR><FONT face=3D"Courier New" size=3D2> ------=20
o00o-(_)-o00o---------------</FONT> =
</P><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_001D_01C15184.E827A610--
From owner-ipsec@lists.tislabs.com Wed Oct 10 11:41:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9AIfvD15445;
Wed, 10 Oct 2001 11:41:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23168
Wed, 10 Oct 2001 13:49:45 -0400 (EDT)
To: Alex Alten <Alten@home.com>
From: dharkins@lounge.org
Cc: ipsec@lists.tislabs.com
Subject: Re: IPSec still too slow?
In-Reply-To: Your message of "Tue, 09 Oct 2001 17:56:28 PDT."
<3.0.3.32.20011009175628.011a2670@mail>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <16951.1002736693.1@SailPix.com>
Date: Wed, 10 Oct 2001 10:58:13 -0700
Message-Id: <20011010175813.54D5154C49@tailor.sailpix.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I was wrong. Your detailed response (Fed 22, 1998) predated the
description of your product as snakeoil (June 9, 1998) by 3 1/2 months.
That was some interesting reading though.
Your number one technical criticism of IPsec at the time was that it
did not have key recovery built in. You said, "Regardless of the merits
of the design by not supporting this requirement it will probably kill
IPSEC as a viable Internet standard." Your number two technical criticism
said that because there was no key recovery built in that the requirement
for DES as the mandatory-to-implement cipher would not be possible to meet.
LOL, indeed!
Dan.
"I personally think it is very dangerous to organize
referendums when you're not sure to win them"
-- Louis Michel, President of the European Union
On Tue, 09 Oct 2001 17:56:28 PDT you wrote
> Dan,
>
> LOL. You need to re-read the archives to get your facts straight.
>
> I've been very clear about my concerns with IPsec prior to that,
> starting with a detailed response to the last call 3 years ago.
>
> - Alex
>
> At 12:01 PM 10/9/2001 -0700, dharkins@lounge.org wrote:
> > Alex,
> >
> > Since all you do is spread FUD you shouldn't be surprised that someone
> >would get nasty. Your agenda is quite obvious, you've had it in for IPsec
> >ever since your product was described on this list as snake-oil.
> >
> > Dan.
From owner-ipsec@lists.tislabs.com Wed Oct 10 21:45:28 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9B4jRD02829;
Wed, 10 Oct 2001 21:45:27 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA24285
Wed, 10 Oct 2001 23:44:10 -0400 (EDT)
Message-ID: <B0080705FCBED41187750050DA1C154A030743@amindmail.india.ambernetworks.com>
From: Raghunath Tilak <tilak@ambernetworks.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Question regarding sensitivity check in RFC 2401
Date: Thu, 11 Oct 2001 09:27:40 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C15208.DF93DCB0"
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_01C15208.DF93DCB0
Content-Type: text/plain;
charset="iso-8859-1"
Hello experts,
I have some questions regarding Sensitivity Level & check on it.
1. RFC 2401 (Security Arch) gives references to RFC 1108 for senitivity
levels associated with a packet.
RFC 1108 (IPSO) suggests use of option fields in IP header to associate
security levels to the packets. These labels can then be used in
MLS capable implementation of IPsec. The RFC 1108 assumes IPv4 case.
What is the equivalent of this in IPv6 world? I did not find any
reference
in RFC 2460 (IP v6).
2. This is regarding the sensitivity check.
How does one determine the value to be compared against sensitivity
information
that is extracted from the packet? The paragraph 8.2 in RFC 2401 gives 3
options.
Sensitivity level associated with a particular output interface
Sensitivity level associated with the IP source address of the
packet
Sensitivity level associated with the IP destination address of the
final
IP packet.
Can an implementation use any one of them or say the least sensitive of
the three
for security check?
I appreciate your help in this regard.
Raghu Tilak
Amber Networks India Pvt Ltd
------_=_NextPart_001_01C15208.DF93DCB0
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 =
5.5.2653.12">
<TITLE>Question regarding sensitivity check in RFC 2401</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Hello experts,</FONT>
</P>
<P><FONT SIZE=3D2>I have some questions regarding Sensitivity Level =
& check on it.</FONT>
</P>
<P><FONT SIZE=3D2>1. RFC 2401 (Security Arch) gives references to RFC =
1108 for senitivity </FONT>
<BR><FONT SIZE=3D2> levels associated with a =
packet.</FONT>
<BR><FONT SIZE=3D2> RFC 1108 (IPSO) suggests use of =
option fields in IP header to associate</FONT>
<BR><FONT SIZE=3D2> security levels to the packets. =
These labels can then be used in</FONT>
<BR><FONT SIZE=3D2> MLS capable implementation of =
IPsec. The RFC 1108 assumes IPv4 case.</FONT>
<BR><FONT SIZE=3D2> What is the equivalent of this in =
IPv6 world? I did not find any reference</FONT>
<BR><FONT SIZE=3D2> in RFC 2460 (IP v6).</FONT>
</P>
<P><FONT SIZE=3D2>2. This is regarding the sensitivity check.</FONT>
<BR><FONT SIZE=3D2> How does one determine the value =
to be compared against sensitivity information</FONT>
<BR><FONT SIZE=3D2> that is extracted from the =
packet? The paragraph 8.2 in RFC 2401 gives 3 options.</FONT>
</P>
<P> <FONT =
SIZE=3D2>Sensitivity level associated with a particular output =
interface</FONT>
<BR> <FONT =
SIZE=3D2>Sensitivity level associated with the IP source address of the =
packet</FONT>
<BR> <FONT =
SIZE=3D2>Sensitivity level associated with the IP destination address =
of the final</FONT>
<BR> <FONT SIZE=3D2>IP =
packet.</FONT>
</P>
<P><FONT SIZE=3D2> Can an implementation use any one of =
them or say the least sensitive of the three</FONT>
<BR><FONT SIZE=3D2> for security check?</FONT>
</P>
<P><FONT SIZE=3D2>I appreciate your help in this regard.</FONT>
</P>
<P><FONT SIZE=3D2>Raghu Tilak</FONT>
<BR><FONT SIZE=3D2>Amber Networks India Pvt Ltd</FONT>
</P>
<P> =20
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C15208.DF93DCB0--
From owner-ipsec@lists.tislabs.com Wed Oct 10 21:45:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9B4jWD02844;
Wed, 10 Oct 2001 21:45:32 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA24347
Wed, 10 Oct 2001 23:58:43 -0400 (EDT)
Date: 11 Oct 2001 04:07:26 -0000
Message-ID: <20011011040726.17198.qmail@mailFA8.rediffmail.com>
MIME-Version: 1.0
From: "sunil kumar chirra" <sunilchirra@rediffmail.com>
Reply-To: "sunil kumar chirra" <sunilchirra@rediffmail.com>
To: <ipsec@lists.tislabs.com>
Subject: Reg simulation of IPSEC
Content-type: text/plain;
charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id XAA24344
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi,
I want to simulate a wireless network with HAs ,FAs and mobile nodes.Then I want to integrate mobile IP with IPSEC so that all packets to be routed are made secure.Can anybody suggest a good simulator which can be used to simulate the IPSEC protocols in mobile environment?.
Thank You
Sunil
From owner-ipsec@lists.tislabs.com Wed Oct 10 22:53:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9B5rqD04887;
Wed, 10 Oct 2001 22:53:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA24414
Thu, 11 Oct 2001 01:05:59 -0400 (EDT)
Message-ID: <00b001c15212$bb39a250$380310ac@cwcrrjkrrcfonk>
From: "Hong Gie Ong" <stuonghg@cwc.nus.edu.sg>
To: "Marco Ender" <marco.ender@dungeonmaster.at>, <ipsec@lists.tislabs.com>
References: <411389049.20011009154534@dungeonmaster.at>
Subject: Re: Calculating Cookies for ISAKMP - Header in IKE
Date: Thu, 11 Oct 2001 13:08:06 +0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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.6700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
but if you just send a random cookie how do you know if someone else created
that cookie to make it look like it comes from the one you're trying to
correspond with ?
Using MD5 based on the IP-address in question and some secret value makes
the outcome unique to both parties right ? So in that way you know that it's
the same originator of the connection request ;
Or do I understand it wrongly ? Please correct me if I'm off-track;
HG
----- Original Message -----
From: "Marco Ender" <marco.ender@dungeonmaster.at>
To: <ipsec@lists.tislabs.com>
Sent: Tuesday, October 09, 2001 9:45 PM
Subject: Q: Calculating Cookies for ISAKMP - Header in IKE
> Hi,
>
> just a small question about the Cookie - Generation as mentioned under
> 3.3 in RFC 2522 "Photuris: Session-Key Management Protocol" (RFC 2408
> "ISAKMP" points to it with [Karn]):
>
> First the Initiator Cookie is calculated with a rather complicated
> method (MD5 over some attributes like a secret value, the source - and
> destination ip adress etc.). Then, when receiving the answer from the
> responder, the initiator - cookie in that message is compared to a
> recalculated cookie, or alternatively the cached sent cookie. This is
> to deny DoS - Attacks on the later Diffie-Hellman calculation.
>
> Now my question: Why not just generate a random cookie? I can check
> this cookie just as i do it with the more complex cookie and have the
> same result, either i sent the cookie or i didn´t?
>
> What do i miss to understand?
>
> thank you in advance for your patience to read (and answer) my
> question,
>
> Marco
>
>
From owner-ipsec@lists.tislabs.com Thu Oct 11 04:42:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9BBglD14529;
Thu, 11 Oct 2001 04:42:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25124
Thu, 11 Oct 2001 06:50:59 -0400 (EDT)
Date: Thu, 11 Oct 2001 12:58:22 +0200
From: Marco Ender <marco.ender@dungeonmaster.at>
X-Mailer: The Bat! (v1.53bis) Educational
Reply-To: Marco Ender <marco.ender@dungeonmaster.at>
X-Priority: 3 (Normal)
Message-ID: <454192948.20011011125822@dungeonmaster.at>
To: ipsec@lists.tislabs.com
Subject: [OT] RE: Calculating Cookies for ISAKMP - Header in IKE - Thank you all!
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I don´t know if this message is just seen as useless traffic on this
list (if it is let me know so i won´t to it again), but i want to
thank all the nice people who explained me the reasons for the MD5 -
Cookie Generation.
greetings
Marco (yes, a newbie to this list =))
From owner-ipsec@lists.tislabs.com Thu Oct 11 04:45:40 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9BBjeD14724;
Thu, 11 Oct 2001 04:45:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25115
Thu, 11 Oct 2001 06:45:26 -0400 (EDT)
Date: Thu, 11 Oct 2001 12:51:58 +0200
From: Marco Ender <marco.ender@dungeonmaster.at>
X-Mailer: The Bat! (v1.53bis) Educational
Reply-To: Marco Ender <marco.ender@dungeonmaster.at>
X-Priority: 3 (Normal)
Message-ID: <1413809303.20011011125158@dungeonmaster.at>
To: "Hong Gie Ong" <stuonghg@cwc.nus.edu.sg>, ipsec@lists.tislabs.com
Subject: Re[2]: Calculating Cookies for ISAKMP - Header in IKE
In-Reply-To: <00b001c15212$bb39a250$380310ac@cwcrrjkrrcfonk>
References: <411389049.20011009154534@dungeonmaster.at>
<00b001c15212$bb39a250$380310ac@cwcrrjkrrcfonk>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hello,
> but if you just send a random cookie how do you know if someone else created
> that cookie to make it look like it comes from the one you're trying to
> correspond with ?
> Using MD5 based on the IP-address in question and some secret value makes
> the outcome unique to both parties right ? So in that way you know that it's
> the same originator of the connection request ;
> Or do I understand it wrongly ? Please correct me if I'm off-track;
I think you are wrong. Each of the two computers has an own secret
value, they don´t share a common one (how should they anyway? before
the first message they can´t have a shared secret). So one computer
can´t check if the other computer´s cookie is ok, only his own (and if
you look at the RFCs, thats really all they check, their own cookie). But
that can also be accomplished without the cryptographic calculation, i
just have to save a list with all cookies i generated and sent. This was
pointed out by the others. The only reason for the MD5 - cookies would
be a stateless protocol where i don´t use any saved information ( here
the list of cookies i sent) and still have some security. Since IKE
needs to save some information anyway it doesn´t matter if i have to
save one additional cookie per session or not.
br
Marco
From owner-ipsec@lists.tislabs.com Thu Oct 11 06:56:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9BDuCD22064;
Thu, 11 Oct 2001 06:56:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA25470
Thu, 11 Oct 2001 08:55:42 -0400 (EDT)
Message-ID: <522FDAAFD532D511A0AB0002A51390EB2F6FE0@cat01s2.catena.com>
From: Tim Jenkins <TJenkins@Catena.com>
To: "'rks@cisco.com'" <rks@cisco.com>, byfraser@cisco.com, tytso@mit.edu
Cc: bbruins@cisco.com, ipsec@lists.tislabs.com, leot@cisco.com
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
Date: Wed, 10 Oct 2001 09:25:45 -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
All,
I have two main objections to this MIB document. They are:
1) It doesn't use the base IPsec MIBs.
2) It does things that are outside the scope of IPsec.
Below, there is agreement to using the base MIBs, so that
deals with my first objection. As a guide, I have submitted
<draft-jenkins-ipsec-tun-mon-mib-00.txt> as an illustration
of how this can be done.
As far as I can see, the second objection has not been
dealt with. While I believe that a number of these
additional features are things that are user requested
(such as IP address to domain name conversion; see objects
ikeTunLocalName and ikeTunRemoteName as examples), it is my
belief that they do not belong in an IPsec MIB. However,
there are few of these, so it is likely this objection can
be easily overcome.
Tim
> -----Original Message-----
> From: rks@cisco.com [mailto:rks@cisco.com]
> Sent: Tuesday, October 09, 2001 6:14 PM
> To: byfraser@cisco.com; tytso@mit.edu
> Cc: bbruins@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com
> Subject: Status of ID: IPsec Flow Monitoring MIB
>
>
>
> We proposed the IPsec Flow Monitor MIB in 1999 to aid
> IPsec monitoring applications designed to evaluate the
> connectivity and performance and troubleshoot connectivity
> failures. The MIB has evolved ever since based on comments
> from early of VPN deployers. We would like to standardize
> this MIB and want the WG chairs to advance the ID in the
> standards track.
>
>
> History:
> The MIB was first defined because the MIBs available during
> that time in the area were insufficient in providing the
> abstractions that are desirable to make IPsec manageable.
>
> Tivoli Systems (a multi-vendor management company) refined
> the MIB with Cisco Systems to make it a multi-vendor/standard
> MIB for managing IPsec networks. After successful deployment in
> the field, it was revised and the revision was submitted to
> the WG early this year.
>
> The MIB has since been adopted by a few VPN service providers,
> management vendors and users. Their comments were helpful in
> further refining the MIB definition.
>
>
> Highlights of the MIB:
> Defining a MIB to merely export bits of the protocol serves no
> management purpose. We defined the MIB with the following features:
>
> 1. Build abstractions that may be used by the network
> administrators
> to identify traffic flows in IPsec networks. This
> would allow the
> correlation of the performance of the application traffic with
> that of the underlying IPsec networks.
> 2. Help define SLAs to qualify the performance and failures.
> 3. History and failure tables for trending and troubleshooting.
> 4. SA tables to aid low level troubleshooting.
> 5. Separation of IKE and IPsec groups to allow later
> extensions for
> other keying protocols to be used with IPsec (such as KINK).
>
> I'd very much like to hear comments on this from administrators
> or NMS developers who are facing the problem of monitoring
> and troubleshooting IPsec-based VPNs.
>
>
> Coexistence with other MIB drafts:
> Our proposal may be regarded as being competing or complementary to
> the low level MIBs proposed by Jenkins et al. To that extent,
> we are willing to layer our MIB on top of the basic definitions
> provided by the Jenkins drafts.
>
> In 1999, it was proposed that we use the ISAKMP and IPsec textual
> conventions proposed by Jenkins drafts. This is quite feasible
> since there is little difference between the TCs proposed by
> the two drafts.
>
>
> Please advise us on what we need to do in order to advance this MIB
> in the standards track.
>
> Thanks,
>
> Leo Temoshenko, Cisco Systems Inc.
> Cheryl Madson, Cisco Systems Inc.
> Chinna Pellacuru, Cisco Systems Inc.
> Bret Harrison, Tivoli Systems Inc.
> S Ramakrishnan, Cisco Systems Inc.
>
From owner-ipsec@lists.tislabs.com Thu Oct 11 07:11:31 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9BEBUD22434;
Thu, 11 Oct 2001 07:11:30 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25525
Thu, 11 Oct 2001 09:17:42 -0400 (EDT)
From: steve@tril-inc.com
To: ipsec@lists.tislabs.com
Subject: IPComp CPI's
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001
Message-ID: <OF4F4B79EF.B708F3A4-ON85256AE2.00460635@tril-inc.com>
Date: Thu, 11 Oct 2001 09:33:56 -0400
X-MIMETrack: Serialize by Router on lntril01/Servers/Trilogy(Release 5.0.6a |January 17, 2001) at
10/11/2001 09:24:20 AM,
Serialize complete at 10/11/2001 09:24:20 AM
Content-Type: multipart/alternative; boundary="=_alternative 004A9A6C85256AE2_="
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multipart message in MIME format.
--=_alternative 004A9A6C85256AE2_=
Content-Type: text/plain; charset="us-ascii"
Hello,
I have a question regarding the negotiation of IPComp CPI's vs. the use of
well known values. In looking at the IPComp RFC there seems to be some
ambiguity regarding the use of well-known CPI's (the CPI indicating the
compression algorithm) vs. negotiated CPI's.
If an initiator of Phase2 sends a well-known CPI for IPComp, what are the
requirements of the responding node? Can the responding node send a
response with a CPI in the negotiated range? If Phase2 completes with the
initiator using a well-known CPI and the responder is using a CPI in the
negotiated range, is the initiator required to use the CPI that was
negotiated during phase2?
Thanks for any insight.
Steven Erickson
Senior Software Engineer
Trilogy, Inc.
978-371-3980 x112
http://www.tril-inc.com
--=_alternative 004A9A6C85256AE2_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="sans-serif">Hello,</font>
<br>
<br><font size=2 face="sans-serif">I have a question regarding the negotiation of IPComp CPI's vs. the use of well known values. In looking at the IPComp RFC there seems to be some ambiguity regarding the use of well-known CPI's (the CPI indicating the compression algorithm) vs. negotiated CPI's. </font>
<br>
<br><font size=2 face="sans-serif">If an initiator of Phase2 sends a well-known CPI for IPComp, what are the requirements of the responding node? Can the responding node send a response with a CPI in the negotiated range? If Phase2 completes with the initiator using a well-known CPI and the responder is using a CPI in the negotiated range, is the initiator required to use the CPI that was negotiated during phase2? </font>
<br>
<br><font size=2 face="sans-serif">Thanks for any insight.</font>
<br>
<br><font size=2 face="sans-serif">Steven Erickson</font>
<br><font size=2 face="sans-serif">Senior Software Engineer</font>
<br><font size=2 face="sans-serif">Trilogy, Inc.</font>
<br><font size=2 face="sans-serif">978-371-3980 x112</font>
<br><font size=2 face="sans-serif">http://www.tril-inc.com</font>
<br>
<br>
--=_alternative 004A9A6C85256AE2_=--
From owner-ipsec@lists.tislabs.com Thu Oct 11 08:58:54 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9BFwrD02313;
Thu, 11 Oct 2001 08:58:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA25615
Thu, 11 Oct 2001 10:38:04 -0400 (EDT)
Message-Id: <5.1.0.14.0.20011011160409.02a5e820@dfintra.f-secure.com>
X-Sender: joern@dfintra.f-secure.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 11 Oct 2001 16:08:57 +0200
To: ipsec@lists.tislabs.com
From: Joern Sierwald <joern@f-secure.com>
Subject: Re: IPComp CPI's
In-Reply-To: <OF4F4B79EF.B708F3A4-ON85256AE2.00460635@tril-inc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA25554
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 09:33 11.10.2001 -0400, steve@tril-inc.com wrote:
>Hello,
>
>I have a question regarding the negotiation of IPComp CPI's vs. the use of
>well known values. In looking at the IPComp RFC there seems to be some
>ambiguity regarding the use of well-known CPI's (the CPI indicating the
>compression algorithm) vs. negotiated CPI's.
>
>If an initiator of Phase2 sends a well-known CPI for IPComp, what are the
>requirements of the responding node? Can the responding node send a
>response with a CPI in the negotiated range?
yes.
>If Phase2 completes with the initiator using a well-known CPI and the
>responder is using a CPI in the negotiated range, is the initiator
>required to use the CPI that was negotiated during phase2?
Each host can choose a CPI, and that will be used for the traffic he receives.
If the initiator uses CPI 2 and the responder CPI 50000 in QM, then all
traffic from i to r
will carry the CPI 50000, and all traffic from r to i the CPI 2.
>Thanks for any insight.
>
>Steven Erickson
>Senior Software Engineer
>Trilogy, Inc.
>978-371-3980 x112
>http://www.tril-inc.com
J–rn
From owner-ipsec@lists.tislabs.com Fri Oct 12 08:48:10 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9CFmAD06100;
Fri, 12 Oct 2001 08:48:10 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27936
Fri, 12 Oct 2001 10:32:36 -0400 (EDT)
Message-ID: <20011012144021.11092.qmail@web8004.mail.in.yahoo.com>
Date: Fri, 12 Oct 2001 15:40:21 +0100 (BST)
From: =?iso-8859-1?q?ranjeet=20barve?= <ranjeet_barve@yahoo.co.in>
Subject: DataStructure for Storing SPD,SA Entries
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
hi,
I had a quesiton on the Data Structure to use for
Security Policy Database and Security Association
Entries.
Which would be the most efficient Data Structure for
Storing SPD and SA entries ??
Which Data-Structure is Most Commonly used?
(I apologise if this question is already answered in
the mailing list.)
Please let me know.
Regards,
Ranjeet Barve,
M.Tech IIT Bombay.
____________________________________________________________
Do You Yahoo!?
Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com
From owner-ipsec@lists.tislabs.com Fri Oct 12 08:48:18 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9CFmID06127;
Fri, 12 Oct 2001 08:48:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27919
Fri, 12 Oct 2001 10:22:14 -0400 (EDT)
Message-ID: <20011012143007.6816.qmail@web8007.mail.in.yahoo.com>
Date: Fri, 12 Oct 2001 15:30:07 +0100 (BST)
From: =?iso-8859-1?q?ranjeet=20barve?= <ranjeet_barve@yahoo.co.in>
Subject: Implicit/Explicit IV
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
hi,
I had a question on the use of Implicit and Explicit
IV.
I have come across following Situations in the various
IPsec Implementations:
1) Implicit IV is used by generating it at the
respective peers by use of SEQ_ID.i.e
IV[0-3] = Seq-id;
IV[4-7] = ~Seq-id;
2) Explicit IV is used for the first Packet i.e IV is
generated Randomly + all following packets of the same
Tunnel use Implicit IV as the last 8 bytes of the
Cipher Text of the earlier Packet.
3) Explicit IV is used for all the Packets of a
particular Tunnel.
Does Cases 1 and 2, not lead to interoperabality issue
if both ends(Peers) are not using the same IPsec
Implementation? i.e How do different IPsec
Implementations Interop.
Which is the most standard way to use in Implicit IV
case?
I would be thankful if you could help me with the
above query.
Best Regards,
Ranjeet Barve,
M.Tech IIT Bombay.
____________________________________________________________
Do You Yahoo!?
Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com
From owner-ipsec@lists.tislabs.com Fri Oct 12 10:00:00 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9CGxxD10617;
Fri, 12 Oct 2001 10:00:00 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28150
Fri, 12 Oct 2001 12:14:17 -0400 (EDT)
content-class: urn:content-classes:message
Subject: Precedence on selectors, policy entries or both?
Date: Fri, 12 Oct 2001 12:22:29 -0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Message-ID: <A6D9D7495456414BA08DB655C2AC671205B1D3@bsebe001.NOE.Nokia.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: DataStructure for Storing SPD,SA Entries
Thread-Index: AcFTMxFllNTzY78kEdWBTQBQi2X+DwABCwuw
From: "Li Man.M (NRC/Boston)" <Man.M.Li@nokia.com>
To: <ipsec@lists.tislabs.com>
X-OriginalArrivalTime: 12 Oct 2001 16:22:48.0114 (UTC) FILETIME=[21AAE120:01C1533A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA28147
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi,
RFC 2401 specifies that "The SPD contains an ordered list of policy
entries". Now, if the selectors are ordered in SPD, the policy entries
are ordered since each selector points to a policy entries. Is this a
correct assumption?
I also see people give precedence to policy entries or policy rules. Is
this redundant since the selectors are already ordered? Could there be
potential conflict if both selectors and policy entries have precedence
orders?
Which one of the following is the common approach in SPD?
A. Give precedence to selectors only
B. Give precedence to policy entries only
C. Give precedence to both selectors and policy entries
Comments are appreciated. Thanks.
Man Li
From owner-ipsec@lists.tislabs.com Fri Oct 12 15:31:24 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9CMVOD18800;
Fri, 12 Oct 2001 15:31:24 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28851
Fri, 12 Oct 2001 17:25:02 -0400 (EDT)
Date: Fri, 12 Oct 2001 23:32:24 +0200
From: Marco Ender <marco.ender@dungeonmaster.at>
X-Mailer: The Bat! (v1.53bis) Educational
Reply-To: Marco Ender <marco.ender@dungeonmaster.at>
X-Priority: 3 (Normal)
Message-ID: <16733577243.20011012233224@dungeonmaster.at>
To: ipsec@lists.tislabs.com
Subject: Frequency of Phase 1 / Phase 2 Exchanges
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
How often are IPSec - Keys usually refreshed via a Quick Mode Exchange, and
how often are whole connections reestablished (sp?) via a Phase 1 Exchange?
In other words, what is the Phase 1 : Phase 2 Exchange Ratio? Since i
have _no_ experience with VPNs any Input would be great,
tia
Marco
From owner-ipsec@lists.tislabs.com Sat Oct 13 02:28:55 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9D9SsD08572;
Sat, 13 Oct 2001 02:28:54 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA29571
Sat, 13 Oct 2001 04:27:32 -0400 (EDT)
Message-ID: <003c01c153c2$c169ecf0$380310ac@cwcrrjkrrcfonk>
From: "Hong Gie Ong" <stuonghg@cwc.nus.edu.sg>
To: "Marco Ender" <marco.ender@dungeonmaster.at>, <ipsec@lists.tislabs.com>
References: <411389049.20011009154534@dungeonmaster.at><00b001c15212$bb39a250$380310ac@cwcrrjkrrcfonk> <1413809303.20011011125158@dungeonmaster.at>
Subject: Re: Re[2]: Calculating Cookies for ISAKMP - Header in IKE
Date: Sat, 13 Oct 2001 16:40:46 +0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Marco,
I think maybe my answer was a little confusing (or I was confused), anyway,
my previous answer below is maybe clearified by the comments after that:
> Hello,
>
> > but if you just send a random cookie how do you know if someone else
created
> > that cookie to make it look like it comes from the one you're trying to
> > correspond with ?
>
> > Using MD5 based on the IP-address in question and some secret value
makes
> > the outcome unique to both parties right ? So in that way you know that
it's
> > the same originator of the connection request ;
the outcome of the MD5 operation becomes unique based on the unique
IP-address of the initiator (and some parameters);
so in that sense the outcome is unique to both parties, because the MD5
result is with the initiator ( in the cookie reply from the responder) as
well as reconstructed at the responder;
so that is to prevent an attacker to intercept the cookie and modify the
IP-source address;
right ?
HG
From owner-ipsec@lists.tislabs.com Sat Oct 13 07:22:01 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9DEM1D25758;
Sat, 13 Oct 2001 07:22:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA29747
Sat, 13 Oct 2001 09:12:34 -0400 (EDT)
Date: 13 Oct 2001 13:20:56 -0000
Message-ID: <20011013132056.28103.qmail@mailweb30.rediffmail.com>
MIME-Version: 1.0
From: "sunil kumar chirra" <sunilchirra@rediffmail.com>
Reply-To: "sunil kumar chirra" <sunilchirra@rediffmail.com>
To: <ipsec@lists.tislabs.com>
Subject: simulation of IPSEC
Content-type: text/plain;
charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA29744
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi,
Can anybody suggest a good simulator for simulating ipsec protocols in wireless environment?
Thanks
Sunil
From owner-ipsec@lists.tislabs.com Sat Oct 13 13:47:06 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9DKl5D13393;
Sat, 13 Oct 2001 13:47:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00215
Sat, 13 Oct 2001 15:43:56 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p05010402b7ee4683246d@[128.33.238.195]>
In-Reply-To:
<A6D9D7495456414BA08DB655C2AC671205B1D3@bsebe001.NOE.Nokia.com>
References: <A6D9D7495456414BA08DB655C2AC671205B1D3@bsebe001.NOE.Nokia.com>
Date: Sat, 13 Oct 2001 15:33:08 -0400
To: "Li Man.M (NRC/Boston)" <Man.M.Li@nokia.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Precedence on selectors, policy entries or both?
Cc: <ipsec@lists.tislabs.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 12:22 PM -0400 10/12/01, Li Man.M (NRC/Boston) wrote:
>Hi,
>
>RFC 2401 specifies that "The SPD contains an ordered list of policy
>entries". Now, if the selectors are ordered in SPD, the policy entries
>are ordered since each selector points to a policy entries. Is this a
>correct assumption?
each SPD entry, keyed by selectors, specifies the policy to be
applied to the traffic that matches the selectors. the policy is
bypass, discard, or a specification of what IPsec processing must be
applied to the traffic.
>
>I also see people give precedence to policy entries or policy rules. Is
>this redundant since the selectors are already ordered? Could there be
>potential conflict if both selectors and policy entries have precedence
>orders?
given the above definition of what a policy is relative to an SPD
entry, there is no conflict, i.e., the SPD is searched to determine
the applicable policy. your confusion may stem from the use of the
term "policy" in a broader sense, in other contexts.
>
>Which one of the following is the common approach in SPD?
>
>A. Give precedence to selectors only
>B. Give precedence to policy entries only
>C. Give precedence to both selectors and policy entries
A is the right answer.
Steve
From owner-ipsec@lists.tislabs.com Sat Oct 13 13:47:08 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9DKl7D13405;
Sat, 13 Oct 2001 13:47:07 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00221
Sat, 13 Oct 2001 15:51:41 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p05010405b7ee4d08ac86@[128.33.238.247]>
In-Reply-To: <20011012143007.6816.qmail@web8007.mail.in.yahoo.com>
References: <20011012143007.6816.qmail@web8007.mail.in.yahoo.com>
Date: Sat, 13 Oct 2001 16:00:31 -0400
To: ranjeet barve <ranjeet_barve@yahoo.co.in>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Implicit/Explicit IV
Cc: ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 3:30 PM +0100 10/12/01, ranjeet barve wrote:
>hi,
>I had a question on the use of Implicit and Explicit
>IV.
>I have come across following Situations in the various
>IPsec Implementations:
>1) Implicit IV is used by generating it at the
>respective peers by use of SEQ_ID.i.e
> IV[0-3] = Seq-id;
> IV[4-7] = ~Seq-id;
>
>2) Explicit IV is used for the first Packet i.e IV is
>generated Randomly + all following packets of the same
>Tunnel use Implicit IV as the last 8 bytes of the
>Cipher Text of the earlier Packet.
>
>3) Explicit IV is used for all the Packets of a
>particular Tunnel.
>
>Does Cases 1 and 2, not lead to interoperabality issue
>if both ends(Peers) are not using the same IPsec
>Implementation? i.e How do different IPsec
>Implementations Interop.
>Which is the most standard way to use in Implicit IV
>case?
whether an IV is implicit or explicit is defined as part of the RFC
for the encryption algorithm and mode in question. thus, when
negotiating the algorithm/mode, each peer will know how to locate or
generate the IV.
case 3 above is clearly the default mode for DES or 3DES CBC. that is
the primary standard in use today. what RFC(s) define the modes you
allude to in cases 1 & 2?
Steve
From owner-ipsec@lists.tislabs.com Sun Oct 14 23:18:16 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9F6IGD19318;
Sun, 14 Oct 2001 23:18:16 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA01901
Mon, 15 Oct 2001 01:02:13 -0400 (EDT)
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
From: "Amey Gokhale" <agokhale@postmaster.co.uk>
Subject: Re: DataStructure for Storing SPD,SA Entries
To: ipsec@lists.tislabs.com
Date: Mon, 15 Oct 2001 06:10:46 +0100
X-Postmaster: Sent from Postmaster http://www.postmaster.co.uk/, the
world's premier free web-based email service, based in London, England.
X-Postmaster-Trace: Account name: agokhale; Local time: Mon Oct 15
06:10:46 2001; Local host: pmweb8.uk1.bibliotech.net; Remote host:
202.54.40.36; Referer site: www.postmaster.co.uk
X-Complaints-To: Administrator@postmaster.co.uk
Message-Id: <PM.18490.1003122646@pmweb8.uk1.bibliotech.net>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hello,
from the analysis of various data structures (linked list, balanced BST, unbalanced BST, hash table, skip lists) for their search / insert / delete time, hash table is found best.
also it;s avg. search time is O(1) for any number of entries in it(ordered or random)....provided selected hash function ensures unique distribution of keys.
i havn;t explored tries data structure. if anybody knows some understandable link on it, plz tell.
Regards,
Amey.
From owner-ipsec@lists.tislabs.com Mon Oct 15 04:49:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FBnhD20888;
Mon, 15 Oct 2001 04:49:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA02662
Mon, 15 Oct 2001 06:43:24 -0400 (EDT)
X-Mailer: exmh version 2.1.1 10/15/1999
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Amey Gokhale" <agokhale@postmaster.co.uk>
Cc: ipsec@lists.tislabs.com
Subject: Re: DataStructure for Storing SPD,SA Entries
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 15 Oct 2001 06:52:50 -0400
Message-Id: <20011015105250.C8E6D7B55@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <PM.18490.1003122646@pmweb8.uk1.bibliotech.net>, "Amey Gokhale" writ
es:
>hello,
>
>from the analysis of various data structures (linked list, balanced BST, unbal
>anced BST, hash table, skip lists) for their search / insert / delete time, ha
>sh table is found best.
>also it;s avg. search time is O(1) for any number of entries in it(ordered or
>random)....provided selected hash function ensures unique distribution of keys
>.
>
Remember that unless you have first expanded the entries, you have to
search the SPD in the order originally specified. I don't know how to
do that with a hash table.
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Mon Oct 15 06:57:15 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FDvFD26824;
Mon, 15 Oct 2001 06:57:15 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02829
Mon, 15 Oct 2001 08:57:55 -0400 (EDT)
Message-Id: <200110151256.UAA28677@csnet1>
Date: Mon, 15 Oct 2001 21:5:52 +0800
From: dxh <sleepy-cat@263.net>
Reply-To: sleepy-cat@263.net
To: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: how Nonce payload be used to prevent replay attack
X-mailer: FoxMail 3.11 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I am not very clear about that. Are there anybody can explain it to me?
I will be very appreciative for your help.
Dong Xiaohu
From owner-ipsec@lists.tislabs.com Mon Oct 15 11:13:59 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FIDwD13175;
Mon, 15 Oct 2001 11:13:58 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03550
Mon, 15 Oct 2001 13:05:21 -0400 (EDT)
Message-ID: <8B204D152222D51182B7000102884137202572@postmaster.cryptek.com>
From: "Aronson, David" <daronson@cryptek.com>
To: "'sleepy-cat@263.net'" <sleepy-cat@263.net>
Cc: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: RE: how Nonce payload be used to prevent replay attack
Date: Mon, 15 Oct 2001 13:23:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="GB2312"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
dxh (sleepy-cat@263.net) writes:
> I am not very clear about that. Are there anybody can
> explain it to me?
> I will be very appreciative for your help.
The basic idea seems to be, "quote this number I just made up back to me, or
I won't believe you're really carrying on a session". Someone simply
replaying old recorded packets won't be able to do that, because the old
stuff would have a different nonce.
--
Dave Aronson, Software Engineer, +1-571-434-2039 V, +1-571-434-2001 F.
Cryptek Secure Communications, 1501 Moran Rd., Sterling, VA 20166 USA.
Opinions above are MINE, ALL MINE -- but for rent at reasonable rates.
From owner-ipsec@lists.tislabs.com Mon Oct 15 11:54:01 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FIs0D13886;
Mon, 15 Oct 2001 11:54:00 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03662
Mon, 15 Oct 2001 13:54:03 -0400 (EDT)
Message-Id: <sbcaca2a.040@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Mon, 15 Oct 2001 11:36:40 -0600
From: "Hilarie Orman" <HORMAN@volera.com>
To: <agokhale@postmaster.co.uk>, <smb@research.att.com>
Cc: <ipsec@lists.tislabs.com>
Subject: Re: DataStructure for Storing SPD,SA Entries
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id NAA03603
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
If the SPD's are non-interfering, the hash table is fine. I'd guess that
these are the normal case for most configurations, but it's just a guess.
Hilarie
>>> "Steven M. Bellovin" <smb@research.att.com> 10/15/01 04:52AM >>>
In message <PM.18490.1003122646@pmweb8.uk1.bibliotech.net>, "Amey Gokhale" writ
es:
>hello,
>
>from the analysis of various data structures (linked list, balanced BST, unbal
>anced BST, hash table, skip lists) for their search / insert / delete time, ha
>sh table is found best.
>also it;s avg. search time is O(1) for any number of entries in it(ordered or
>random)....provided selected hash function ensures unique distribution of keys
>.
>
Remember that unless you have first expanded the entries, you have to
search the SPD in the order originally specified. I don't know how to
do that with a hash table.
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Mon Oct 15 12:03:14 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FJ3DD14069;
Mon, 15 Oct 2001 12:03:13 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03697
Mon, 15 Oct 2001 14:10:38 -0400 (EDT)
X-Mailer: exmh version 2.1.1 10/15/1999
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Hilarie Orman" <HORMAN@volera.com>
Cc: agokhale@postmaster.co.uk, ipsec@lists.tislabs.com
Subject: Re: DataStructure for Storing SPD,SA Entries
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 15 Oct 2001 14:19:18 -0400
Message-Id: <20011015181918.C81797B55@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <sbcaca2a.040@prv-mail20.provo.novell.com>, "Hilarie Orman" writes:
>If the SPD's are non-interfering, the hash table is fine. I'd guess that
>these are the normal case for most configurations, but it's just a guess.
>
Sure -- but you have to verify that first, and if there are rules that do
interfere you need a backup datastructure or you need to expand the
SPD, which again takes checking and special code.
I'm not objecting to hash tables -- *if* they're applicable. My note
was more a caution on applicability.
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Mon Oct 15 12:17:22 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FJHMD14427;
Mon, 15 Oct 2001 12:17:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03783
Mon, 15 Oct 2001 14:37:36 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010411b7f0ddd020a9@[128.33.84.34]>
In-Reply-To: <20011015181918.C81797B55@berkshire.research.att.com>
References: <20011015181918.C81797B55@berkshire.research.att.com>
Date: Mon, 15 Oct 2001 14:39:51 -0400
To: "Steven M. Bellovin" <smb@research.att.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: DataStructure for Storing SPD,SA Entries
Cc: "Hilarie Orman" <HORMAN@volera.com>, agokhale@postmaster.co.uk,
ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 2:19 PM -0400 10/15/01, Steven M. Bellovin wrote:
>In message <sbcaca2a.040@prv-mail20.provo.novell.com>, "Hilarie Orman" writes:
>>If the SPD's are non-interfering, the hash table is fine. I'd guess that
>>these are the normal case for most configurations, but it's just a guess.
>>
>
>Sure -- but you have to verify that first, and if there are rules that do
>interfere you need a backup datastructure or you need to expand the
>SPD, which again takes checking and special code.
>
>I'm not objecting to hash tables -- *if* they're applicable. My note
>was more a caution on applicability.
>
> --Steve Bellovin, http://www.research.att.com/~smb
> Full text of "Firewalls" book now at http://www.wilyhacker.com
Since SPD rules are very similar to firewall filters, and these are
often overlapping, I would not anticipate independence unless great
care was taken to ensure it.
Steve
From owner-ipsec@lists.tislabs.com Mon Oct 15 14:14:10 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9FLE9D16934;
Mon, 15 Oct 2001 14:14:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04244
Mon, 15 Oct 2001 16:22:57 -0400 (EDT)
Message-ID: <3BCB4730.4738E57A@research.bell-labs.com>
Date: Mon, 15 Oct 2001 16:29:36 -0400
From: Sandeep Joshi <sandeepj@research.bell-labs.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "'sleepy-cat@263.net'" <sleepy-cat@263.net>
CC: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Re: how Nonce payload be used to prevent replay attack
References: <8B204D152222D51182B7000102884137202572@postmaster.cryptek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
"Aronson, David" wrote:
>
> dxh (sleepy-cat@263.net) writes:
>
> > I am not very clear about that. Are there anybody can
> > explain it to me?
> > I will be very appreciative for your help.
>
> The basic idea seems to be, "quote this number I just made up back to me, or
> I won't believe you're really carrying on a session". Someone simply
> replaying old recorded packets won't be able to do that, because the old
> stuff would have a different nonce.
..And such a nonce is easier to verify (in terms of CPU time
and memory state) than an ack payload based on a crypto function.
-Sandeep
>
> --
> Dave Aronson, Software Engineer, +1-571-434-2039 V, +1-571-434-2001 F.
> Cryptek Secure Communications, 1501 Moran Rd., Sterling, VA 20166 USA.
> Opinions above are MINE, ALL MINE -- but for rent at reasonable rates.
From owner-ipsec@lists.tislabs.com Tue Oct 16 15:32:46 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9GMWkD11031;
Tue, 16 Oct 2001 15:32:46 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06569
Tue, 16 Oct 2001 17:21:08 -0400 (EDT)
Message-ID: <594B0AA59AE5F74D875F55C5F56EE4FF032AD7@01mail.nomadix.com>
From: Bikramjit Singh <BSingh@Nomadix.com>
To: "'jhardin@wolfenet.com'" <jhardin@wolfenet.com>
Subject: ipsec masqueradin
Date: Tue, 16 Oct 2001 14:18:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C15688.26DCA560"
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_01C15688.26DCA560
Content-Type: text/plain;
charset="iso-8859-1"
Hi
I am implementing an IPsec masquerading service for vxWorks for our
product. I had some questions... I would appreciate if somebody could
clarify them for me.
* is ISAKMP icookie masquerading acceptable or the remote server
has some way of distinguishing icookies coming from the source security
gateway / masquerading gateway and will reject if the masquerading
gateway changes the icookie value.
* is there a way to distinguish tunnel mode from transport mode
just by looking at an ESP packet.
* is there any relation between the ISAKMP icookie and the ESP SPI
( i mean is the value of SPI dependent on the icookie value or is it
pretty much a random selection from a range of unused SPIs).
Thanks a lot
-Bik
------------------------------------------------------------------------
------------------
Bik Singh 818-575-2518 (Off)
Research Scientist 818-597-1502 (Fax)
Product Development 31355 Agoura Road
Nomadix Westlake Village, CA 91361
------_=_NextPart_001_01C15688.26DCA560
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>ipsec masqueradin</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2 FACE=3D"Arial">Hi</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">I am implementing an IPsec =
masquerading service for vxWorks for our product. I had some =
questions... I would appreciate if somebody could clarify them for =
me.</FONT></P>
<P><FONT FACE=3D"Arial">=A0</FONT>
</P>
<UL><LI><FONT SIZE=3D2 FACE=3D"Arial">is ISAKMP icookie masquerading =
acceptable or the remote server has some way of distinguishing icookies =
coming from the source security gateway / masquerading gateway and will =
reject if the masquerading gateway changes the icookie =
value.</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">is there a way to distinguish tunnel =
mode from transport mode just by looking at an ESP packet.</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">is there any relation between the =
ISAKMP icookie and the ESP SPI ( i mean is the value of SPI dependent =
on the icookie value or is it pretty much a random selection from a =
range of unused SPIs).</FONT></LI>
<BR>
</UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks a lot</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-Bik</FONT>
</P>
<P><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
---------------------------------</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Bik =
Singh=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 818-575-2518 (Off)</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Research =
Scientist=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
818-597-1502 (Fax)</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Product =
Development=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A031355 =
Agoura Road</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Nomadix =A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 Westlake Village, CA =
91361</FONT><FONT FACE=3D"Arial"> </FONT>
</P>
<P><FONT FACE=3D"Arial">=A0</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C15688.26DCA560--
From owner-ipsec@lists.tislabs.com Tue Oct 16 15:36:50 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9GMaoD11091;
Tue, 16 Oct 2001 15:36:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06642
Tue, 16 Oct 2001 17:56:22 -0400 (EDT)
Message-ID: <594B0AA59AE5F74D875F55C5F56EE4FF032AD9@01mail.nomadix.com>
From: Bikramjit Singh <BSingh@Nomadix.com>
To: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Date: Tue, 16 Oct 2001 14:56:44 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C1568D.71A830F0"
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_01C1568D.71A830F0
Content-Type: text/plain;
charset="iso-8859-1"
Hi
I am implementing an IPsec masquerading service for vxWorks for our product.
I had some questions... I would appreciate if somebody could clarify them
for me.
is ISAKMP icookie masquerading acceptable or the remote server has
some way of distinguishing icookies coming from the source security gateway
/ masquerading gateway and will reject if the masquerading gateway changes
the icookie value.
is there a way to distinguish tunnel mode from transport mode just
by looking at an ESP packet.
is there any relation between the ISAKMP icookie and the ESP SPI ( i
mean is the value of SPI dependent on the icookie value or is it pretty much
a random selection from a range of unused SPIs).
Thanks a lot
-Bik
----------------------------------------------------------------------------
--------------
Bik Singh 818-575-2518 (Off)
Research Scientist 818-597-1502 (Fax)
Product Development 31355 Agoura Road
Nomadix Westlake Village, CA 91361
------_=_NextPart_001_01C1568D.71A830F0
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">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><FONT size=3D2>
<P>Hi</P></FONT><FONT size=3D2>
<P>I am implementing an IPsec masquerading service for vxWorks for our =
product.=20
I had some questions... I would appreciate if somebody could clarify =
them for=20
me.</P></FONT>
<P></P>
<DIR><FONT size=3D2>
<P>is ISAKMP icookie masquerading acceptable or the remote server has =
some way=20
of distinguishing icookies coming from the source security gateway /=20
masquerading gateway and will reject if the masquerading gateway =
changes the=20
icookie value.</P>
<P>is there a way to distinguish tunnel mode from transport mode just =
by looking=20
at an ESP packet.</P>
<P>is there any relation between the ISAKMP icookie and the ESP SPI ( i =
mean is=20
the value of SPI dependent on the icookie value or is it pretty much a =
random=20
selection from a range of unused SPIs).</P></FONT></DIR><FONT size=3D2>
<P>Thanks a lot</P></FONT>
<P></P><FONT size=3D2>
<P>-Bik</P></FONT></FONT></DIV>
<P><FONT face=3DArial=20
size=3D2>---------------------------------------------------------------=
---------------------------</FONT>=20
<BR><FONT face=3DArial size=3D2>Bik=20
Singh &=
nbsp; &=
nbsp; =20
818-575-2518 (Off)</FONT> <BR><FONT face=3DArial size=3D2>Research=20
Scientist &nb=
sp; =20
818-597-1502 (Fax)</FONT> <BR><FONT face=3DArial size=3D2>Product=20
Development &=
nbsp; 31355=20
Agoura Road</FONT> <BR><FONT face=3DArial size=3D2>Nomadix=20
=20
=20
Westlake Village, CA =
91361</FONT>=20
</P>
<DIV> </DIV></BODY></HTML>
------_=_NextPart_001_01C1568D.71A830F0--
From owner-ipsec@lists.tislabs.com Wed Oct 17 22:35:02 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9I5Z1D27916;
Wed, 17 Oct 2001 22:35:02 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA09781
Thu, 18 Oct 2001 00:13:11 -0400 (EDT)
Message-ID: <20011018042107.97593.qmail@web8004.mail.in.yahoo.com>
Date: Thu, 18 Oct 2001 05:21:07 +0100 (BST)
From: =?iso-8859-1?q?ranjeet=20barve?= <ranjeet_barve@yahoo.co.in>
Subject: Re: DataStructure for Storing SPD,SA Entries
To: Puja Puri <puja.puri@cdac.ernet.in>
Cc: ipsec@lists.tislabs.com
In-Reply-To: <01a101c156cd$eb8f3540$30cd09c0@puja>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi,
With Hash Table finding an efficient hash function
seems to be a major Problem. Also as the Selector
contains of a number of fields, it would make the task
even complicated. Which Implementations are using Hash
Tables for storing SPD and SAD? What kind of hash
functions do they use??
Also does the range queries with wild cards not create
a major problem in formulating a Hash Function??
Does any implementation use Tries for Storing SPD,SAD?
Please help me with the above queries,
Regards,
Ranjeet Barve,
M.Tech IIT Bombay.
--- Puja Puri <puja.puri@cdac.ernet.in> wrote: > hi
> Hash tables seem to be good for SPD n SAD, since
> search is faster than many
> other data structures. It is used by many toolkits
> which implement IPSec.
>
> Just need to take care that policies don't overlap
> Correct me anybody if I am wrong.
> regds
> puja
> ----- Original Message -----
> From: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
> To: <ipsec@lists.tislabs.com>
> Sent: Friday, October 12, 2001 8:10 PM
> Subject: DataStructure for Storing SPD,SA Entries
>
>
> > hi,
> > I had a quesiton on the Data Structure to use for
> > Security Policy Database and Security Association
> > Entries.
> > Which would be the most efficient Data Structure
> for
> > Storing SPD and SA entries ??
> > Which Data-Structure is Most Commonly used?
> > (I apologise if this question is already answered
> in
> > the mailing list.)
> >
> > Please let me know.
> >
> > Regards,
> > Ranjeet Barve,
> > M.Tech IIT Bombay.
> >
> >
> >
> >
>
____________________________________________________________
> > Do You Yahoo!?
> > Send a newsletter, share photos & files, conduct
> polls, organize chat
> events. Visit http://in.groups.yahoo.com
>
____________________________________________________________
*NEW* Connect to Yahoo! Messenger through your mobile phone *NEW*
Visit http://in.mobile.yahoo.com/smsmgr_signin.html
From owner-ipsec@lists.tislabs.com Wed Oct 17 22:46:51 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9I5kpD28081;
Wed, 17 Oct 2001 22:46:51 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA09926
Thu, 18 Oct 2001 01:01:38 -0400 (EDT)
Message-ID: <013701c15793$a90216e0$30cd09c0@puja>
From: "Puja Puri" <puja.puri@cdac.ernet.in>
To: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
Cc: <ipsec@lists.tislabs.com>
References: <20011018042107.97593.qmail@web8004.mail.in.yahoo.com>
Subject: Re: DataStructure for Storing SPD,SA Entries
Date: Thu, 18 Oct 2001 10:43:39 +0530
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.6700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
hi
Its true that finding an efficient hash function seems to be a major problem
but then once that is done, hash tables prove to be efficient. Rajesh, I
suggest u to do some r&d on hash function to find a suitable one for you.
For instance the hi/fn toolkit for IPSec uses hash tables. But unfortunately
such implementations don't mention about their hash functions.
The selectors do contain a number of fields but remember that according to
RFC 2401 u can use one or more fields from selectors to map to ur policies.
This makes life simpler.
The queries with wildcards do create some problem but that can be sorted out
with the way u implement.
As far as tries are concerned, I have no idea whether any implementations
use it or not.
I hope Rajesh that atleast i have tried answering all your queries.
regds
puja
----- Original Message -----
From: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
To: "Puja Puri" <puja.puri@cdac.ernet.in>
Cc: <ipsec@lists.tislabs.com>
Sent: Thursday, October 18, 2001 9:51 AM
Subject: Re: DataStructure for Storing SPD,SA Entries
> hi,
> With Hash Table finding an efficient hash function
> seems to be a major Problem. Also as the Selector
> contains of a number of fields, it would make the task
> even complicated. Which Implementations are using Hash
> Tables for storing SPD and SAD? What kind of hash
> functions do they use??
>
> Also does the range queries with wild cards not create
> a major problem in formulating a Hash Function??
> Does any implementation use Tries for Storing SPD,SAD?
>
> Please help me with the above queries,
>
> Regards,
> Ranjeet Barve,
> M.Tech IIT Bombay.
>
>
>
> --- Puja Puri <puja.puri@cdac.ernet.in> wrote: > hi
> > Hash tables seem to be good for SPD n SAD, since
> > search is faster than many
> > other data structures. It is used by many toolkits
> > which implement IPSec.
> >
> > Just need to take care that policies don't overlap
> > Correct me anybody if I am wrong.
> > regds
> > puja
> > ----- Original Message -----
> > From: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
> > To: <ipsec@lists.tislabs.com>
> > Sent: Friday, October 12, 2001 8:10 PM
> > Subject: DataStructure for Storing SPD,SA Entries
> >
> >
> > > hi,
> > > I had a quesiton on the Data Structure to use for
> > > Security Policy Database and Security Association
> > > Entries.
> > > Which would be the most efficient Data Structure
> > for
> > > Storing SPD and SA entries ??
> > > Which Data-Structure is Most Commonly used?
> > > (I apologise if this question is already answered
> > in
> > > the mailing list.)
> > >
> > > Please let me know.
> > >
> > > Regards,
> > > Ranjeet Barve,
> > > M.Tech IIT Bombay.
> > >
> > >
> > >
> > >
> >
> ____________________________________________________________
> > > Do You Yahoo!?
> > > Send a newsletter, share photos & files, conduct
> > polls, organize chat
> > events. Visit http://in.groups.yahoo.com
> >
>
> ____________________________________________________________
> *NEW* Connect to Yahoo! Messenger through your mobile phone *NEW*
> Visit http://in.mobile.yahoo.com/smsmgr_signin.html
From owner-ipsec@lists.tislabs.com Thu Oct 18 00:42:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9I7glD15626;
Thu, 18 Oct 2001 00:42:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA10128
Thu, 18 Oct 2001 02:49:05 -0400 (EDT)
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
From: "Amey Gokhale" <agokhale@postmaster.co.uk>
Subject: Re:
To: Bikramjit Singh <BSingh@Nomadix.com>
Cc: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Date: Thu, 18 Oct 2001 07:57:37 +0100
X-Postmaster: Sent from Postmaster http://www.postmaster.co.uk/, the
world's premier free web-based email service, based in London, England.
X-Postmaster-Trace: Account name: agokhale; Local time: Thu Oct 18
07:57:37 2001; Local host: pmweb7.uk1.bibliotech.net; Remote host:
196.1.109.11; Referer site: www.postmaster.co.uk
X-Complaints-To: Administrator@postmaster.co.uk
Message-Id: <PM.6785.1003388257@pmweb7.uk1.bibliotech.net>
Content-Type: multipart/mixed; boundary="----------=_1003388257-6785-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format...
------------=_1003388257-6785-1
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
Hello,
next header field(which determines coming payload as IP payload or TCP payload) in ESP trailer is in encrypted form hence i don;t think there will be any way to determine the mode of ESP packet(transport/tunnel) when packet is in transit.
Regards,
Amey.
On Tue, 16 Oct 2001 14:56:44 -0700
Bikramjit Singh <BSingh@Nomadix.com> wrote:
>
> is there a way to distinguish tunnel mode from transport mode just
> by looking at an ESP packet.
>
------------=_1003388257-6785-1
Content-Type: text/html
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
<!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.50.4134.600" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><FONT size=2>
<P>Hi</P></FONT><FONT size=2>
<P>I am implementing an IPsec masquerading service for vxWorks for our product.
I had some questions... I would appreciate if somebody could clarify them for
me.</P></FONT>
<P></P>
<DIR><FONT size=2>
<P>is ISAKMP icookie masquerading acceptable or the remote server has some way
of distinguishing icookies coming from the source security gateway /
masquerading gateway and will reject if the masquerading gateway changes the
icookie value.</P>
<P>is there a way to distinguish tunnel mode from transport mode just by looking
at an ESP packet.</P>
<P>is there any relation between the ISAKMP icookie and the ESP SPI ( i mean is
the value of SPI dependent on the icookie value or is it pretty much a random
selection from a range of unused SPIs).</P></FONT></DIR><FONT size=2>
<P>Thanks a lot</P></FONT>
<P></P><FONT size=2>
<P>-Bik</P></FONT></FONT></DIV>
<P><FONT face=Arial
size=2>------------------------------------------------------------------------------------------</FONT>
<BR><FONT face=Arial size=2>Bik
Singh
818-575-2518 (Off)</FONT> <BR><FONT face=Arial size=2>Research
Scientist
818-597-1502 (Fax)</FONT> <BR><FONT face=Arial size=2>Product
Development 31355
Agoura Road</FONT> <BR><FONT face=Arial size=2>Nomadix
Westlake Village, CA 91361</FONT>
</P>
<DIV> </DIV></BODY></HTML>
------------=_1003388257-6785-1--
From owner-ipsec@lists.tislabs.com Thu Oct 18 06:16:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9IDGvD10038;
Thu, 18 Oct 2001 06:16:57 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10657
Thu, 18 Oct 2001 08:11:24 -0400 (EDT)
From: Steve.Robinson@psti.com
Subject: Re: DataStructure for Storing SPD,SA Entries
To: "Puja Puri" <puja.puri@cdac.ernet.in>
Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com,
"ranjeet barve" <ranjeet_barve@yahoo.co.in>
X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000
Message-ID: <OF230F9B30.92656D16-ON80256AE9.00435881@psti.com>
Date: Thu, 18 Oct 2001 08:25:20 -0400
X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.8 |June 18, 2001) at 10/18/2001
01:25:59 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I use three tries in my implementation -- but it really isn't the relevant
issue here. It sounds to me like you are really glossing over the issue of
overlapping policy. If you do not implement a decorrelation algorithm, you
are probably going to cause yourself some major problems down the road.
Are you going to be hardcoding the policy values in yourself, or are you
going to be selling a product that will have the policies loaded by a
system administrator after the sale? Assuming the latter case is correct,
and you insist on using a hash lookup, then you really should guarantee
that your product will not overlap the policies ever -- don't blame the
system administrators for not using the product correctly if the initial
design is not robust and able to separate the policies dynamically in the
field.
Steve
"Puja Puri"
<puja.puri@cdac.ern To: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
et.in> cc: <ipsec@lists.tislabs.com>
Sent by: Subject: Re: DataStructure for Storing SPD,SA Entries
owner-ipsec@lists.t
islabs.com
10/18/01 01:13 AM
hi
Its true that finding an efficient hash function seems to be a major
problem
but then once that is done, hash tables prove to be efficient. Rajesh, I
suggest u to do some r&d on hash function to find a suitable one for you.
For instance the hi/fn toolkit for IPSec uses hash tables. But
unfortunately
such implementations don't mention about their hash functions.
The selectors do contain a number of fields but remember that according to
RFC 2401 u can use one or more fields from selectors to map to ur policies.
This makes life simpler.
The queries with wildcards do create some problem but that can be sorted
out
with the way u implement.
As far as tries are concerned, I have no idea whether any implementations
use it or not.
I hope Rajesh that atleast i have tried answering all your queries.
regds
puja
----- Original Message -----
From: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
To: "Puja Puri" <puja.puri@cdac.ernet.in>
Cc: <ipsec@lists.tislabs.com>
Sent: Thursday, October 18, 2001 9:51 AM
Subject: Re: DataStructure for Storing SPD,SA Entries
> hi,
> With Hash Table finding an efficient hash function
> seems to be a major Problem. Also as the Selector
> contains of a number of fields, it would make the task
> even complicated. Which Implementations are using Hash
> Tables for storing SPD and SAD? What kind of hash
> functions do they use??
>
> Also does the range queries with wild cards not create
> a major problem in formulating a Hash Function??
> Does any implementation use Tries for Storing SPD,SAD?
>
> Please help me with the above queries,
>
> Regards,
> Ranjeet Barve,
> M.Tech IIT Bombay.
>
>
>
> --- Puja Puri <puja.puri@cdac.ernet.in> wrote: > hi
> > Hash tables seem to be good for SPD n SAD, since
> > search is faster than many
> > other data structures. It is used by many toolkits
> > which implement IPSec.
> >
> > Just need to take care that policies don't overlap
> > Correct me anybody if I am wrong.
> > regds
> > puja
> > ----- Original Message -----
> > From: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
> > To: <ipsec@lists.tislabs.com>
> > Sent: Friday, October 12, 2001 8:10 PM
> > Subject: DataStructure for Storing SPD,SA Entries
> >
> >
> > > hi,
> > > I had a quesiton on the Data Structure to use for
> > > Security Policy Database and Security Association
> > > Entries.
> > > Which would be the most efficient Data Structure
> > for
> > > Storing SPD and SA entries ??
> > > Which Data-Structure is Most Commonly used?
> > > (I apologise if this question is already answered
> > in
> > > the mailing list.)
> > >
> > > Please let me know.
> > >
> > > Regards,
> > > Ranjeet Barve,
> > > M.Tech IIT Bombay.
> > >
> > >
> > >
> > >
> >
> ____________________________________________________________
> > > Do You Yahoo!?
> > > Send a newsletter, share photos & files, conduct
> > polls, organize chat
> > events. Visit http://in.groups.yahoo.com
> >
>
> ____________________________________________________________
> *NEW* Connect to Yahoo! Messenger through your mobile phone *NEW*
> Visit http://in.mobile.yahoo.com/smsmgr_signin.html
From owner-ipsec@lists.tislabs.com Thu Oct 18 07:00:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9IE0hD12099;
Thu, 18 Oct 2001 07:00:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10745
Thu, 18 Oct 2001 09:15:50 -0400 (EDT)
Message-ID: <20011018044456.94863.qmail@web21104.mail.yahoo.com>
Date: Wed, 17 Oct 2001 21:44:56 -0700 (PDT)
From: Smith Geo <lpgone_2001@yahoo.com>
Subject: A short letter about VPN security
To: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dear Sir£¬
I'm very interesting in VPN security. A problem
troubles me, but I don't know wether it is worth
proposing.
How to solve overlay of security function in a layered
protocol stack? For example, in a security VPN
implemention of "L2TP over IPSec", perhaps it has
carried out encryption in a private network, but when
a private packet is handled by IPSec, the second
encryption is applied. However£¬if the edge VPN
device doesn't do encryption process to the incoming
private packet, the control information field or other
fields that can't be encrypted in a private network
will be exposed to the public network.So attackers can
analyse the private traffic and so it will result in
many potential threats.
Is it not serious in a VPN?
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
From owner-ipsec@lists.tislabs.com Thu Oct 18 08:02:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9IF2mD15984;
Thu, 18 Oct 2001 08:02:48 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10853
Thu, 18 Oct 2001 10:04:10 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <p0501040ab7f39fc5c237@[10.1.70.94]>
In-Reply-To:
<B0080705FCBED41187750050DA1C154A030743@amindmail.india.ambernetworks.com>
References:
<B0080705FCBED41187750050DA1C154A030743@amindmail.india.ambernetworks.com>
Date: Wed, 17 Oct 2001 16:53:21 -0400
To: Raghunath Tilak <tilak@ambernetworks.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: Question regarding sensitivity check in RFC 2401
Cc: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 9:27 AM +0530 10/11/01, Raghunath Tilak wrote:
>Hello experts,
>
>I have some questions regarding Sensitivity Level & check on it.
>
>1. RFC 2401 (Security Arch) gives references to RFC 1108 for senitivity
> levels associated with a packet.
> RFC 1108 (IPSO) suggests use of option fields in IP header to associate
> security levels to the packets. These labels can then be used in
> MLS capable implementation of IPsec. The RFC 1108 assumes IPv4 case.
> What is the equivalent of this in IPv6 world? I did not find any reference
> in RFC 2460 (IP v6).
>
>2. This is regarding the sensitivity check.
> How does one determine the value to be compared against
>sensitivity information
> that is extracted from the packet? The paragraph 8.2 in RFC 2401
>gives 3 options.
>
> Sensitivity level associated with a particular output interface
> Sensitivity level associated with the IP source address of the packet
> Sensitivity level associated with the IP destination address
>of the final
> IP packet.
>
> Can an implementation use any one of them or say the least
>sensitive of the three
> for security check?
>
>I appreciate your help in this regard.
>
>Raghu Tilak
>Amber Networks India Pvt Ltd
>
>
the selection of a sensitivity level source for reference depends on
your environment. only if you are operating in an information flow
security policy environment does any of this apply. if you operate in
such an environment, you will be able to figure out the answer to
your question.
steve
From owner-ipsec@lists.tislabs.com Thu Oct 18 09:43:23 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9IGhMD22012;
Thu, 18 Oct 2001 09:43:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11155
Thu, 18 Oct 2001 11:49:27 -0400 (EDT)
Message-ID: <20011018155457.40430.qmail@web10401.mail.yahoo.com>
Date: Thu, 18 Oct 2001 08:54:57 -0700 (PDT)
From: Saroop Mathur <saroop1@yahoo.com>
Subject: Re: DataStructure for Storing SPD,SA Entries
To: Puja Puri <puja.puri@cdac.ernet.in>,
ranjeet barve <ranjeet_barve@yahoo.co.in>
Cc: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
IPSEC policy data structures need two properties: handling overlapping
policies and maintianing an ordered list. Hash tables generally do not
have these properties, although they could be designed for this
purpose.
Trees are the most efficient data structure that I have found for
storing IPSEC policies. I have seen an implementation perform policy
lookups with an average time of less than 10 microseconds with
1,000,000 policies in the SPD. Of course, in real deployments, you are
unlikely to have that many policy entries.
For best performance, my sugggestion would be to break up a policy into
selectors and organize the selectors in a tree. For very high
performance, you can use hardware to lookup policies.
-Saroop Mathur
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
From owner-ipsec@lists.tislabs.com Thu Oct 18 09:51:03 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9IGp3D22145;
Thu, 18 Oct 2001 09:51:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11170
Thu, 18 Oct 2001 11:53:23 -0400 (EDT)
Message-ID: <8B204D152222D51182B7000102884137202584@postmaster.cryptek.com>
From: "Aronson, David" <daronson@cryptek.com>
To: "'Smith Geo'" <lpgone_2001@yahoo.com>
Cc: ipsec@lists.tislabs.com
Subject: RE: A short letter about VPN security
Date: Thu, 18 Oct 2001 12:11:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 LAA11167
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
(First my usual disclaimer: I'm very new to both security and VPNs, and
somewhat new to networking in general. If I say anything wrong, feel free
to correct me -- it'll just help me learn.)
Smith Geo <lpgone_2001@yahoo.com> writes:
> A problem troubles me, but I don't know wether it is worth
> proposing.
We won't know 'til you ask....
> How to solve overlay of security function in a layered protocol stack?
Keep them in order, and each one's output will simply be input for the next
one. For instance, you can have an IPsec-based VPN running over modems that
scramble the data at that layer, serving an application that also uses
encryption at its layer. None of these layers know, let alone care, about
the others, so long as lower ones can provide all the services needed by the
higher ones.
> For example, in a security VPN
> implemention of "L2TP over IPSec", perhaps it has
> carried out encryption in a private network, but when
> a private packet is handled by IPSec, the second
> encryption is applied. However£¬if the edge VPN
> device doesn't do encryption process to the incoming
> private packet, the control information field or other
> fields that can't be encrypted in a private network
> will be exposed to the public network.So attackers can
> analyse the private traffic and so it will result in
> many potential threats.
>
> Is it not serious in a VPN?
Yes, assuming that the data in question is of such a nature that the
information typically exposed by traffic analysis attacks really matters.
So make sure that anything from your gateways to the public Internet is
encapsulated and encrypted. Then, all an attacker knows is that there's
X-amount of traffic from gateway A to gateway B, and nothing about traffic
behind the gateways, including even what endpoints exist. If the amount of
traffic between your gateways is still a concern for analysis purposes,
there are numerous other ways to deal with that, like creating dummy
traffic, tagging your traffic with priorities so as to make it seem like
less now and more later (by delaying the extremely low priority stuff),
making it seem to come from multiple points, making it seem to be bound for
multiple points, etc.
--
Dave Aronson, Software Engineer, +1-571-434-2039 V, +1-571-434-2001 F.
Cryptek Secure Communications, 1501 Moran Rd., Sterling, VA 20166 USA.
Opinions above are MINE, ALL MINE -- but for rent at reasonable rates.
From owner-ipsec@lists.tislabs.com Thu Oct 18 19:26:12 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9J2QBD04288;
Thu, 18 Oct 2001 19:26:11 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA12022
Thu, 18 Oct 2001 21:20:36 -0400 (EDT)
Message-Id: <200110190120.JAA05933@csnet1>
Date: Fri, 19 Oct 2001 9:29:57 +0800
From: dxh <sleepy-cat@263.net>
Reply-To: sleepy-cat@263.net
To: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: question about Nonce
X-mailer: FoxMail 3.11 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I am not sure if the nonce in Phase One is the same as
the one in Phase two. And I still can not see why there is
need using nonce to prevent from replay attacking in Phase
One. I think the Kes of DH exch can do this.
Dong Xiaohu
From owner-ipsec@lists.tislabs.com Thu Oct 18 22:14:33 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9J5EWD12244;
Thu, 18 Oct 2001 22:14:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA12254
Fri, 19 Oct 2001 00:15:50 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
content-class: urn:content-classes:message
Subject: RE: DataStructure for Storing SPD,SA Entries
Date: Thu, 18 Oct 2001 21:23:14 -0700
Message-ID: <2E33960095B58E40A4D3345AB9F65EC102EE6854@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: DataStructure for Storing SPD,SA Entries
Thread-Index: AcFX0fJrOzdLJN+KTvKAU3KJZM7JLQAfioLA
From: "William Dixon" <wdixon@windows.microsoft.com>
To: <Steve.Robinson@psti.com>, "Puja Puri" <puja.puri@cdac.ernet.in>
Cc: <ipsec@lists.tislabs.com>, "ranjeet barve" <ranjeet_barve@yahoo.co.in>
X-OriginalArrivalTime: 19 Oct 2001 04:23:16.0057 (UTC) FILETIME=[C6020490:01C15855]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Deconflicting overlapping policy (e.g. port ranges, subnets, all TCP to
Any IP vs. All traffic to 1.1.1.1) was the main point why RFC 2401 says
filters must be manually ordered.
However, I'll posit that, when talking about IP packet filters that are
matched only at the IP level (or below), manual ordering is enforceable
only if your policy comes from one source. Clearly if policy comes from
two sources, and if it overlaps, it would be impossible to guarantee the
outcome of each original manual ordering. If your run-time effective
policy comes from a static policy definition, then enhanced from a local
command line, possibly enhanced by local service or application API
calls to protect their traffic, and perhaps filters are generated by a
default response policy (accept whatever is proposed by the initiator)
when nothing else matches inbound IKE QM requests, then you must have an
automatic, total ordering, decorrelation algorithm.
With many new IETF protocols specifying their traffic to be protected by
IPsec, and some like iFCP in the IP Storage group requiring tunneling
mode instead of transport mode, enforcing strict admin manual ordering
of filters in the static policy he applied last week does not appear to
be feasible for an end-system.
To the extent possible, I've encouraged other protocols to request IPSec
transport mode 5-tuple specific IPsec SA pairs. This is how L2TP
requests IKE quick mode to establish an SA pair for src me, dst gw, UDP,
src <specific>, dst 1701.
However, many people have argued that they want an IPSec SA established
for TCP src <any>, dst <their port>, so they don't get additional
overhead of QM's & IPSec SA pairs per new connection. I see their
point. However, different source ports could imply different
applications or even identities connecting to the same service port at
the destination IP. In L2TP's case, a new UDP source port connecting to
the same destination port could mean a new L2TP tunnel (L2TP can do new
tunnel sessions across the same port pair with session IDs). The IKE
identity used is that of the machine, thus it could have requested src
<any>, dst 1701 in QM. We just had to decide, and chose the "safer"
full 5-tuple. L2TP itself identifies the user for each tunnel in it's
PPP negotiation completely independent of IPsec.
Anyway, decorrelation ordering based on most specific seems reasonable,
since IP will see a full 5-tuple outbound and inbound. Just hope the
other guy implements the same ordering, so the return traffic doesn't
use a different IPSec SA than the pair you initially established...
-----Original Message-----
From: Steve.Robinson@psti.com [mailto:Steve.Robinson@psti.com]
Sent: Thursday, October 18, 2001 5:25 AM
To: Puja Puri
Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com; ranjeet
barve
Subject: Re: DataStructure for Storing SPD,SA Entries
I use three tries in my implementation -- but it really isn't the
relevant issue here. It sounds to me like you are really glossing over
the issue of overlapping policy. If you do not implement a
decorrelation algorithm, you are probably going to cause yourself some
major problems down the road. Are you going to be hardcoding the policy
values in yourself, or are you going to be selling a product that will
have the policies loaded by a system administrator after the sale?
Assuming the latter case is correct, and you insist on using a hash
lookup, then you really should guarantee that your product will not
overlap the policies ever -- don't blame the system administrators for
not using the product correctly if the initial design is not robust and
able to separate the policies dynamically in the field.
Steve
"Puja Puri"
<puja.puri@cdac.ern To: "ranjeet barve"
<ranjeet_barve@yahoo.co.in>
et.in> cc:
<ipsec@lists.tislabs.com>
Sent by: Subject: Re:
DataStructure for Storing SPD,SA Entries
owner-ipsec@lists.t
islabs.com
10/18/01 01:13 AM
hi
Its true that finding an efficient hash function seems to be a major
problem but then once that is done, hash tables prove to be efficient.
Rajesh, I suggest u to do some r&d on hash function to find a suitable
one for you. For instance the hi/fn toolkit for IPSec uses hash tables.
But unfortunately such implementations don't mention about their hash
functions.
The selectors do contain a number of fields but remember that according
to RFC 2401 u can use one or more fields from selectors to map to ur
policies. This makes life simpler.
The queries with wildcards do create some problem but that can be sorted
out with the way u implement.
As far as tries are concerned, I have no idea whether any
implementations use it or not.
I hope Rajesh that atleast i have tried answering all your queries.
regds
puja
----- Original Message -----
From: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
To: "Puja Puri" <puja.puri@cdac.ernet.in>
Cc: <ipsec@lists.tislabs.com>
Sent: Thursday, October 18, 2001 9:51 AM
Subject: Re: DataStructure for Storing SPD,SA Entries
> hi,
> With Hash Table finding an efficient hash function
> seems to be a major Problem. Also as the Selector
> contains of a number of fields, it would make the task
> even complicated. Which Implementations are using Hash
> Tables for storing SPD and SAD? What kind of hash
> functions do they use??
>
> Also does the range queries with wild cards not create
> a major problem in formulating a Hash Function??
> Does any implementation use Tries for Storing SPD,SAD?
>
> Please help me with the above queries,
>
> Regards,
> Ranjeet Barve,
> M.Tech IIT Bombay.
>
>
>
> --- Puja Puri <puja.puri@cdac.ernet.in> wrote: > hi
> > Hash tables seem to be good for SPD n SAD, since
> > search is faster than many
> > other data structures. It is used by many toolkits
> > which implement IPSec.
> >
> > Just need to take care that policies don't overlap
> > Correct me anybody if I am wrong.
> > regds
> > puja
> > ----- Original Message -----
> > From: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
> > To: <ipsec@lists.tislabs.com>
> > Sent: Friday, October 12, 2001 8:10 PM
> > Subject: DataStructure for Storing SPD,SA Entries
> >
> >
> > > hi,
> > > I had a quesiton on the Data Structure to use for Security Policy
> > > Database and Security Association Entries.
> > > Which would be the most efficient Data Structure
> > for
> > > Storing SPD and SA entries ??
> > > Which Data-Structure is Most Commonly used?
> > > (I apologise if this question is already answered
> > in
> > > the mailing list.)
> > >
> > > Please let me know.
> > >
> > > Regards,
> > > Ranjeet Barve,
> > > M.Tech IIT Bombay.
> > >
> > >
> > >
> > >
> >
> ____________________________________________________________
> > > Do You Yahoo!?
> > > Send a newsletter, share photos & files, conduct
> > polls, organize chat
> > events. Visit http://in.groups.yahoo.com
> >
>
> ____________________________________________________________
> *NEW* Connect to Yahoo! Messenger through your mobile phone *NEW*
> Visit http://in.mobile.yahoo.com/smsmgr_signin.html
From owner-ipsec@lists.tislabs.com Fri Oct 19 06:19:09 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JDJ9D05123;
Fri, 19 Oct 2001 06:19:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12986
Fri, 19 Oct 2001 07:58:16 -0400 (EDT)
Message-ID: <3BD01732.850679BA@americasm01.nt.com>
Date: Fri, 19 Oct 2001 08:06:11 -0400
From: "Wei-Jen Yeh" <weijyeh@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.10.20 9000/785)
X-Accept-Language: en
MIME-Version: 1.0
To: William Dixon <wdixon@windows.microsoft.com>
CC: "Steve.Robinson" <Steve.Robinson@psti.com>,
Puja Puri <puja.puri@cdac.ernet.in>, ipsec <ipsec@lists.tislabs.com>,
ranjeet barve <ranjeet_barve@yahoo.co.in>
Subject: Re: DataStructure for Storing SPD,SA Entries
References: <2E33960095B58E40A4D3345AB9F65EC102EE6854@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I think removing the requirement on policy ordering works only if your
system supports one security modeul for all peers, e.g. the `friendly' model,
i.e., if it's not specified secured in the SPD bypass the traffic. It will
not work if you need to support both the friendly model and the opposite (discard
by default). The policies still need to be ordered, somewhere and somehow,
but may not be globally.
--Wei Jen Yeh
William Dixon wrote:
>
> Deconflicting overlapping policy (e.g. port ranges, subnets, all TCP to
> Any IP vs. All traffic to 1.1.1.1) was the main point why RFC 2401 says
> filters must be manually ordered.
>
> However, I'll posit that, when talking about IP packet filters that are
> matched only at the IP level (or below), manual ordering is enforceable
> only if your policy comes from one source. Clearly if policy comes from
> two sources, and if it overlaps, it would be impossible to guarantee the
> outcome of each original manual ordering. If your run-time effective
> policy comes from a static policy definition, then enhanced from a local
> command line, possibly enhanced by local service or application API
> calls to protect their traffic, and perhaps filters are generated by a
> default response policy (accept whatever is proposed by the initiator)
> when nothing else matches inbound IKE QM requests, then you must have an
> automatic, total ordering, decorrelation algorithm.
>
> With many new IETF protocols specifying their traffic to be protected by
> IPsec, and some like iFCP in the IP Storage group requiring tunneling
> mode instead of transport mode, enforcing strict admin manual ordering
> of filters in the static policy he applied last week does not appear to
> be feasible for an end-system.
>
> To the extent possible, I've encouraged other protocols to request IPSec
> transport mode 5-tuple specific IPsec SA pairs. This is how L2TP
> requests IKE quick mode to establish an SA pair for src me, dst gw, UDP,
> src <specific>, dst 1701.
>
> However, many people have argued that they want an IPSec SA established
> for TCP src <any>, dst <their port>, so they don't get additional
> overhead of QM's & IPSec SA pairs per new connection. I see their
> point. However, different source ports could imply different
> applications or even identities connecting to the same service port at
> the destination IP. In L2TP's case, a new UDP source port connecting to
> the same destination port could mean a new L2TP tunnel (L2TP can do new
> tunnel sessions across the same port pair with session IDs). The IKE
> identity used is that of the machine, thus it could have requested src
> <any>, dst 1701 in QM. We just had to decide, and chose the "safer"
> full 5-tuple. L2TP itself identifies the user for each tunnel in it's
> PPP negotiation completely independent of IPsec.
>
> Anyway, decorrelation ordering based on most specific seems reasonable,
> since IP will see a full 5-tuple outbound and inbound. Just hope the
> other guy implements the same ordering, so the return traffic doesn't
> use a different IPSec SA than the pair you initially established...
>
> -----Original Message-----
> From: Steve.Robinson@psti.com [mailto:Steve.Robinson@psti.com]
> Sent: Thursday, October 18, 2001 5:25 AM
> To: Puja Puri
> Cc: ipsec@lists.tislabs.com; owner-ipsec@lists.tislabs.com; ranjeet
> barve
> Subject: Re: DataStructure for Storing SPD,SA Entries
>
> I use three tries in my implementation -- but it really isn't the
> relevant issue here. It sounds to me like you are really glossing over
> the issue of overlapping policy. If you do not implement a
> decorrelation algorithm, you are probably going to cause yourself some
> major problems down the road. Are you going to be hardcoding the policy
> values in yourself, or are you going to be selling a product that will
> have the policies loaded by a system administrator after the sale?
> Assuming the latter case is correct, and you insist on using a hash
> lookup, then you really should guarantee that your product will not
> overlap the policies ever -- don't blame the system administrators for
> not using the product correctly if the initial design is not robust and
> able to separate the policies dynamically in the field.
>
> Steve
>
>
>
> "Puja Puri"
>
> <puja.puri@cdac.ern To: "ranjeet barve"
> <ranjeet_barve@yahoo.co.in>
> et.in> cc:
> <ipsec@lists.tislabs.com>
> Sent by: Subject: Re:
> DataStructure for Storing SPD,SA Entries
> owner-ipsec@lists.t
>
> islabs.com
>
>
>
>
>
> 10/18/01 01:13 AM
>
>
>
>
>
> hi
> Its true that finding an efficient hash function seems to be a major
> problem but then once that is done, hash tables prove to be efficient.
> Rajesh, I suggest u to do some r&d on hash function to find a suitable
> one for you. For instance the hi/fn toolkit for IPSec uses hash tables.
> But unfortunately such implementations don't mention about their hash
> functions.
>
> The selectors do contain a number of fields but remember that according
> to RFC 2401 u can use one or more fields from selectors to map to ur
> policies. This makes life simpler.
>
> The queries with wildcards do create some problem but that can be sorted
> out with the way u implement.
>
> As far as tries are concerned, I have no idea whether any
> implementations use it or not.
>
> I hope Rajesh that atleast i have tried answering all your queries.
>
> regds
> puja
> ----- Original Message -----
> From: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
> To: "Puja Puri" <puja.puri@cdac.ernet.in>
> Cc: <ipsec@lists.tislabs.com>
> Sent: Thursday, October 18, 2001 9:51 AM
> Subject: Re: DataStructure for Storing SPD,SA Entries
>
> > hi,
> > With Hash Table finding an efficient hash function
> > seems to be a major Problem. Also as the Selector
> > contains of a number of fields, it would make the task
> > even complicated. Which Implementations are using Hash
> > Tables for storing SPD and SAD? What kind of hash
> > functions do they use??
> >
> > Also does the range queries with wild cards not create
> > a major problem in formulating a Hash Function??
> > Does any implementation use Tries for Storing SPD,SAD?
> >
> > Please help me with the above queries,
> >
> > Regards,
> > Ranjeet Barve,
> > M.Tech IIT Bombay.
> >
> >
> >
> > --- Puja Puri <puja.puri@cdac.ernet.in> wrote: > hi
> > > Hash tables seem to be good for SPD n SAD, since
> > > search is faster than many
> > > other data structures. It is used by many toolkits
> > > which implement IPSec.
> > >
> > > Just need to take care that policies don't overlap
> > > Correct me anybody if I am wrong.
> > > regds
> > > puja
> > > ----- Original Message -----
> > > From: "ranjeet barve" <ranjeet_barve@yahoo.co.in>
> > > To: <ipsec@lists.tislabs.com>
> > > Sent: Friday, October 12, 2001 8:10 PM
> > > Subject: DataStructure for Storing SPD,SA Entries
> > >
> > >
> > > > hi,
> > > > I had a quesiton on the Data Structure to use for Security Policy
> > > > Database and Security Association Entries.
> > > > Which would be the most efficient Data Structure
> > > for
> > > > Storing SPD and SA entries ??
> > > > Which Data-Structure is Most Commonly used?
> > > > (I apologise if this question is already answered
> > > in
> > > > the mailing list.)
> > > >
> > > > Please let me know.
> > > >
> > > > Regards,
> > > > Ranjeet Barve,
> > > > M.Tech IIT Bombay.
> > > >
> > > >
> > > >
> > > >
> > >
> > ____________________________________________________________
> > > > Do You Yahoo!?
> > > > Send a newsletter, share photos & files, conduct
> > > polls, organize chat
> > > events. Visit http://in.groups.yahoo.com
> > >
> >
> > ____________________________________________________________
> > *NEW* Connect to Yahoo! Messenger through your mobile phone *NEW*
> > Visit http://in.mobile.yahoo.com/smsmgr_signin.html
--
Wei-Jen Yeh
weijyeh@nortelnetworks.com Nortel, RTP, NC
Office Phone: (919) 991-2707, ESN: 35-12707
Fax: (919) 991-8073
From owner-ipsec@lists.tislabs.com Fri Oct 19 07:15:50 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JEFnD08536;
Fri, 19 Oct 2001 07:15:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13208
Fri, 19 Oct 2001 09:26:46 -0400 (EDT)
Message-ID: <8894CA1F87A5D411BD24009027EE783812834E@ROC-76-204.nai.com>
From: "Mason, David" <David_Mason@nai.com>
To: "'Wei-Jen Yeh'" <weijyeh@nortelnetworks.com>,
William Dixon
<wdixon@windows.microsoft.com>
Cc: "Steve.Robinson" <Steve.Robinson@psti.com>,
Puja Puri
<puja.puri@cdac.ernet.in>, ipsec <ipsec@lists.tislabs.com>,
ranjeet barve <ranjeet_barve@yahoo.co.in>
Subject: RE: DataStructure for Storing SPD,SA Entries
Date: Fri, 19 Oct 2001 08:32:50 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
One of the reasons for having ordered SPDs is interoperability. If you have
overlapping SPDs and they are in different orders on both sides of the VPN
link, then you may run into connectivity problems. To correct a problem of
this sort, one of the sides will need to change the order of their SPDs.
-dave
From owner-ipsec@lists.tislabs.com Fri Oct 19 07:38:27 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JEcQD10441;
Fri, 19 Oct 2001 07:38:26 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13281
Fri, 19 Oct 2001 09:44:11 -0400 (EDT)
From: Steve.Robinson@psti.com
Subject: RE: DataStructure for Storing SPD,SA Entries
To: "Mason, David" <David_Mason@nai.com>
Cc: ipsec <ipsec@lists.tislabs.com>, Puja Puri <puja.puri@cdac.ernet.in>,
ranjeet barve <ranjeet_barve@yahoo.co.in>,
William Dixon <wdixon@windows.microsoft.com>,
"'Wei-Jen Yeh'" <weijyeh@nortelnetworks.com>
X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001
Message-ID: <OF20EF5556.3B27FFA0-ON80256AEA.004BC2A6@psti.com>
Date: Fri, 19 Oct 2001 09:58:00 -0400
X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.8 |June 18, 2001) at 10/19/2001
02:58:46 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
You know, I never considered the interoperability issue! I would love to
see a discussion on the issue of a decorrelated host interacting with a
host that uses an ordered SPD. I don't see a problem on the decorrelated
side, since you can guarantee that you are using the correct policy, but
how do you coordinate with 3rd party hosts and/or negotiate with them to
set up the policies on the fly? Everything seems OK to me (even
negotiating with the ordered host -- as you are negotiating algorithms and
selectors, not database structure)-- but I'll be up front in pointing out
that I haven't put a great deal of research into the subject yet. Any
pointers would be welcome.
Steve
"Mason, David"
<David_Mason@N To: "'Wei-Jen Yeh'" <weijyeh@nortelnetworks.com>, William Dixon
AI.com> <wdixon@windows.microsoft.com>
cc: "Steve.Robinson" <Steve.Robinson@psti.com>, Puja Puri
10/19/01 09:32 <puja.puri@cdac.ernet.in>, ipsec <ipsec@lists.tislabs.com>, ranjeet
AM barve <ranjeet_barve@yahoo.co.in>
Subject: RE: DataStructure for Storing SPD,SA Entries
One of the reasons for having ordered SPDs is interoperability. If you
have
overlapping SPDs and they are in different orders on both sides of the VPN
link, then you may run into connectivity problems. To correct a problem of
this sort, one of the sides will need to change the order of their SPDs.
-dave
From owner-ipsec@lists.tislabs.com Fri Oct 19 07:54:40 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JEseD12671;
Fri, 19 Oct 2001 07:54:40 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13328
Fri, 19 Oct 2001 10:03:39 -0400 (EDT)
To: sleepy-cat@263.net
Cc: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: Re: question about Nonce
References: <200110190120.JAA05933@csnet1>
From: Derek Atkins <warlord@mit.edu>
Date: 19 Oct 2001 10:12:03 -0400
In-Reply-To: dxh's message of "Fri, 19 Oct 2001 9:29:57 +0800"
Message-ID: <sjmbsj3yb0s.fsf@rcn.ihtfp.org>
Lines: 24
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The nonce provides a quick, non-cryptographic check to prevent not
only replay but also DoS attacks. The responder should not have to
perform any high-CPU operations (e.g. modexp) until the nonce (cookie)
reachability test has succeeded.
-derek
dxh <sleepy-cat@263.net> writes:
> I am not sure if the nonce in Phase One is the same as
> the one in Phase two. And I still can not see why there is
> need using nonce to prevent from replay attacking in Phase
> One. I think the Kes of DH exch can do this.
>
>
>
> Dong Xiaohu
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Fri Oct 19 09:42:09 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JGg8D24566;
Fri, 19 Oct 2001 09:42:08 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13532
Fri, 19 Oct 2001 11:20:30 -0400 (EDT)
From: "Joseph D. Harwood" <jharwood@vesta-corp.com>
To: <Steve.Robinson@psti.com>, "Mason, David" <David_Mason@nai.com>
Cc: "ipsec" <ipsec@lists.tislabs.com>, "Puja Puri" <puja.puri@cdac.ernet.in>,
"ranjeet barve" <ranjeet_barve@yahoo.co.in>,
"William Dixon" <wdixon@windows.microsoft.com>,
"'Wei-Jen Yeh'" <weijyeh@nortelnetworks.com>
Subject: RE: DataStructure for Storing SPD,SA Entries
Date: Fri, 19 Oct 2001 08:29:01 -0700
Message-ID: <007201c158b2$c74511a0$c7d0fea9@vesta>
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 V5.50.4133.2400
In-Reply-To: <OF20EF5556.3B27FFA0-ON80256AEA.004BC2A6@psti.com>
X-Loop-Detect: 1
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I don't see that interoperability is linked to decorrelation. The
decorreclation needs to be functionally equivalent to a search through the
ordered SPD. The interoperability problem mentioned below, where the two
sides have their policies in a different order, would result in an
interoperability problem regardless of how either side does the policy look
up.
Best Regards,
Joseph D. Harwood
(408) 838-9434
jharwood@vesta-corp.com
www.vesta-corp.com
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of
> Steve.Robinson@psti.com
> Sent: Friday, October 19, 2001 6:58 AM
> To: Mason, David
> Cc: ipsec; Puja Puri; ranjeet barve; William Dixon; 'Wei-Jen Yeh'
> Subject: RE: DataStructure for Storing SPD,SA Entries
>
>
>
> You know, I never considered the interoperability issue! I would love to
> see a discussion on the issue of a decorrelated host interacting with a
> host that uses an ordered SPD. I don't see a problem on the decorrelated
> side, since you can guarantee that you are using the correct policy, but
> how do you coordinate with 3rd party hosts and/or negotiate with them to
> set up the policies on the fly? Everything seems OK to me (even
> negotiating with the ordered host -- as you are negotiating algorithms and
> selectors, not database structure)-- but I'll be up front in pointing out
> that I haven't put a great deal of research into the subject yet. Any
> pointers would be welcome.
>
>
> Steve
>
>
>
>
>
>
> "Mason, David"
>
> <David_Mason@N To: "'Wei-Jen Yeh'"
> <weijyeh@nortelnetworks.com>, William Dixon
> AI.com>
> <wdixon@windows.microsoft.com>
> cc: "Steve.Robinson"
> <Steve.Robinson@psti.com>, Puja Puri
> 10/19/01 09:32
> <puja.puri@cdac.ernet.in>, ipsec <ipsec@lists.tislabs.com>, ranjeet
> AM barve
> <ranjeet_barve@yahoo.co.in>
> Subject: RE:
> DataStructure for Storing SPD,SA Entries
>
>
>
>
>
>
> One of the reasons for having ordered SPDs is interoperability. If you
> have
> overlapping SPDs and they are in different orders on both sides of the VPN
> link, then you may run into connectivity problems. To correct a
> problem of
> this sort, one of the sides will need to change the order of their SPDs.
>
> -dave
>
>
>
>
From owner-ipsec@lists.tislabs.com Fri Oct 19 11:46:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JIkPD02976;
Fri, 19 Oct 2001 11:46:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13978
Fri, 19 Oct 2001 13:39:32 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011019104307.02ebf7f0@mira-sjc5-4.cisco.com>
X-Sender: byfraser@mira-sjc5-4.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 19 Oct 2001 10:47:01 -0700
To: Tim Jenkins <TJenkins@Catena.com>
From: Barbara Fraser <byfraser@cisco.com>
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
Cc: "'rks@cisco.com'" <rks@cisco.com>, tytso@mit.edu, bbruins@cisco.com,
ipsec@lists.tislabs.com, leot@cisco.com
In-Reply-To: <522FDAAFD532D511A0AB0002A51390EB2F6FE0@cat01s2.catena.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
All,
We have 5 MIB documents that really need general attention from the working
group. Postings to the list seem to indicate there isn't much active
interest in these documents at the current time. So, Ted and I are issuing
a call for interest to see how many folks are planning to implement some or
all of these MIBs.
Thanks
Barb
At 06:25 AM 10/10/2001, Tim Jenkins wrote:
>All,
>
>I have two main objections to this MIB document. They are:
>1) It doesn't use the base IPsec MIBs.
>2) It does things that are outside the scope of IPsec.
>
>Below, there is agreement to using the base MIBs, so that
>deals with my first objection. As a guide, I have submitted
><draft-jenkins-ipsec-tun-mon-mib-00.txt> as an illustration
>of how this can be done.
>
>As far as I can see, the second objection has not been
>dealt with. While I believe that a number of these
>additional features are things that are user requested
>(such as IP address to domain name conversion; see objects
>ikeTunLocalName and ikeTunRemoteName as examples), it is my
>belief that they do not belong in an IPsec MIB. However,
>there are few of these, so it is likely this objection can
>be easily overcome.
>
>Tim
>
> > -----Original Message-----
> > From: rks@cisco.com [mailto:rks@cisco.com]
> > Sent: Tuesday, October 09, 2001 6:14 PM
> > To: byfraser@cisco.com; tytso@mit.edu
> > Cc: bbruins@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com
> > Subject: Status of ID: IPsec Flow Monitoring MIB
> >
> >
> >
> > We proposed the IPsec Flow Monitor MIB in 1999 to aid
> > IPsec monitoring applications designed to evaluate the
> > connectivity and performance and troubleshoot connectivity
> > failures. The MIB has evolved ever since based on comments
> > from early of VPN deployers. We would like to standardize
> > this MIB and want the WG chairs to advance the ID in the
> > standards track.
> >
> >
> > History:
> > The MIB was first defined because the MIBs available during
> > that time in the area were insufficient in providing the
> > abstractions that are desirable to make IPsec manageable.
> >
> > Tivoli Systems (a multi-vendor management company) refined
> > the MIB with Cisco Systems to make it a multi-vendor/standard
> > MIB for managing IPsec networks. After successful deployment in
> > the field, it was revised and the revision was submitted to
> > the WG early this year.
> >
> > The MIB has since been adopted by a few VPN service providers,
> > management vendors and users. Their comments were helpful in
> > further refining the MIB definition.
> >
> >
> > Highlights of the MIB:
> > Defining a MIB to merely export bits of the protocol serves no
> > management purpose. We defined the MIB with the following features:
> >
> > 1. Build abstractions that may be used by the network
> > administrators
> > to identify traffic flows in IPsec networks. This
> > would allow the
> > correlation of the performance of the application traffic with
> > that of the underlying IPsec networks.
> > 2. Help define SLAs to qualify the performance and failures.
> > 3. History and failure tables for trending and troubleshooting.
> > 4. SA tables to aid low level troubleshooting.
> > 5. Separation of IKE and IPsec groups to allow later
> > extensions for
> > other keying protocols to be used with IPsec (such as KINK).
> >
> > I'd very much like to hear comments on this from administrators
> > or NMS developers who are facing the problem of monitoring
> > and troubleshooting IPsec-based VPNs.
> >
> >
> > Coexistence with other MIB drafts:
> > Our proposal may be regarded as being competing or complementary to
> > the low level MIBs proposed by Jenkins et al. To that extent,
> > we are willing to layer our MIB on top of the basic definitions
> > provided by the Jenkins drafts.
> >
> > In 1999, it was proposed that we use the ISAKMP and IPsec textual
> > conventions proposed by Jenkins drafts. This is quite feasible
> > since there is little difference between the TCs proposed by
> > the two drafts.
> >
> >
> > Please advise us on what we need to do in order to advance this MIB
> > in the standards track.
> >
> > Thanks,
> >
> > Leo Temoshenko, Cisco Systems Inc.
> > Cheryl Madson, Cisco Systems Inc.
> > Chinna Pellacuru, Cisco Systems Inc.
> > Bret Harrison, Tivoli Systems Inc.
> > S Ramakrishnan, Cisco Systems Inc.
> >
From owner-ipsec@lists.tislabs.com Fri Oct 19 14:24:50 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JLOoD11068;
Fri, 19 Oct 2001 14:24:50 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14315
Fri, 19 Oct 2001 16:36:14 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010404b7f5e248e981@[128.33.84.34]>
In-Reply-To:
<2E33960095B58E40A4D3345AB9F65EC102EE6854@win-msg-01.wingroup.windeploy.nt
dev.microsoft.com>
References:
<2E33960095B58E40A4D3345AB9F65EC102EE6854@win-msg-01.wingroup.windeploy.nt
dev.microsoft.com>
Date: Fri, 19 Oct 2001 16:42:52 -0400
To: "William Dixon" <wdixon@windows.microsoft.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: DataStructure for Storing SPD,SA Entries
Cc: <Steve.Robinson@psti.com>, "Puja Puri" <puja.puri@cdac.ernet.in>,
<ipsec@lists.tislabs.com>, "ranjeet barve" <ranjeet_barve@yahoo.co.in>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 9:23 PM -0700 10/18/01, William Dixon wrote:
>Deconflicting overlapping policy (e.g. port ranges, subnets, all TCP to
>Any IP vs. All traffic to 1.1.1.1) was the main point why RFC 2401 says
>filters must be manually ordered.
As the author of the standard, I think I can provide a somewhat
better characterization of the rationale for ordering.
The 5 selectors used in the SPD correspond to what one finds in many
forms of network access control enforcement devices that operate at
the IP and transport layers. They define a lattice, not a total
order, and thus they must be ordered so that the effect of the
security policy they define, in aggregate, is deterministic. This too
is characteristic of all ACL-style enforcement mechanisms that deal
with entries which forma lattice. (Go back and look at the Multices
time sharing system and its ACLs in the early 70s, for example. This
is not new stuff.)
>However, I'll posit that, when talking about IP packet filters that are
>matched only at the IP level (or below), manual ordering is enforceable
>only if your policy comes from one source. Clearly if policy comes from
>two sources, and if it overlaps, it would be impossible to guarantee the
>outcome of each original manual ordering. If your run-time effective
>policy comes from a static policy definition, then enhanced from a local
>command line, possibly enhanced by local service or application API
>calls to protect their traffic, and perhaps filters are generated by a
>default response policy (accept whatever is proposed by the initiator)
>when nothing else matches inbound IKE QM requests, then you must have an
>automatic, total ordering, decorrelation algorithm.
>
>With many new IETF protocols specifying their traffic to be protected by
>IPsec, and some like iFCP in the IP Storage group requiring tunneling
>mode instead of transport mode, enforcing strict admin manual ordering
>of filters in the static policy he applied last week does not appear to
>be feasible for an end-system.
I disagree. There always has to be one, accountable entity
responsible for the SPD associated with any device. If there are to
be multiple sources of SPD entries, someone has to make sure that
they don't conflict, and this is more that just an ordering issue.
>To the extent possible, I've encouraged other protocols to request IPSec
>transport mode 5-tuple specific IPsec SA pairs. This is how L2TP
>requests IKE quick mode to establish an SA pair for src me, dst gw, UDP,
>src <specific>, dst 1701.
This seems like a discussion of how to use a TLI request for an SA,
which is distinct from the SPD requirement. Even as an individual
user, I would generally like to specify a policy for my traffic that
cannot be overridden by applications. This is the whole notion
behind personal firewalls.
> However, many people have argued that they want an IPSec SA established
>for TCP src <any>, dst <their port>, so they don't get additional
>overhead of QM's & IPSec SA pairs per new connection. I see their
>point. However, different source ports could imply different
>applications or even identities connecting to the same service port at
>the destination IP. In L2TP's case, a new UDP source port connecting to
>the same destination port could mean a new L2TP tunnel (L2TP can do new
>tunnel sessions across the same port pair with session IDs). The IKE
>identity used is that of the machine, thus it could have requested src
><any>, dst 1701 in QM. We just had to decide, and chose the "safer"
>full 5-tuple. L2TP itself identifies the user for each tunnel in it's
>PPP negotiation completely independent of IPsec.
>
>Anyway, decorrelation ordering based on most specific seems reasonable,
>since IP will see a full 5-tuple outbound and inbound. Just hope the
>other guy implements the same ordering, so the return traffic doesn't
>use a different IPSec SA than the pair you initially established...
Decorrelation does not depend on any sense of "most specific."
Decorrelated SPD entries do not overlap with one another, which is
why there is no requirement for ordered searching of a decorrelated
SPD.
Steve
From owner-ipsec@lists.tislabs.com Fri Oct 19 15:30:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9JMUhD12378;
Fri, 19 Oct 2001 15:30:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14364
Fri, 19 Oct 2001 17:40:55 -0400 (EDT)
Message-ID: <3BD09FDA.79BDA9D9@redcreek.com>
Date: Fri, 19 Oct 2001 14:49:14 -0700
From: "Scott G. Kelly" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Barbara Fraser <byfraser@cisco.com>
CC: Tim Jenkins <TJenkins@Catena.com>, "'rks@cisco.com'" <rks@cisco.com>,
tytso@mit.edu, bbruins@cisco.com, ipsec@lists.tislabs.com, leot@cisco.com
Subject: Re: Status of ID: IPsec Flow Monitoring MIB
References: <4.3.2.7.2.20011019104307.02ebf7f0@mira-sjc5-4.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
RedCreek has implemented the ipsec monitoring mib, and intends to
implement the IKE monitoring mibs. Once we reach agreement on a tunnel
mib, we may implement that as well.
Scott
Barbara Fraser wrote:
>
> All,
>
> We have 5 MIB documents that really need general attention from the working
> group. Postings to the list seem to indicate there isn't much active
> interest in these documents at the current time. So, Ted and I are issuing
> a call for interest to see how many folks are planning to implement some or
> all of these MIBs.
>
> Thanks
> Barb
>
> At 06:25 AM 10/10/2001, Tim Jenkins wrote:
> >All,
> >
> >I have two main objections to this MIB document. They are:
> >1) It doesn't use the base IPsec MIBs.
> >2) It does things that are outside the scope of IPsec.
> >
> >Below, there is agreement to using the base MIBs, so that
> >deals with my first objection. As a guide, I have submitted
> ><draft-jenkins-ipsec-tun-mon-mib-00.txt> as an illustration
> >of how this can be done.
> >
> >As far as I can see, the second objection has not been
> >dealt with. While I believe that a number of these
> >additional features are things that are user requested
> >(such as IP address to domain name conversion; see objects
> >ikeTunLocalName and ikeTunRemoteName as examples), it is my
> >belief that they do not belong in an IPsec MIB. However,
> >there are few of these, so it is likely this objection can
> >be easily overcome.
> >
> >Tim
> >
> > > -----Original Message-----
> > > From: rks@cisco.com [mailto:rks@cisco.com]
> > > Sent: Tuesday, October 09, 2001 6:14 PM
> > > To: byfraser@cisco.com; tytso@mit.edu
> > > Cc: bbruins@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com
> > > Subject: Status of ID: IPsec Flow Monitoring MIB
> > >
> > >
> > >
> > > We proposed the IPsec Flow Monitor MIB in 1999 to aid
> > > IPsec monitoring applications designed to evaluate the
> > > connectivity and performance and troubleshoot connectivity
> > > failures. The MIB has evolved ever since based on comments
> > > from early of VPN deployers. We would like to standardize
> > > this MIB and want the WG chairs to advance the ID in the
> > > standards track.
> > >
> > >
> > > History:
> > > The MIB was first defined because the MIBs available during
> > > that time in the area were insufficient in providing the
> > > abstractions that are desirable to make IPsec manageable.
> > >
> > > Tivoli Systems (a multi-vendor management company) refined
> > > the MIB with Cisco Systems to make it a multi-vendor/standard
> > > MIB for managing IPsec networks. After successful deployment in
> > > the field, it was revised and the revision was submitted to
> > > the WG early this year.
> > >
> > > The MIB has since been adopted by a few VPN service providers,
> > > management vendors and users. Their comments were helpful in
> > > further refining the MIB definition.
> > >
> > >
> > > Highlights of the MIB:
> > > Defining a MIB to merely export bits of the protocol serves no
> > > management purpose. We defined the MIB with the following features:
> > >
> > > 1. Build abstractions that may be used by the network
> > > administrators
> > > to identify traffic flows in IPsec networks. This
> > > would allow the
> > > correlation of the performance of the application traffic with
> > > that of the underlying IPsec networks.
> > > 2. Help define SLAs to qualify the performance and failures.
> > > 3. History and failure tables for trending and troubleshooting.
> > > 4. SA tables to aid low level troubleshooting.
> > > 5. Separation of IKE and IPsec groups to allow later
> > > extensions for
> > > other keying protocols to be used with IPsec (such as KINK).
> > >
> > > I'd very much like to hear comments on this from administrators
> > > or NMS developers who are facing the problem of monitoring
> > > and troubleshooting IPsec-based VPNs.
> > >
> > >
> > > Coexistence with other MIB drafts:
> > > Our proposal may be regarded as being competing or complementary to
> > > the low level MIBs proposed by Jenkins et al. To that extent,
> > > we are willing to layer our MIB on top of the basic definitions
> > > provided by the Jenkins drafts.
> > >
> > > In 1999, it was proposed that we use the ISAKMP and IPsec textual
> > > conventions proposed by Jenkins drafts. This is quite feasible
> > > since there is little difference between the TCs proposed by
> > > the two drafts.
> > >
> > >
> > > Please advise us on what we need to do in order to advance this MIB
> > > in the standards track.
> > >
> > > Thanks,
> > >
> > > Leo Temoshenko, Cisco Systems Inc.
> > > Cheryl Madson, Cisco Systems Inc.
> > > Chinna Pellacuru, Cisco Systems Inc.
> > > Bret Harrison, Tivoli Systems Inc.
> > > S Ramakrishnan, Cisco Systems Inc.
> > >
From owner-ipsec@lists.tislabs.com Sat Oct 20 08:39:50 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9KFdnD16652;
Sat, 20 Oct 2001 08:39:49 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15445
Sat, 20 Oct 2001 10:25:38 -0400 (EDT)
Date: Sat, 20 Oct 2001 16:32:40 +0200
From: Marco Ender <marco.ender@dungeonmaster.at>
X-Mailer: The Bat! (v1.53bis) Educational
Reply-To: Marco Ender <marco.ender@dungeonmaster.at>
X-Priority: 3 (Normal)
Message-ID: <134142411083.20011020163240@dungeonmaster.at>
To: ipsec@lists.tislabs.com
Subject: IKE encryption in aggressive mode
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I have a small question regarding the point at which the encryption
using SKEYID_e starts in aggressive mode. In Main Mode, all parts of
the pakets 4 & 5 are encrypted using the SKEYID_e. Which parts of the
_second_ paket in Aggressive Mode are encrpted using SKEYID_e with
each authentication method? Am i correct that again the complete third
paket is encrypted using SKEYID_e?
tia
Marco
From owner-ipsec@lists.tislabs.com Sun Oct 21 02:31:04 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9L9V3805150;
Sun, 21 Oct 2001 02:31:03 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA16780
Sun, 21 Oct 2001 04:36:34 -0400 (EDT)
Message-Id: <200110210836.QAA09615@csnet1>
Date: Sun, 21 Oct 2001 16:45:29 +0800
From: dxh <sleepy-cat@263.net>
Reply-To: sleepy-cat@263.net
To: Derek Atkins <warlord@mit.edu>,
"ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: Re: Re: question about Nonce
X-mailer: FoxMail 3.11 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id EAA16777
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
you still did not tell if the nonce in phase one and the one in phase two is
the same. And I think the cookie is not the nonce. It's cookie's reachability, not
nonce's, that is tested.
I am a newbie in security area. Maybe I miss your point. Would you give more
detail?
you writes:
>The nonce provides a quick, non-cryptographic check to prevent not
>only replay but also DoS attacks. The responder should not have to
>perform any high-CPU operations (e.g. modexp) until the nonce (cookie)
>reachability test has succeeded.
>
>-derek
>
>dxh <sleepy-cat@263.net> writes:
>
>> I am not sure if the nonce in Phase One is the same as
>> the one in Phase two. And I still can not see why there is
>> need using nonce to prevent from replay attacking in Phase
>> One. I think the Kes of DH exch can do this.
>>
>>
>>
>> Dong Xiaohu
>>
>
>--
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
ÖÂ
Àñ£¡
dxh
sleepy-cat@263.net
From owner-ipsec@lists.tislabs.com Sun Oct 21 02:31:05 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9L9V5805159;
Sun, 21 Oct 2001 02:31:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA16810
Sun, 21 Oct 2001 04:38:54 -0400 (EDT)
Message-Id: <200110210839.QAA09619@csnet1>
Date: Sun, 21 Oct 2001 16:48:19 +0800
From: dxh <sleepy-cat@263.net>
Reply-To: sleepy-cat@263.net
To: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: what 's the use of ID payloads in Main mode of preshared key?
X-mailer: FoxMail 3.11 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Are they used to authenticate? I see no need.
dxh
From owner-ipsec@lists.tislabs.com Sun Oct 21 06:34:05 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9LDY4819706;
Sun, 21 Oct 2001 06:34:05 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17035
Sun, 21 Oct 2001 08:41:14 -0400 (EDT)
To: sleepy-cat@263.net
Cc: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: Re: Re: question about Nonce
References: <200110210836.QAA09615@csnet1>
From: Derek Atkins <warlord@mit.edu>
Date: 21 Oct 2001 08:49:45 -0400
In-Reply-To: dxh's message of "Sun, 21 Oct 2001 16:45:29 +0800"
Message-ID: <sjmpu7hi2dy.fsf@rcn.ihtfp.org>
Lines: 61
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Sorry, you are correct. The cookie is reachability. The nonces
are used to derive the session key. The nonces should be used
ONLY ONCE. This means that each phase-i and each phase-ii nonce
should be generated independently.
-derek
dxh <sleepy-cat@263.net> writes:
> =09you still did not tell if the nonce in phase one and the one in=
> phase two is
> the same. And I think the cookie is not the nonce. It's cookie's=
> reachability, not
> nonce's, that is tested.
> =09I am a newbie in security area. Maybe I miss your point. Would=
> you give more
> detail?
>
>
>
> you writes:
> >The nonce provides a quick, non-cryptographic check to prevent=
> not
> >only replay but also DoS attacks. The responder should not have=
> to
> >perform any high-CPU operations (e.g. modexp) until the nonce=
> (cookie)
> >reachability test has succeeded.
> >
> >-derek
> >
> >dxh <sleepy-cat@263.net> writes:
> >
> >> =09I am not sure if the nonce in Phase One is the same as
> >> the one in Phase two. And I still can not see why there is
> >> need using nonce to prevent from replay attacking in Phase
> >> One. I think the Kes of DH exch can do this.
> >>
> >>
> >>
> >> Dong Xiaohu
> >>
> >
> >--
> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > Member, MIT Student Information Processing Board (SIPB)
> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> > warlord@MIT.EDU PGP key available
>
> =D6=C2
> =C0=F1=A3=A1
>
> dxh
> sleepy-cat@263.net
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Sun Oct 21 06:34:19 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9LDYI819754;
Sun, 21 Oct 2001 06:34:19 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17047
Sun, 21 Oct 2001 08:45:40 -0400 (EDT)
To: sleepy-cat@263.net
Cc: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: Re: what 's the use of ID payloads in Main mode of preshared key?
References: <200110210839.QAA09619@csnet1>
From: Derek Atkins <warlord@mit.edu>
Date: 21 Oct 2001 08:54:15 -0400
In-Reply-To: dxh's message of "Sun, 21 Oct 2001 16:48:19 +0800"
Message-ID: <sjmofn1i26g.fsf@rcn.ihtfp.org>
Lines: 16
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
dxh <sleepy-cat@263.net> writes:
> Are they used to authenticate? I see no need.
Yes, they are used for authentication. How else are the endpoints
supposed to indentify each other? Just using the IP address is
insufficient, because you may have a host that has a dynamic address
(e.g. a road warrior connection).
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Sun Oct 21 14:39:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9LLdK809981;
Sun, 21 Oct 2001 14:39:20 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17618
Sun, 21 Oct 2001 16:48:31 -0400 (EDT)
To: <andrew.krywaniuk@alcatel.com>
Cc: <sleepy-cat@263.net>, <ipsec@lists.tislabs.com>
Subject: Re: what 's the use of ID payloads in Main mode of preshared key?
References: <002901c15a70$875ab3f0$1e72788a@andrewk3.ca.newbridge.com>
From: Derek Atkins <warlord@mit.edu>
Date: 21 Oct 2001 16:57:09 -0400
In-Reply-To: "Andrew Krywaniuk"'s message of "Sun, 21 Oct 2001 16:39:47 -0400"
Message-ID: <sjmhessiue2.fsf@rcn.ihtfp.org>
Lines: 52
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Oops, you are correct. Serves me right for ignoring
the subject when responding :)
-derek
"Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com> writes:
> Actually, the poster asked specifically about main mode with preshared keys.
> The identities are indeed redundant in this case.
>
> Andrew
> -------------------------------------------
> Upon closer inspection, I saw that the line
> dividing black from white was in fact a shade
> of grey. As I drew nearer still, the grey area
> grew larger. And then I was enlightened.
>
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins
> > Sent: Sunday, October 21, 2001 8:54 AM
> > To: sleepy-cat@263.net
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: what 's the use of ID payloads in Main mode of preshared
> > key?
> >
> >
> > dxh <sleepy-cat@263.net> writes:
> >
> > > Are they used to authenticate? I see no need.
> >
> > Yes, they are used for authentication. How else are the endpoints
> > supposed to indentify each other? Just using the IP address is
> > insufficient, because you may have a host that has a dynamic address
> > (e.g. a road warrior connection).
> >
> > -derek
> >
> > --
> > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > Member, MIT Student Information Processing Board (SIPB)
> > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> > warlord@MIT.EDU PGP key available
> >
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Sun Oct 21 14:39:23 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9LLdM809994;
Sun, 21 Oct 2001 14:39:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17578
Sun, 21 Oct 2001 16:32:59 -0400 (EDT)
Reply-To: <andrew.krywaniuk@alcatel.com>
From: "Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>
To: "'Derek Atkins'" <warlord@mit.edu>, <sleepy-cat@263.net>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: what 's the use of ID payloads in Main mode of preshared key?
Date: Sun, 21 Oct 2001 16:39:47 -0400
Message-Id: <002901c15a70$875ab3f0$1e72788a@andrewk3.ca.newbridge.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <sjmofn1i26g.fsf@rcn.ihtfp.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Actually, the poster asked specifically about main mode with preshared keys.
The identities are indeed redundant in this case.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins
> Sent: Sunday, October 21, 2001 8:54 AM
> To: sleepy-cat@263.net
> Cc: ipsec@lists.tislabs.com
> Subject: Re: what 's the use of ID payloads in Main mode of preshared
> key?
>
>
> dxh <sleepy-cat@263.net> writes:
>
> > Are they used to authenticate? I see no need.
>
> Yes, they are used for authentication. How else are the endpoints
> supposed to indentify each other? Just using the IP address is
> insufficient, because you may have a host that has a dynamic address
> (e.g. a road warrior connection).
>
> -derek
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
>
From owner-ipsec@lists.tislabs.com Sun Oct 21 19:43:24 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9M2hN815161;
Sun, 21 Oct 2001 19:43:23 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18035
Sun, 21 Oct 2001 22:02:53 -0400 (EDT)
To: sleepy-cat@263.net
Cc: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: Re: preshared key in ipv6
References: <200110220138.JAA10352@csnet1>
From: Derek Atkins <warlord@mit.edu>
Date: 21 Oct 2001 22:11:32 -0400
In-Reply-To: dxh's message of "Mon, 22 Oct 2001 9:47:22 +0800"
Message-ID: <sjmbsj0ifu3.fsf@rcn.ihtfp.org>
Lines: 17
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
There is no guarantee that the low 64 bits will be unique.
-derek
dxh <sleepy-cat@263.net> writes:
> when ike is used in IPv6, can we just use the low 64 bits ip addr to determine the preshared key? Then the main mode of preshared key can be used in mobile scenario of ipv6 without problems.
>
>
> dxh
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Sun Oct 21 19:43:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9M2hP815172;
Sun, 21 Oct 2001 19:43:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA17991
Sun, 21 Oct 2001 21:38:20 -0400 (EDT)
Message-Id: <200110220138.JAA10352@csnet1>
Date: Mon, 22 Oct 2001 9:47:22 +0800
From: dxh <sleepy-cat@263.net>
Reply-To: sleepy-cat@263.net
To: "ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: preshared key in ipv6
X-mailer: FoxMail 3.11 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
when ike is used in IPv6, can we just use the low 64 bits ip addr to determine the preshared key? Then the main mode of preshared key can be used in mobile scenario of ipv6 without problems.
dxh
From owner-ipsec@lists.tislabs.com Sun Oct 21 20:10:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9M3AC815574;
Sun, 21 Oct 2001 20:10:12 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA18089
Sun, 21 Oct 2001 22:24:57 -0400 (EDT)
Date: Mon, 22 Oct 2001 10:33:34 +0800 (HKT)
From: Derek Ho <csderek@cs.ust.hk>
To: <ipsec@lists.tislabs.com>
Subject: Minimum implementation requirement of IPsec
Message-ID: <Pine.SOL.4.32.0110221020150.9596-100000@cssu5.cs.ust.hk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Dear all,
IPsec contains several protocol, such as ESP, AH, IKE. I would like to ask
if I want to implement my own IPsec, which part I should do and which is
not if I want to connect my client to an IPsec server?
Now, I am concentrating on ESP tunnel mode instead of AH because ESP
provides both authentication and encryption. I have read the RFC and it
said that HMAC-MD5, HMAC-SHA1 is the requirement for message
authentication which DES-CBC is the requirement for message encryption.
For my implementation, I have prepared 3DES-EDE too because DES is now
known as not too secure.
For the IKE, I would like to ask should I implement it for the key change?
Can I use the pre-shared key model in IKE for my implemenation?
I apologise if my question is already answered here. I'm new to IPsec and
any comments is welcome!
Best Regards,
Derek
From owner-ipsec@lists.tislabs.com Mon Oct 22 01:09:36 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9M89Z811759;
Mon, 22 Oct 2001 01:09:35 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18537
Mon, 22 Oct 2001 03:06:34 -0400 (EDT)
Message-Id: <200110220706.PAA11174@csnet1>
Date: Mon, 22 Oct 2001 15:15:41 +0800
From: dxh <sleepy-cat@263.net>
Reply-To: sleepy-cat@263.net
To: Derek Atkins <warlord@mit.edu>,
"ipsec@lists.tislabs.com" <ipsec@lists.tislabs.com>
Subject: Re: preshared key in ipv6
X-mailer: FoxMail 3.11 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I know. But in some environments, the low 64 bits can be unique. For example, if a wireless ICP can guarantee this, he can use this trick for his customers.
you writes:
>There is no guarantee that the low 64 bits will be unique.
>
>-derek
>
dxh
From owner-ipsec@lists.tislabs.com Mon Oct 22 02:57:59 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9M9vw826405;
Mon, 22 Oct 2001 02:57:58 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA18968
Mon, 22 Oct 2001 05:04:16 -0400 (EDT)
Message-ID: <8894CA1F87A5D411BD24009027EE783812835A@ROC-76-204.nai.com>
From: "Mason, David" <David_Mason@nai.com>
To: "'Marco Ender'" <marco.ender@dungeonmaster.at>, ipsec@lists.tislabs.com
Subject: RE: IKE encryption in aggressive mode
Date: Mon, 22 Oct 2001 04:10:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
RFC 2409: The final message MAY NOT be sent under protection of the ISAKMP
SA allowing each party to postpone exponentiation, ... The graphic
depictions of Aggressive Mode show the final payload in the clear; it need
not be.
So the third message may or MAY NOT be encrypted. The preferred method is
not to encrypt since it provides not benefit except perhaps for Signatures
where the certificate identity of the Initiator is protected (but if that
property is desired then Main Mode w/ Identity protection is available).
-dave
-----Original Message-----
From: Marco Ender [mailto:marco.ender@dungeonmaster.at]
Sent: Saturday, October 20, 2001 10:33 AM
To: ipsec@lists.tislabs.com
Subject: IKE encryption in aggressive mode
I have a small question regarding the point at which the encryption
using SKEYID_e starts in aggressive mode. In Main Mode, all parts of
the pakets 4 & 5 are encrypted using the SKEYID_e. Which parts of the
_second_ paket in Aggressive Mode are encrpted using SKEYID_e with
each authentication method? Am i correct that again the complete third
paket is encrypted using SKEYID_e?
tia
Marco
From owner-ipsec@lists.tislabs.com Mon Oct 22 02:58:53 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9M9wr826549;
Mon, 22 Oct 2001 02:58:53 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA18980
Mon, 22 Oct 2001 05:09:54 -0400 (EDT)
Message-ID: <8894CA1F87A5D411BD24009027EE783812835B@ROC-76-204.nai.com>
From: "Mason, David" <David_Mason@nai.com>
To: "'andrew.krywaniuk@alcatel.com'" <andrew.krywaniuk@alcatel.com>,
"'Derek Atkins'" <warlord@mit.edu>, sleepy-cat@263.net
Cc: ipsec@lists.tislabs.com
Subject: RE: what 's the use of ID payloads in Main mode of preshared key?
Date: Mon, 22 Oct 2001 04:15:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
For an explanation of why: In Main Mode, the pre-shared key must be used
before you have even received the peer's ID payload. In Aggressive mode
they are not necessarily redundant.
-dave
-----Original Message-----
From: Andrew Krywaniuk [mailto:andrew.krywaniuk@alcatel.com]
Sent: Sunday, October 21, 2001 4:40 PM
To: 'Derek Atkins'; sleepy-cat@263.net
Cc: ipsec@lists.tislabs.com
Subject: RE: what 's the use of ID payloads in Main mode of preshared
key?
Actually, the poster asked specifically about main mode with preshared keys.
The identities are indeed redundant in this case.
Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins
> Sent: Sunday, October 21, 2001 8:54 AM
> To: sleepy-cat@263.net
> Cc: ipsec@lists.tislabs.com
> Subject: Re: what 's the use of ID payloads in Main mode of preshared
> key?
>
>
> dxh <sleepy-cat@263.net> writes:
>
> > Are they used to authenticate? I see no need.
>
> Yes, they are used for authentication. How else are the endpoints
> supposed to indentify each other? Just using the IP address is
> insufficient, because you may have a host that has a dynamic address
> (e.g. a road warrior connection).
>
> -derek
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
>
From owner-ipsec@lists.tislabs.com Mon Oct 22 12:04:17 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9MJ4G801433;
Mon, 22 Oct 2001 12:04:17 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20193
Mon, 22 Oct 2001 14:07:36 -0400 (EDT)
X-Mailer: exmh version 2.1.1 10/15/1999
From: "Steven M. Bellovin" <smb@research.att.com>
To: Paul Koning <ni1d@arrl.net>
Cc: sleepy-cat@263.net, ipsec@lists.tislabs.com
Subject: Re: preshared key in ipv6
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 Oct 2001 14:16:13 -0400
Message-Id: <20011022181614.0BA597B55@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <15316.23604.897000.316048@gargle.gargle.HOWL>, Paul Koning writes:
>Excerpt of message (sent 22 October 2001) by dxh:
>> I know. But in some environments, the low 64 bits can be
>> unique. For example, if a wireless ICP can guarantee this, he can
>> use this trick for his customers.
>
>Bad design decision.
>
>Looking up a full V6 address is no harder than looking up a 64 bit
>piece. That way you don't have to rely on unreliable assumptions.
>You don't implement a proprietary system that doesn't work when people
>outside the closed group want to communicate. And so on.
>
>If full V6 address handling were difficult, then perhaps this sort of
>shortcut would be justified. But there is no benefit, only problems,
>so why do it?
One problem is renumbering: if your upstream ISP renumbers, you need
to change your lookup tables (or, in some cases, your certificates).
The right answer is to do things based on domain name, not IP
addresses, but that means that we *really* need DNSSEC.
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Mon Oct 22 12:04:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9MJ4J801447;
Mon, 22 Oct 2001 12:04:19 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20136
Mon, 22 Oct 2001 13:40:50 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15316.23604.897000.316048@gargle.gargle.HOWL>
Date: Mon, 22 Oct 2001 13:49:40 -0400
From: Paul Koning <ni1d@arrl.net>
To: sleepy-cat@263.net
Cc: ipsec@lists.tislabs.com
Subject: Re: preshared key in ipv6
References: <200110220706.PAA11174@csnet1>
X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Excerpt of message (sent 22 October 2001) by dxh:
> I know. But in some environments, the low 64 bits can be
> unique. For example, if a wireless ICP can guarantee this, he can
> use this trick for his customers.
Bad design decision.
Looking up a full V6 address is no harder than looking up a 64 bit
piece. That way you don't have to rely on unreliable assumptions.
You don't implement a proprietary system that doesn't work when people
outside the closed group want to communicate. And so on.
If full V6 address handling were difficult, then perhaps this sort of
shortcut would be justified. But there is no benefit, only problems,
so why do it?
paul
From owner-ipsec@lists.tislabs.com Tue Oct 23 05:14:41 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9NCEf826569;
Tue, 23 Oct 2001 05:14:41 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA21843
Tue, 23 Oct 2001 06:53:49 -0400 (EDT)
Message-Id: <200110231102.HAA25461@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-sctp-02.txt
Date: Tue, 23 Oct 2001 07:02:31 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : On the Use of SCTP with IPsec
Author(s) : S. Bellovin et al.
Filename : draft-ietf-ipsec-sctp-02.txt
Pages :
Date : 22-Oct-01
This document describes functional requirements for IPsec [RFC2401]
and IKE [RFC2409] to facilitate their use for securing SCTP
[RFC2960] traffic.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-sctp-02.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-sctp-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-sctp-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20011022135509.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-sctp-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-sctp-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20011022135509.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Tue Oct 23 09:57:00 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9NGux818177;
Tue, 23 Oct 2001 09:56:59 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22387
Tue, 23 Oct 2001 11:32:23 -0400 (EDT)
To: "Steven M. Bellovin" <smb@research.att.com>
Cc: Paul Koning <ni1d@arrl.net>, sleepy-cat@263.net, ipsec@lists.tislabs.com
Subject: Re: preshared key in ipv6
References: <20011022181614.0BA597B55@berkshire.research.att.com>
From: Derek Atkins <warlord@mit.edu>
Date: 23 Oct 2001 11:41:03 -0400
In-Reply-To: "Steven M. Bellovin"'s message of "Mon, 22 Oct 2001 14:16:13 -0400"
Message-ID: <sjmzo6ifjow.fsf@rcn.ihtfp.org>
Lines: 23
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
"Steven M. Bellovin" <smb@research.att.com> writes:
> The right answer is to do things based on domain name, not IP
> addresses, but that means that we *really* need DNSSEC.
Why? You can just as easily use pre-shared RSA keys as you can use
preshared DES keys. Using pre-shared RSA keys allows you to use
domain names instead of IP addresses. So you can disassociate
yourself from your IP address with practically zero added effort.
DNSSec only comes into play for optimistic encryption, where you want
to use IPsec with arbitrary correspondants across the net.
> --Steve Bellovin, http://www.research.att.com/~smb
> Full text of "Firewalls" book now at http://www.wilyhacker.com
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available
From owner-ipsec@lists.tislabs.com Wed Oct 24 05:07:22 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9OC7M807280;
Wed, 24 Oct 2001 05:07:22 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA24074
Wed, 24 Oct 2001 07:01:01 -0400 (EDT)
Message-Id: <200110241109.HAA20703@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec@lists.tislabs.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-nat-t-ike-01.txt
Date: Wed, 24 Oct 2001 07:09:44 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.
Title : Negotiation of NAT-Traversal in the IKE
Author(s) : T. Kivinen et al.
Filename : draft-ietf-ipsec-nat-t-ike-01.txt
Pages : 9
Date : 23-Oct-01
This document describes how to detect one or more NATs between IPsec
hosts, and how to negotiate the use of UDP encapsulation of the IPsec
packets through the NAT boxes in IKE.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-01.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-nat-t-ike-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20011023111425.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-nat-t-ike-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-nat-t-ike-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20011023111425.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ipsec@lists.tislabs.com Wed Oct 24 13:47:09 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9OKl9814420;
Wed, 24 Oct 2001 13:47:09 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25053
Wed, 24 Oct 2001 15:27:52 -0400 (EDT)
From: "Renee L. Danson" <Renee.Danson@Eng.Sun.COM>
Message-Id: <200110241914.f9OJEJP4217992@jurassic.eng.sun.com>
Subject: Connectathon 2002 announcement
To: ipsec@lists.tislabs.com
Date: Wed, 24 Oct 2001 12:14:19 -0700 (PDT)
CC: audrey@vanb.com
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Connectathon 2002 is coming up, and we're inviting folks to participate
in IKE/IPsec interoperability again. I've attached a general announcement
from Connectathon organizer Audrey Van Bellingham (audrey@vanb.com) below.
We'd like to have one or more CAs for the testing; if you're interested
in providing one, please let me and Audrey know.
Renee Danson
Solaris Internet Engineering
+++++
The Connectathon team is delighted to announce its 16th annual event
will take place as scheduled. Connectathon 2002, an interoperability
testing event for engineers only, will be held Feb. 28-Mar. 7, 2002 in
San Jose, California. Sponsored by Sun Microsystems, Inc., Connectathon
hosts over 50 companies from around the globe in an effort to test and
debug source code. Currently, the following technologies and protocols
are on the agenda:
NFS versions 2, 3 and 4
NFS over RDMA
WebNFS
Lock Manager
NIS/NIS+
Automounter
Kerberos
IPv6
IPsec
Mobile IPv4
Mobile IPv6
Secure Shell
NDMP
Based on demand, in addition we are considering to offer:
Service Location Protocol
Diameter/AAA
CIFS
ATM
If you are interested in testing any of the above 4 protocols, please
send a note to Cthon@Sun.com and we'll gauge interest. Or if you have a
suggestion for another technology, feel free to contact us as well.
Testing continues 24 hours per day. Technology testing coordinators
will organize testing procedures and test suite material. In addition,
there will be seminars with speakers addressing various topics.
The registration deadline is February 7, 2002. An Early Bird Discount
on station fees is available to those who register and pay by December
31, 2001. For registration information, please see our web site at
http://www.connectathon.org.
If you have any questions, please feel free to contact Audrey Van
Belleghem at audrey@vanb.com or (408) 358-9598.
We look forward to seeing you at the 16th annual Connectathon event!
Audrey Van Belleghem
Connectathon Manager
----- End of forwarded message from Renee L. Danson -----
From owner-ipsec@lists.tislabs.com Thu Oct 25 19:05:12 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9Q25C809487;
Thu, 25 Oct 2001 19:05:12 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA27483
Thu, 25 Oct 2001 20:46:56 -0400 (EDT)
Message-Id: <200110252243.f9PMhDp00539@marajade.sandelman.ottawa.on.ca>
To: Jun-ichiro itojun Hagino <itojun@iijlab.net>
cc: ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-reply-to: Your message of "Wed, 15 Aug 2001 01:41:22 +0900."
<20010814164122.68A287BA@starfruit.itojun.org>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 25 Oct 2001 18:43:12 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Jun-ichiro" == Jun-ichiro itojun Hagino <itojun@iijlab.net> writes:
mcr> If the packet has some form of authentication (I'll not prejudge by saying
mcr> AH), and this is noted in the control structure, then the piece that
mcr> processes the Binding Update says "okay, it was protected".
mcr> The TCP layer (or whatever) above it didn't require that the packet was
mcr> protected (or not), so it goes on. If the system policy required all packets
mcr> to be authenticated, then TCP would check that.
mcr>
mcr> Dan McDonald? Bill Sommerfeld? Itojun?
mcr> Does this make sense?
Jun-ichiro> (not about the ipsec issue... anyway...)
Jun-ichiro> The above is basically what we (itojun + Dave Johnson) thought
Jun-ichiro> around 09 -> 10 mobile-ip6 spec (when we put more details on
Jun-ichiro> IPsec manipulation). there were issues raised at IETF50 about policy
Jun-ichiro> lookup in such cases. a point was made that there are implementations
Jun-ichiro> that are not flexible enough to permit such a tweak.
Host implementations? Or bump in the stack implementations?
I really think that this is something which requires integration to get right.
Jun-ichiro> now I believe that we should avoid piggybacking the binding
Jun-ichiro> updates onto normal packets. if we treat them separately, we can
Jun-ichiro> decide IPsec policy completely in a independent manner.
I feel uncomfortable about this.
I'm not sure why yet.
Jun-ichiro> I believe it okay to use IPsec with mobile-ip6. we don't need to
Jun-ichiro> invent a new authentication mechanism. another point made at IETF50
Jun-ichiro> about mobile-ip6 was the lack of PKI infrastructure, which is, a
Jun-ichiro> hard problem by itself and noone is going to be able ot solve this.
Well, the failure for an end node to authenticate the binding update is
that it must continue to use the home agent. It is less efficient, but it
works.
I'm not yet seen a mobilev6+IPsec implementation that I could use even if I
pre-exchanged all the public keys. I'm hopeful that I'll see this soon.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys
iQCVAwUBO9iVf4qHRg3pndX9AQHVrQQAiNfcAGQcUsy68fFopI7edg2Kv90Ld0RM
F5OJeWMT8G4anTno/6fNfm6nxbzvjR0kOdvv/gU6+HEC5ky3nxAFVXNc1fN8zw5a
c/Vwbge6uGlT0YKurDYh8OH5KbHR0LOftWQV9DOFwySoZsdhqMAmTzz+oSDE5qSp
/zc0V3gH3as=
=rSbC
-----END PGP SIGNATURE-----
From owner-ipsec@lists.tislabs.com Thu Oct 25 19:05:15 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9Q25E809499;
Thu, 25 Oct 2001 19:05:14 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA27538
Thu, 25 Oct 2001 21:16:45 -0400 (EDT)
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Cc: ipsec@lists.tislabs.com
In-reply-to: mcr's message of Thu, 25 Oct 2001 18:43:12 -0400.
<200110252243.f9PMhDp00539@marajade.sandelman.ottawa.on.ca>
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2
Subject: Re: Simplifying IKE
From: itojun@iijlab.net
Date: Fri, 26 Oct 2001 10:25:26 +0900
Message-ID: <3862.1004059526@itojun.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>> (not about the ipsec issue... anyway...)
>
>> The above is basically what we (itojun + Dave Johnson) thought
>> around 09 -> 10 mobile-ip6 spec (when we put more details on
>> IPsec manipulation). there were issues raised at IETF50 about policy
>> lookup in such cases. a point was made that there are implementations
>> that are not flexible enough to permit such a tweak.
> Host implementations? Or bump in the stack implementations?
> I really think that this is something which requires integration to get right.
no real example was given, IIRC.
>> now I believe that we should avoid piggybacking the binding
>> updates onto normal packets. if we treat them separately, we can
>> decide IPsec policy completely in a independent manner.
> I feel uncomfortable about this.
> I'm not sure why yet.
uncomfortable about forbidding piggybacking binding updates? why?
>> I believe it okay to use IPsec with mobile-ip6. we don't need to
>> invent a new authentication mechanism. another point made at IETF50
>> about mobile-ip6 was the lack of PKI infrastructure, which is, a
>> hard problem by itself and noone is going to be able ot solve this.
> Well, the failure for an end node to authenticate the binding update is
>that it must continue to use the home agent. It is less efficient, but it
>works.
yes. it will go through inefficient path but works.
my point is, inventing a new security mechanism for mobile-ip6 does not
worth an effort, because regardless from authentication mechanism we
are going to use to authenticate binding update, they would require
PKI infrastructure, therefore, they will fail to satisfy the
requirement posed by the comment to mobile-ip6 + IPsec.
are there any trustworthy authentication mechanism that works WITHOUT
PKI? what are we authenticating in that case?
> I'm not yet seen a mobilev6+IPsec implementation that I could use even if I
>pre-exchanged all the public keys. I'm hopeful that I'll see this soon.
NEC and Keio SFC both do (or did in some point in the past)
mobile-ip6 + IPsec with manual keying.
itojun
From owner-ipsec@lists.tislabs.com Fri Oct 26 12:35:04 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QJZ3829775;
Fri, 26 Oct 2001 12:35:04 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA00770
Fri, 26 Oct 2001 14:20:57 -0400 (EDT)
Date: Fri, 26 Oct 2001 14:23:03 -0400
From: Theodore Tso <tytso@mit.edu>
To: "Scott G. Kelly" <skelly@redcreek.com>
Cc: Barbara Fraser <byfraser@cisco.com>, Tim Jenkins <TJenkins@Catena.com>,
"'rks@cisco.com'" <rks@cisco.com>, tytso@mit.edu, bbruins@cisco.com,
ipsec@lists.tislabs.com, leot@cisco.com
Subject: Re: Status of ID: IPsec Flow Monitoring MIB
Message-ID: <20011026142303.A3991@thunk.org>
References: <4.3.2.7.2.20011019104307.02ebf7f0@mira-sjc5-4.cisco.com> <3BD09FDA.79BDA9D9@redcreek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <3BD09FDA.79BDA9D9@redcreek.com>; from skelly@redcreek.com on Fri, Oct 19, 2001 at 02:49:14PM -0700
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Fri, Oct 19, 2001 at 02:49:14PM -0700, Scott G. Kelly wrote:
> RedCreek has implemented the ipsec monitoring mib, and intends to
> implement the IKE monitoring mibs. Once we reach agreement on a tunnel
> mib, we may implement that as well.
Thanks Scott, for responding.
Are there any other vendors/implementors which have implmeneted the
various proposed MIBs? Although having multiple implementations isn't
a requirement for the first level of standardization, it always
worries me when I-D's are advanced with minimal levels of
implementation. Problems are much more easily fixed before the spec
achieves RFC status, since there's much less of a deployed base.
Which leads us to the next question... assuming that there is only one
attempt to implement the I-D's, what is the working group's feeling
about advancing the documents?
- Ted
From owner-ipsec@lists.tislabs.com Fri Oct 26 14:00:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9QL0T801342;
Fri, 26 Oct 2001 14:00:29 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00961
Fri, 26 Oct 2001 15:44:20 -0400 (EDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15321.48761.134750.547493@thomasm-u1.cisco.com>
Date: Fri, 26 Oct 2001 12:50:17 -0700 (PDT)
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Cc: Jun-ichiro itojun Hagino <itojun@iijlab.net>, ipsec@lists.tislabs.com
Subject: Re: Simplifying IKE
In-Reply-To: <200110252243.f9PMhDp00539@marajade.sandelman.ottawa.on.ca>
References: <20010814164122.68A287BA@starfruit.itojun.org>
<200110252243.f9PMhDp00539@marajade.sandelman.ottawa.on.ca>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
@RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
bUcI'1!
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Michael Richardson writes:
> Jun-ichiro> now I believe that we should avoid piggybacking the binding
> Jun-ichiro> updates onto normal packets. if we treat them separately, we can
> Jun-ichiro> decide IPsec policy completely in a independent manner.
>
> I feel uncomfortable about this.
> I'm not sure why yet.
The problem with binding update piggybacking is
that you have a single IP packet which may, in
fact, have two different protection domains. That
is, the binding update may require authentication
in one realm, which the final payload may require
authentication in another. Currently, there is no
way to express such a rule in the SPD, nor key it.
IPsec is the first one that tripped over this, but
QoS is also negativey affected by piggybacking.
This shouldn't be surprising: IP expects that you
put messages with different functionality into
different packets. Opening this pandora's box is
IMO a generally bad idea.
Mike
From owner-ipsec@lists.tislabs.com Sun Oct 28 16:00:17 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T00G825331;
Sun, 28 Oct 2001 16:00:17 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04442
Sun, 28 Oct 2001 18:19:09 -0500 (EST)
From: rks@cisco.com
Date: Sun, 28 Oct 2001 15:27:30 -0800 (PST)
To: Casey Carr <kcarr@nc.rr.com>
cc: Theodore Tso <tytso@mit.edu>, Barbara Fraser <byfraser@cisco.com>,
Barry Bruins <bbruins@cisco.com>, <ipsec@lists.tislabs.com>,
Cheryl Madson <cmadson@cisco.com>, Narasimha <pcn@cisco.com>,
<leot@cisco.com>
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
In-Reply-To: <LGEPIDKIMCMEJMAHEKALEEJFCFAA.kcarr@nc.rr.com>
Message-ID: <Pine.GSO.4.33.0110281520060.8582-100000@nm-vdm-build1.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Casey -
On Fri, 26 Oct 2001, Casey Carr wrote:
> Are there IETF alternative specifications for monitoring
> IPSec via SNMP? If not, what would the working group recommend
> for monitoring IPSec performance?
There are indeed two competing drafts for IKE and IPsec
monitoring and there is an unfortunate similarity in
their names. The one submitted by Cisco and Tivoli Inc.
is
"IPsec Flow Monitoring MIB"
I'd love to hear your comments on this draft (and from those in
your engineering and marketing groups planning to design
management applications based on SNMP for your product.)
Thanks,
Rk
x77309
----
S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
On Fri, 26 Oct 2001, Casey Carr wrote:
> cipherOptics has committed to implement both the IPSec and IKE monitoring
> MIBs. This effort is scheduled to begin within the next few months. Since
> we have not started this effort, we can not give any constructive feedback
> on these MIBs.
>
> Are there IETF alternative specifications for monitoring IPSec via SNMP? If
> not, what would the working group recommend for monitoring IPSec
> performance?
>
> Casey
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Tso
> Sent: Friday, October 26, 2001 2:23 PM
> To: Scott G. Kelly
> Cc: Barbara Fraser; Tim Jenkins; 'rks@cisco.com'; tytso@mit.edu;
> bbruins@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com
> Subject: Re: Status of ID: IPsec Flow Monitoring MIB
>
>
> On Fri, Oct 19, 2001 at 02:49:14PM -0700, Scott G. Kelly wrote:
> > RedCreek has implemented the ipsec monitoring mib, and intends to
> > implement the IKE monitoring mibs. Once we reach agreement on a tunnel
> > mib, we may implement that as well.
>
> Thanks Scott, for responding.
>
> Are there any other vendors/implementors which have implmeneted the
> various proposed MIBs? Although having multiple implementations isn't
> a requirement for the first level of standardization, it always
> worries me when I-D's are advanced with minimal levels of
> implementation. Problems are much more easily fixed before the spec
> achieves RFC status, since there's much less of a deployed base.
>
> Which leads us to the next question... assuming that there is only one
> attempt to implement the I-D's, what is the working group's feeling
> about advancing the documents?
>
> - Ted
>
>
>
>
From owner-ipsec@lists.tislabs.com Sun Oct 28 16:00:25 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T00P825346;
Sun, 28 Oct 2001 16:00:25 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04342
Sun, 28 Oct 2001 18:08:36 -0500 (EST)
From: rks@cisco.com
Date: Sun, 28 Oct 2001 15:16:57 -0800 (PST)
To: Tim Jenkins <TJenkins@Catena.com>
cc: <byfraser@cisco.com>, <tytso@mit.edu>, <bbruins@cisco.com>,
<ipsec@lists.tislabs.com>, <leot@cisco.com>
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
In-Reply-To: <522FDAAFD532D511A0AB0002A51390EB2F6FE0@cat01s2.catena.com>
Message-ID: <Pine.GSO.4.33.0110281502160.8471-100000@nm-vdm-build1.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi -
I do not understand your first objection below:
you are objecting to a draft because its not based
on another draft? What is the status of your draft?
Why should we base our proposal on it?
I looked through the textual conventions defined by you
and John Shriver <draft-ietf-ipsec-doi-tc-mib-05.txt>.
I find them comprehensive am willing to based our definitions
on them. That is the extent of layering I proposed below.
> As a guide, I have submitted <draft-jenkins-ipsec-tun-mon-mib-00.txt>
> as an illustration of how this can be done.
Unfortunately, this would make it expensive for an
vendors of small IPsec devices to implement the MIB
we propose, although it details very useful abstractions
and correlations. I'd hate to see that happen.
Like I said in my earlier mail, the IPsec Flow Monitor
MIB provides both the protocol view and an application view
and hence can be stand-alone.
Thanks,
Rk
x77309
On Wed, 10 Oct 2001, Tim Jenkins wrote:
> I have two main objections to this MIB document. They are:
> 1) It doesn't use the base IPsec MIBs.
> 2) It does things that are outside the scope of IPsec.
> Below, there is agreement to using the base MIBs, so that
> deals with my first objection. As a guide, I have submitted
> <draft-jenkins-ipsec-tun-mon-mib-00.txt> as an illustration
> of how this can be done.
> As far as I can see, the second objection has not been
> dealt with. While I believe that a number of these
> additional features are things that are user requested
> (such as IP address to domain name conversion; see objects
> ikeTunLocalName and ikeTunRemoteName as examples), it is my
> belief that they do not belong in an IPsec MIB. However,
> there are few of these, so it is likely this objection can
> be easily overcome.
>
> > -----Original Message-----
> > From: rks@cisco.com [mailto:rks@cisco.com]
> > Sent: Tuesday, October 09, 2001 6:14 PM
> > To: byfraser@cisco.com; tytso@mit.edu
> > Cc: bbruins@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com
> > Subject: Status of ID: IPsec Flow Monitoring MIB
> >
> >
> >
> > We proposed the IPsec Flow Monitor MIB in 1999 to aid
> > IPsec monitoring applications designed to evaluate the
> > connectivity and performance and troubleshoot connectivity
> > failures. The MIB has evolved ever since based on comments
> > from early of VPN deployers. We would like to standardize
> > this MIB and want the WG chairs to advance the ID in the
> > standards track.
> >
> >
> > History:
> > The MIB was first defined because the MIBs available during
> > that time in the area were insufficient in providing the
> > abstractions that are desirable to make IPsec manageable.
> >
> > Tivoli Systems (a multi-vendor management company) refined
> > the MIB with Cisco Systems to make it a multi-vendor/standard
> > MIB for managing IPsec networks. After successful deployment in
> > the field, it was revised and the revision was submitted to
> > the WG early this year.
> >
> > The MIB has since been adopted by a few VPN service providers,
> > management vendors and users. Their comments were helpful in
> > further refining the MIB definition.
> >
> >
> > Highlights of the MIB:
> > Defining a MIB to merely export bits of the protocol serves no
> > management purpose. We defined the MIB with the following features:
> >
> > 1. Build abstractions that may be used by the network
> > administrators
> > to identify traffic flows in IPsec networks. This
> > would allow the
> > correlation of the performance of the application traffic with
> > that of the underlying IPsec networks.
> > 2. Help define SLAs to qualify the performance and failures.
> > 3. History and failure tables for trending and troubleshooting.
> > 4. SA tables to aid low level troubleshooting.
> > 5. Separation of IKE and IPsec groups to allow later
> > extensions for
> > other keying protocols to be used with IPsec (such as KINK).
> >
> > I'd very much like to hear comments on this from administrators
> > or NMS developers who are facing the problem of monitoring
> > and troubleshooting IPsec-based VPNs.
> >
> >
> > Coexistence with other MIB drafts:
> > Our proposal may be regarded as being competing or complementary to
> > the low level MIBs proposed by Jenkins et al. To that extent,
> > we are willing to layer our MIB on top of the basic definitions
> > provided by the Jenkins drafts.
> >
> > In 1999, it was proposed that we use the ISAKMP and IPsec textual
> > conventions proposed by Jenkins drafts. This is quite feasible
> > since there is little difference between the TCs proposed by
> > the two drafts.
> >
> >
> > Please advise us on what we need to do in order to advance this MIB
> > in the standards track.
> >
> > Thanks,
> >
> > Leo Temoshenko, Cisco Systems Inc.
> > Cheryl Madson, Cisco Systems Inc.
> > Chinna Pellacuru, Cisco Systems Inc.
> > Bret Harrison, Tivoli Systems Inc.
> > S Ramakrishnan, Cisco Systems Inc.
---
S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
From owner-ipsec@lists.tislabs.com Sun Oct 28 16:00:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T00P825347;
Sun, 28 Oct 2001 16:00:25 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04305
Sun, 28 Oct 2001 17:53:20 -0500 (EST)
From: rks@cisco.com
To: Theodore Tso <tytso@mit.edu>
Cc: Tim Jenkins <TJenkins@Catena.com>, bbruins@cisco.com,
bret_harrison@tivoli.com, Barbara Fraser <byfraser@cisco.com>,
cmadson@cisco.com, ipsec@lists.tislabs.com, leot@cisco.com, pcn@cisco.com
Subject: Re: Status of ID: IPsec Flow Monitoring MIB
Date: Fri, 26 Oct 2001 14:23:03 -0400
Message-ID: <20011026142303.A3991@thunk.org>
References: <4.3.2.7.2.20011019104307.02ebf7f0@mira-sjc5-4.cisco.com> <3BD09FDA.79BDA9D9@redcreek.com> <3BD09FDA.79BDA9D9@redcreek.com>
In-Reply-To: <20011026142303.A3991@thunk.org>; from Theodore Tso <tytso@mit.edu> Fri, 26 Oct 2001 14:23:03 -0400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi -
From: Theodore Tso <tytso@mit.edu>
Date: On Fri, 26 Oct 2001 14:23:03 -0400
>Which leads us to the next question... assuming that there
>is only one attempt to implement the I-D's, what is the
>working group's feeling about advancing the documents?
I have looked through the IKE and IPsec monitoring MIBs
and I am a bit confused about the purpose of these "low level" MIBs.
Why were these defined and what problem are they meant to solve?
MIBs that dish out bits of the protocol merely because the bits
happen to be there, serve very little purpose (let's call
such MIBs "protocol MIBs").
Why would an administrator use them instead of the command
line interface (I am not sure there is a device out there
that supports SNMP protocol but not management through
telnet)?
One answer to my last question could be the following:
Monitoring and troubleshooting are done in the context of
an application of IPsec (such as VPNs). Hence, if a problem
with the application is traced down to the underlying protocol
(IPsec), the ensuing troubleshooting would require the nuts and bolts
of the protocol. Hence, I'd argue that without a MIB that provides
abstractions on top of the protocol view (an "application MIB"),
the protocol MIB serves little purpose.
Its precisely for this reason that we (Tivoli Inc and Cisco)
drafted the IPsec Flow Monitoring MIB and proposed it to
IETF in Fall 1999. We were looking to building monitoring
and troubleshooting applications for IPsec-based VPNs. The MIBs
available in the WG at that time were too low level and hence
unsuitable for our purposes. The result of our work was a MIB
that provides both the views: it provides the abstractions of
IKE and IPsec Flows ("tunnels"), provides low level SA view of the
IPsec flows and correlates between the two views. I contend that
out proposal "IPsec Flow Monitoring MIB" can be stand alone
or can make use of some components defined by Jenkins et al.
Finally, I'd like to hear comments from vendors (ISPs, VPN SPs, etc)
who are going to make use of these MIBs to provide VPN SLAs and other
goodies: please contrast the IPsec Monitoring MIB and the
"IPsec Flow Monitor MIB". Your comments from the trenches would be
invaluable to us in improving our proposal.
There has not been any discussion on these MIBs, leave alone
a debate contrasting the two approaches (the Jenkins drafts and
the IPsec Flow Monitoring MIB, proposed by us).
Hence, how can it be appropriate to take these drafts to the
final call?
Rk
x77309
---
S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
From owner-ipsec@lists.tislabs.com Sun Oct 28 18:16:08 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T2G7827745;
Sun, 28 Oct 2001 18:16:07 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04703
Sun, 28 Oct 2001 20:26:29 -0500 (EST)
Message-Id: <200110290135.UAA18324@bcn.East.Sun.COM>
Date: Sun, 28 Oct 2001 20:35:21 -0500 (EST)
From: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Reply-To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Subject: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
To: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 5io9XiTpPRsU6wrZxjsoGA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I don't quite understand why IKE is negotiating IPcomp, and it clutters
up the IKE spec. Presumably IPcomp should exist outside of IPsec, as
in you might want to send a compressed packet even if it isn't
cryptographically protected. So presumably there's already some way
of negotiating compression algorithms, or at least there would have
to be in order to deploy IPcomp without IPsec. So would anyone object
to removing all mention of IPcomp from the IKE spec?
If anyone likes IPcomp and wants it
to stay in IKE, perhaps they'd be willing to explain it to me? :-)
Radia
From owner-ipsec@lists.tislabs.com Sun Oct 28 18:34:42 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T2Yg828071;
Sun, 28 Oct 2001 18:34:42 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA04726
Sun, 28 Oct 2001 20:47:57 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 28 Oct 2001 20:55:44 -0500
Message-Id: <20011029015544.B57687B55@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <200110290135.UAA18324@bcn.East.Sun.COM>, Radia Perlman - Boston Cen
ter for Networking writes:
>I don't quite understand why IKE is negotiating IPcomp, and it clutters
>up the IKE spec. Presumably IPcomp should exist outside of IPsec, as
>in you might want to send a compressed packet even if it isn't
>cryptographically protected. So presumably there's already some way
>of negotiating compression algorithms, or at least there would have
>to be in order to deploy IPcomp without IPsec. So would anyone object
>to removing all mention of IPcomp from the IKE spec?
>
>If anyone likes IPcomp and wants it
>to stay in IKE, perhaps they'd be willing to explain it to me? :-)
The problem is that link-layer encryption -- the most common form below
the application -- doesn't work on IPsec packets, and the upper layers
may not be aware of, say, gateway-to-gateway IPsec. The IPsec layer,
in other words, is the first to know for sure that a lower layer can't
do the encryption that might be desired.
There's no other negotiation mechanism for IPcomp because compression
is circuit-like, and there are no other circuits at the IP layer. (For
discussion on how to negotiate compression at the TCP layer, see
http://www.research.att.com/~smb/papers/draft-bellovin-tcpfilt-00.txt
and http://www.research.att.com/~smb/papers/draft-bellovin-tcpcomp-00.txt.
We've implemented the scheme, and are planning on updating and
resubmitting the drafts.)
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Sun Oct 28 19:28:06 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T3S6828944;
Sun, 28 Oct 2001 19:28:06 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA04828
Sun, 28 Oct 2001 21:42:56 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Cc: ipsec@lists.tislabs.com
Subject: Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 28 Oct 2001 21:50:40 -0500
Message-Id: <20011029025040.97DB87B55@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <200110290247.VAA18598@bcn.East.Sun.COM>, Radia Perlman - Boston Cen
ter for Networking writes:
>"Steven M. Bellovin" <smb@research.att.com> writes:
>>The problem is that link-layer encryption -- the most common form below
>>the application -- doesn't work on IPsec packets, and the upper layers
>>may not be aware of, say, gateway-to-gateway IPsec. The IPsec layer,
>>in other words, is the first to know for sure that a lower layer can't
>>do the encryption that might be desired.
>>
>>There's no other negotiation mechanism for IPcomp because compression
>>is circuit-like, and there are no other circuits at the IP layer. (For
>>discussion on how to negotiate compression at the TCP layer, see
>>http://www.research.att.com/~smb/papers/draft-bellovin-tcpfilt-00.txt
>>and http://www.research.att.com/~smb/papers/draft-bellovin-tcpcomp-00.txt.
>
>[I assume you mean "link-layer compression" above, not "link-layer encryption"
>].
I did indeed.
>Thanks! What I needed was a pointer to RFC 2393, which I got from your
>paper pointed to above.
>
>It does seem as though doing it end-to-end independently of IPsec (as
>is done in the internet draft you pointed me to) would
>be a better thing. Though I suppose doing it in IKE means that it works
>for UDP also. So I guess I can't assume a TCP mechanism for negotiating
>compression will replace the IKE mechanism.
Right, though of course most traffic by volume is TCP. TCP compression
is better because it retains state, rather than having to compress each
packet individually; we have some numbers that demonstrate this very clearly.
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Sun Oct 28 19:30:36 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T3UZ829012;
Sun, 28 Oct 2001 19:30:36 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA04822
Sun, 28 Oct 2001 21:38:21 -0500 (EST)
Message-Id: <200110290247.VAA18598@bcn.East.Sun.COM>
Date: Sun, 28 Oct 2001 21:47:10 -0500 (EST)
From: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Reply-To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Subject: Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
To: Radia.Perlman@sun.com, smb@research.att.com
Cc: ipsec@lists.tislabs.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: mDF6awvk+WzneJAABQcb6g==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
"Steven M. Bellovin" <smb@research.att.com> writes:
>The problem is that link-layer encryption -- the most common form below
>the application -- doesn't work on IPsec packets, and the upper layers
>may not be aware of, say, gateway-to-gateway IPsec. The IPsec layer,
>in other words, is the first to know for sure that a lower layer can't
>do the encryption that might be desired.
>
>There's no other negotiation mechanism for IPcomp because compression
>is circuit-like, and there are no other circuits at the IP layer. (For
>discussion on how to negotiate compression at the TCP layer, see
>http://www.research.att.com/~smb/papers/draft-bellovin-tcpfilt-00.txt
>and http://www.research.att.com/~smb/papers/draft-bellovin-tcpcomp-00.txt.
[I assume you mean "link-layer compression" above, not "link-layer encryption"].
Thanks! What I needed was a pointer to RFC 2393, which I got from your
paper pointed to above.
It does seem as though doing it end-to-end independently of IPsec (as
is done in the internet draft you pointed me to) would
be a better thing. Though I suppose doing it in IKE means that it works
for UDP also. So I guess I can't assume a TCP mechanism for negotiating
compression will replace the IKE mechanism.
Radia
From owner-ipsec@lists.tislabs.com Sun Oct 28 19:36:50 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9T3ao829110;
Sun, 28 Oct 2001 19:36:50 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA04852
Sun, 28 Oct 2001 21:53:55 -0500 (EST)
To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
Cc: ipsec@lists.tislabs.com
In-reply-to: Radia.Perlman's message of Sun, 28 Oct 2001 20:35:21 EST.
<200110290135.UAA18324@bcn.East.Sun.COM>
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2
Subject: Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
From: itojun@iijlab.net
Date: Mon, 29 Oct 2001 12:02:44 +0900
Message-ID: <21316.1004324564@itojun.org>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>I don't quite understand why IKE is negotiating IPcomp, and it clutters
>up the IKE spec. Presumably IPcomp should exist outside of IPsec, as
>in you might want to send a compressed packet even if it isn't
>cryptographically protected. So presumably there's already some way
>of negotiating compression algorithms, or at least there would have
>to be in order to deploy IPcomp without IPsec. So would anyone object
>to removing all mention of IPcomp from the IKE spec?
>
>If anyone likes IPcomp and wants it
>to stay in IKE, perhaps they'd be willing to explain it to me? :-)
you can't be sure that your peer supports IPComp or not, until
you negotiate it. also, you will want to negotiate what algorithm
to use, what CPI to use, and such.
(I'm not advocating IPComp negotiation with IKE...)
itojun
From owner-ipsec@lists.tislabs.com Mon Oct 29 02:28:38 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TASc806044;
Mon, 29 Oct 2001 02:28:38 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA05575
Mon, 29 Oct 2001 04:14:53 -0500 (EST)
Reply-To: <tsuruta@insi.co.jp>
From: "Masafumi Tsuruta" <tsuruta@insi.co.jp>
To: <ipsec@lists.tislabs.com>
Subject: IPSec SA's contents
Date: Mon, 29 Oct 2001 18:23:41 +0900
Message-ID: <000501c1605b$66f1d620$8300a8c0@tsuruta>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
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.50.4133.2400
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi.
I have a question about IPSec SA. Please give me any suggestion if you don't
worry.
In Phase 2, Quickmode, according to RFC 2409 <5.5 Phase 2 - Quick Mode> an
ascii art explains how works quickmode as below.
-----------------------begin-----------------------------------
Initiator | Responder
HDR*, HASH (1), SA, Ni,
[, KE] [, IDci, IDcr] -->
<-- HDR*, HASH (2), SA, Nr
[, KE] [, IDci, IDcr]
HDR*, HASH (3) -->
-----------------------end-------------------------------------
In this figure, I can't understand what is in the "SA". Some components (ex.
Nonce payload) are part from "SA", so I can't understand "SA" contents.
Please tell me the contents of "SA". Thank you.
Masafumi Tsuruta
tsuruta@insi.co.jp
From owner-ipsec@lists.tislabs.com Mon Oct 29 07:54:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TFsh826947;
Mon, 29 Oct 2001 07:54:44 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06062
Mon, 29 Oct 2001 10:01:27 -0500 (EST)
Message-ID: <3BDD713D.57B463A6@hns.com>
Date: Mon, 29 Oct 2001 10:09:49 -0500
From: John Border <border@hns.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
CC: ipsec@lists.tislabs.com, narten@raleigh.ibm.com, nordmark@Eng.Sun.COM
Subject: Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
References: <200110290135.UAA18324@bcn.East.Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I have always assumed that the reason is based on advice I have often
heard given by the Trasport ADs to Transport working groups... "Don't invent
a new protocol if an existing protocol can be adapted to meet the
requirements." If IKE was not used to negotiate IPcomp, then something else
would have needed to be developed to do so.
In addition (or maybe instead, see my disclaimer), there is a relationship
between compression and encryption in that compression needs to occur first if
both are to be used. Therefore, negotiating them at the same time seems more
efficient in terms of the number of handshakes required.
Disclaimer: I was not around when IPcomp was developed, so I do not know
for a fact that this reasoning is correct. And, I am not sure to which
working group mailing list to forward the question. I am pretty sure the work
was done in the Internet Area because the Internet ADs are the ones who took
an interest when I submitted an independent I-D for publication as an
Informational RFC for a specific IPComp protocol (V.44)...
John
Radia Perlman - Boston Center for Networking wrote:
>
> I don't quite understand why IKE is negotiating IPcomp, and it clutters
> up the IKE spec. Presumably IPcomp should exist outside of IPsec, as
> in you might want to send a compressed packet even if it isn't
> cryptographically protected. So presumably there's already some way
> of negotiating compression algorithms, or at least there would have
> to be in order to deploy IPcomp without IPsec. So would anyone object
> to removing all mention of IPcomp from the IKE spec?
>
> If anyone likes IPcomp and wants it
> to stay in IKE, perhaps they'd be willing to explain it to me? :-)
>
> Radia
From owner-ipsec@lists.tislabs.com Mon Oct 29 08:02:47 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9TG2j829485;
Mon, 29 Oct 2001 08:02:46 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06039
Mon, 29 Oct 2001 09:44:27 -0500 (EST)
Message-ID: <C703B434E680D511BDFD0002A50706960CCE25@hdsmsx101.hd.intel.com>
From: "Shriver, John" <john.shriver@intel.com>
To: "'rks@cisco.com'" <rks@cisco.com>, Theodore Tso <tytso@mit.edu>
Cc: Tim Jenkins <TJenkins@Catena.com>, bbruins@cisco.com,
bret_harrison@tivoli.com, Barbara Fraser <byfraser@cisco.com>,
cmadson@cisco.com, ipsec@lists.tislabs.com, leot@cisco.com, pcn@cisco.com
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
Date: Mon, 29 Oct 2001 06:54:01 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="ISO-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Comments inline...
> -----Original Message-----
> From: rks@cisco.com [mailto:rks@cisco.com]
> Sent: Friday, October 26, 2001 2:23 PM
> To: Theodore Tso
> Cc: Tim Jenkins; bbruins@cisco.com; bret_harrison@tivoli.com; Barbara
> Fraser; cmadson@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com;
> pcn@cisco.com
> Subject: Re: Status of ID: IPsec Flow Monitoring MIB
>
>
> Hi -
>
> From: Theodore Tso <tytso@mit.edu>
> Date: On Fri, 26 Oct 2001 14:23:03 -0400
>
> >Which leads us to the next question... assuming that there
> >is only one attempt to implement the I-D's, what is the
> >working group's feeling about advancing the documents?
>
>
> I have looked through the IKE and IPsec monitoring MIBs
> and I am a bit confused about the purpose of these "low level" MIBs.
> Why were these defined and what problem are they meant to solve?
> MIBs that dish out bits of the protocol merely because the bits
> happen to be there, serve very little purpose (let's call
> such MIBs "protocol MIBs").
Well, there are IETF rules about protocols, progress along the standards
path, and SNMP MIBs. No MIB, no Full Standard status. That's what got me
initially interested.
>
> Why would an administrator use them instead of the command
> line interface (I am not sure there is a device out there
> that supports SNMP protocol but not management through
> telnet)?
Two reasons:
Because you are using the MIB because you cannot establish an IPsec session
with the managed system. If you can't establish an IPsec session, how are
you going to establish a Telnet session that is secure enough to be allowed
access to the CLI?
Because you need to automate troubleshooting, and you're not going to do
that with a CLI management interface. These MIBs were designed according to
criteria set out by people at BBN when we were courting them as a customer,
to be able to troubleshoot a particular IPsec "session" WITHOUT having to do
any table searching. That is what makes the indexing complicated. (BBN is
famous for knowing how to manage a network.)
>
> One answer to my last question could be the following:
> Monitoring and troubleshooting are done in the context of
> an application of IPsec (such as VPNs). Hence, if a problem
> with the application is traced down to the underlying protocol
> (IPsec), the ensuing troubleshooting would require the nuts and bolts
> of the protocol. Hence, I'd argue that without a MIB that provides
> abstractions on top of the protocol view (an "application MIB"),
> the protocol MIB serves little purpose.
I fully agree that application oriented MIBs on top of these MIBs are fully
appropriate.
> There has not been any discussion on these MIBs, leave alone
> a debate contrasting the two approaches (the Jenkins drafts and
> the IPsec Flow Monitoring MIB, proposed by us).
They have been presented at the IETF meeting, and few issues were raised.
Those issues were addressed in revisions.
We've had a lot of good review comments from various reviewers. I started
as a reviewer, and progressed into co-authorship.
There are admittedly some curious issues of managing a strong secure
protocol like IPsec with the much more modestly secure protocol SNMPv3.
I will admit that the drafts now have a bunch of redundant layering, since
there may someday be a revision of IKE that "flattens out" the
specifications. But we have put a lot of work into making them
"well-formed" MIBs.
>
> Hence, how can it be appropriate to take these drafts to the
> final call?
>
> Rk
> x77309
>
> ---
> S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
>
From owner-ipsec@lists.tislabs.com Mon Oct 29 09:12:12 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9THCB805533;
Mon, 29 Oct 2001 09:12:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06290
Mon, 29 Oct 2001 11:16:17 -0500 (EST)
Message-ID: <522FDAAFD532D511A0AB0002A51390EB2F7082@cat01s2.catena.com>
From: Tim Jenkins <TJenkins@Catena.com>
To: "'rks@cisco.com'" <rks@cisco.com>
Cc: byfraser@cisco.com, tytso@mit.edu, bbruins@cisco.com,
ipsec@lists.tislabs.com, leot@cisco.com
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
Date: Mon, 29 Oct 2001 09:41:29 -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
> -----Original Message-----
> From: rks@cisco.com [mailto:rks@cisco.com]
> Sent: Sunday, October 28, 2001 6:17 PM
> To: Tim Jenkins
> Cc: byfraser@cisco.com; tytso@mit.edu; bbruins@cisco.com;
> ipsec@lists.tislabs.com; leot@cisco.com
> Subject: RE: Status of ID: IPsec Flow Monitoring MIB
>
>
> Hi -
>
> I do not understand your first objection below:
> you are objecting to a draft because its not based
> on another draft? What is the status of your draft?
> Why should we base our proposal on it?
Yes, I'm objecting that it's not based on the other drafts
because the intent of those drafts was to be the MIBs
produced by the working group to monitor the stuff that
came out of the working group.
Since they are not application specific, and in their raw
form may not be what most implementors want, it is expected
that they will be used as the building blocks for application
specific MIBs. That is why I submitted the tunnel monitoring
MIB: as an example of how the base MIBs could be used as
the building block of an application specific MIB.
The status is that they have had minimal changes for the last
three revisions, and are ready for last call. We get next to
no comments on them now. (But we do know people are reading
them, since we get private questions on them.)
Why should you base yours on them? Well, if they become the
standard MIBs for IPsec, then you'll likely have to implement
them anyway, so it would make your application level MIB much
smaller and easier to implement.
>
> I looked through the textual conventions defined by you
> and John Shriver <draft-ietf-ipsec-doi-tc-mib-05.txt>.
> I find them comprehensive am willing to based our definitions
> on them. That is the extent of layering I proposed below.
>
> > As a guide, I have submitted
> <draft-jenkins-ipsec-tun-mon-mib-00.txt>
> > as an illustration of how this can be done.
>
> Unfortunately, this would make it expensive for an
> vendors of small IPsec devices to implement the MIB
> we propose, although it details very useful abstractions
> and correlations. I'd hate to see that happen.
See what happen again?
>
> Like I said in my earlier mail, the IPsec Flow Monitor
> MIB provides both the protocol view and an application view
> and hence can be stand-alone.
>
Agreed it does.
When I first started the MIBs, I proposed one that looked very
similar to yours, in fact, it was similar to the tunnel MIB
I submitted with alot of the IPsec stuff as well.
This version was very forcefully rejected by the working group
at the meeting in Orlando because it was application specific,
and did not separate the components out. That is why there exists
the series you see today that honours the separation of the IPsec
components as they exist today.
Perhaps the working group has changed its mind. If it hasn't,
then I don't see how the Flow monitoring MIB can be advanced as
it is since it duplicates much of what is already done in the
collection of base MIBs.
> Thanks,
>
> Rk
> x77309
>
>
> On Wed, 10 Oct 2001, Tim Jenkins wrote:
>
>
> > I have two main objections to this MIB document. They are:
> > 1) It doesn't use the base IPsec MIBs.
> > 2) It does things that are outside the scope of IPsec.
>
> > Below, there is agreement to using the base MIBs, so that
> > deals with my first objection. As a guide, I have submitted
> > <draft-jenkins-ipsec-tun-mon-mib-00.txt> as an illustration
> > of how this can be done.
>
> > As far as I can see, the second objection has not been
> > dealt with. While I believe that a number of these
> > additional features are things that are user requested
> > (such as IP address to domain name conversion; see objects
> > ikeTunLocalName and ikeTunRemoteName as examples), it is my
> > belief that they do not belong in an IPsec MIB. However,
> > there are few of these, so it is likely this objection can
> > be easily overcome.
>
> >
> > > -----Original Message-----
> > > From: rks@cisco.com [mailto:rks@cisco.com]
> > > Sent: Tuesday, October 09, 2001 6:14 PM
> > > To: byfraser@cisco.com; tytso@mit.edu
> > > Cc: bbruins@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com
> > > Subject: Status of ID: IPsec Flow Monitoring MIB
> > >
> > >
> > >
> > > We proposed the IPsec Flow Monitor MIB in 1999 to aid
> > > IPsec monitoring applications designed to evaluate the
> > > connectivity and performance and troubleshoot connectivity
> > > failures. The MIB has evolved ever since based on comments
> > > from early of VPN deployers. We would like to standardize
> > > this MIB and want the WG chairs to advance the ID in the
> > > standards track.
> > >
> > >
> > > History:
> > > The MIB was first defined because the MIBs available during
> > > that time in the area were insufficient in providing the
> > > abstractions that are desirable to make IPsec manageable.
> > >
> > > Tivoli Systems (a multi-vendor management company) refined
> > > the MIB with Cisco Systems to make it a multi-vendor/standard
> > > MIB for managing IPsec networks. After successful deployment in
> > > the field, it was revised and the revision was submitted to
> > > the WG early this year.
> > >
> > > The MIB has since been adopted by a few VPN service providers,
> > > management vendors and users. Their comments were helpful in
> > > further refining the MIB definition.
> > >
> > >
> > > Highlights of the MIB:
> > > Defining a MIB to merely export bits of the protocol serves no
> > > management purpose. We defined the MIB with the
> following features:
> > >
> > > 1. Build abstractions that may be used by the network
> > > administrators
> > > to identify traffic flows in IPsec networks. This
> > > would allow the
> > > correlation of the performance of the application
> traffic with
> > > that of the underlying IPsec networks.
> > > 2. Help define SLAs to qualify the performance and failures.
> > > 3. History and failure tables for trending and
> troubleshooting.
> > > 4. SA tables to aid low level troubleshooting.
> > > 5. Separation of IKE and IPsec groups to allow later
> > > extensions for
> > > other keying protocols to be used with IPsec (such
> as KINK).
> > >
> > > I'd very much like to hear comments on this from
> administrators
> > > or NMS developers who are facing the problem of monitoring
> > > and troubleshooting IPsec-based VPNs.
> > >
> > >
> > > Coexistence with other MIB drafts:
> > > Our proposal may be regarded as being competing or
> complementary to
> > > the low level MIBs proposed by Jenkins et al. To that extent,
> > > we are willing to layer our MIB on top of the basic definitions
> > > provided by the Jenkins drafts.
> > >
> > > In 1999, it was proposed that we use the ISAKMP and
> IPsec textual
> > > conventions proposed by Jenkins drafts. This is quite feasible
> > > since there is little difference between the TCs proposed by
> > > the two drafts.
> > >
> > >
> > > Please advise us on what we need to do in order to
> advance this MIB
> > > in the standards track.
> > >
> > > Thanks,
> > >
> > > Leo Temoshenko, Cisco Systems Inc.
> > > Cheryl Madson, Cisco Systems Inc.
> > > Chinna Pellacuru, Cisco Systems Inc.
> > > Bret Harrison, Tivoli Systems Inc.
> > > S Ramakrishnan, Cisco Systems Inc.
>
> ---
> S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
>
From owner-ipsec@lists.tislabs.com Mon Oct 29 09:17:00 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9THH0805767;
Mon, 29 Oct 2001 09:17:00 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06263
Mon, 29 Oct 2001 11:14:16 -0500 (EST)
From: "Casey Carr" <kcarr@nc.rr.com>
To: "Theodore Tso" <tytso@mit.edu>, "Scott G. Kelly" <skelly@redcreek.com>
Cc: "Barbara Fraser" <byfraser@cisco.com>, "Tim Jenkins" <TJenkins@Catena.com>,
<rks@cisco.com>, <bbruins@cisco.com>, <ipsec@lists.tislabs.com>,
<leot@cisco.com>
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
Date: Fri, 26 Oct 2001 16:50:03 -0400
Message-ID: <LGEPIDKIMCMEJMAHEKALEEJFCFAA.kcarr@nc.rr.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 IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <20011026142303.A3991@thunk.org>
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
cipherOptics has committed to implement both the IPSec and IKE monitoring
MIBs. This effort is scheduled to begin within the next few months. Since
we have not started this effort, we can not give any constructive feedback
on these MIBs.
Are there IETF alternative specifications for monitoring IPSec via SNMP? If
not, what would the working group recommend for monitoring IPSec
performance?
Casey
-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Tso
Sent: Friday, October 26, 2001 2:23 PM
To: Scott G. Kelly
Cc: Barbara Fraser; Tim Jenkins; 'rks@cisco.com'; tytso@mit.edu;
bbruins@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com
Subject: Re: Status of ID: IPsec Flow Monitoring MIB
On Fri, Oct 19, 2001 at 02:49:14PM -0700, Scott G. Kelly wrote:
> RedCreek has implemented the ipsec monitoring mib, and intends to
> implement the IKE monitoring mibs. Once we reach agreement on a tunnel
> mib, we may implement that as well.
Thanks Scott, for responding.
Are there any other vendors/implementors which have implmeneted the
various proposed MIBs? Although having multiple implementations isn't
a requirement for the first level of standardization, it always
worries me when I-D's are advanced with minimal levels of
implementation. Problems are much more easily fixed before the spec
achieves RFC status, since there's much less of a deployed base.
Which leads us to the next question... assuming that there is only one
attempt to implement the I-D's, what is the working group's feeling
about advancing the documents?
- Ted
From owner-ipsec@lists.tislabs.com Mon Oct 29 09:17:46 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9THHj805800;
Mon, 29 Oct 2001 09:17:45 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06301
Mon, 29 Oct 2001 11:16:20 -0500 (EST)
Message-ID: <522FDAAFD532D511A0AB0002A51390EB2F7084@cat01s2.catena.com>
From: Tim Jenkins <TJenkins@Catena.com>
To: "'rks@cisco.com'" <rks@cisco.com>, Casey Carr <kcarr@nc.rr.com>
Cc: Theodore Tso <tytso@mit.edu>, Barbara Fraser <byfraser@cisco.com>,
Barry Bruins <bbruins@cisco.com>, ipsec@lists.tislabs.com,
Cheryl Madson
<cmadson@cisco.com>, Narasimha <pcn@cisco.com>,
leot@cisco.com
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
Date: Mon, 29 Oct 2001 09:55:50 -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
> Casey -
>
> On Fri, 26 Oct 2001, Casey Carr wrote:
>
> > Are there IETF alternative specifications for monitoring
> > IPSec via SNMP? If not, what would the working group recommend
> > for monitoring IPSec performance?
>
> There are indeed two competing drafts for IKE and IPsec
> monitoring and there is an unfortunate similarity in
> their names. The one submitted by Cisco and Tivoli Inc.
> is...
I beg to differ. The series submitted by John Shriver and me
does not 'compete' with the flow monitoring MIB.
The series John and I submitted defines the components of IPsec
as developed by the working group and are application independent.
If you use only some components of the work done in the IPsec WG,
you only some of the MIBs.
The flow monitoring MIB is an application specific MIB which
redefines the presentation of the components of IPsec in that
single application specific MIB.
I think the working group really needs to ask:
1) Do the MIBs submitted by John and I represent the work developed
by the working group?
2) Should the working group develop an application specific MIB for
IPsec?
If the answer to 2) is yes, then the obvious next question is:
3) Should any application specific MIB re-use the MIBs that represent
the work done by the working group, or should it be a stand-alone
MIB?
Tim
> -----Original Message-----
> From: rks@cisco.com [mailto:rks@cisco.com]
> Sent: Sunday, October 28, 2001 6:28 PM
> To: Casey Carr
> Cc: Theodore Tso; Barbara Fraser; Barry Bruins;
> ipsec@lists.tislabs.com;
> Cheryl Madson; Narasimha; leot@cisco.com
> Subject: RE: Status of ID: IPsec Flow Monitoring MIB
>
>
From owner-ipsec@lists.tislabs.com Mon Oct 29 09:24:15 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9THOE805947;
Mon, 29 Oct 2001 09:24:14 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA06302
Mon, 29 Oct 2001 11:16:21 -0500 (EST)
Message-ID: <522FDAAFD532D511A0AB0002A51390EB2F7083@cat01s2.catena.com>
From: Tim Jenkins <TJenkins@Catena.com>
To: "'rks@cisco.com'" <rks@cisco.com>, Theodore Tso <tytso@mit.edu>
Cc: bbruins@cisco.com, bret_harrison@tivoli.com,
Barbara Fraser
<byfraser@cisco.com>, cmadson@cisco.com,
ipsec@lists.tislabs.com, leot@cisco.com, pcn@cisco.com
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
Date: Mon, 29 Oct 2001 09:49:02 -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
> -----Original Message-----
> From: rks@cisco.com [mailto:rks@cisco.com]
> Sent: Friday, October 26, 2001 2:23 PM
> To: Theodore Tso
> Cc: Tim Jenkins; bbruins@cisco.com; bret_harrison@tivoli.com; Barbara
> Fraser; cmadson@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com;
> pcn@cisco.com
> Subject: Re: Status of ID: IPsec Flow Monitoring MIB
>
>
> Hi -
>
> From: Theodore Tso <tytso@mit.edu>
> Date: On Fri, 26 Oct 2001 14:23:03 -0400
>
> >Which leads us to the next question... assuming that there
> >is only one attempt to implement the I-D's, what is the
> >working group's feeling about advancing the documents?
>
>
> I have looked through the IKE and IPsec monitoring MIBs
> and I am a bit confused about the purpose of these "low level" MIBs.
> Why were these defined and what problem are they meant to solve?
> MIBs that dish out bits of the protocol merely because the bits
> happen to be there, serve very little purpose (let's call
> such MIBs "protocol MIBs").
As I mentioned elsewhere, they are not application specifc because
that is what the working group wanted, as was made clear in Orlando
(yes, that long ago).
The split as is allows parts of them to be used if you use IPsec SAs
with manual keying or some other key exchange protocol. It allows
you to use the ISAKMP portion if you build a different key exchange
protocol on top of ISAKMP.
This is what the working group wanted and I believe we have provided.
Further, I believe, and I said this when the Flow monitoring MIB
was first presented, that any application level MIB should use these
base MIBs, rather than forcing a second presentation of the same
information in another way.
>
> Why would an administrator use them instead of the command
> line interface (I am not sure there is a device out there
> that supports SNMP protocol but not management through
> telnet)?
>
> One answer to my last question could be the following:
> Monitoring and troubleshooting are done in the context of
> an application of IPsec (such as VPNs). Hence, if a problem
> with the application is traced down to the underlying protocol
> (IPsec), the ensuing troubleshooting would require the nuts and bolts
> of the protocol. Hence, I'd argue that without a MIB that provides
> abstractions on top of the protocol view (an "application MIB"),
> the protocol MIB serves little purpose.
>
> Its precisely for this reason that we (Tivoli Inc and Cisco)
> drafted the IPsec Flow Monitoring MIB and proposed it to
> IETF in Fall 1999. We were looking to building monitoring
> and troubleshooting applications for IPsec-based VPNs. The MIBs
> available in the WG at that time were too low level and hence
> unsuitable for our purposes. The result of our work was a MIB
> that provides both the views: it provides the abstractions of
> IKE and IPsec Flows ("tunnels"), provides low level SA view of the
> IPsec flows and correlates between the two views. I contend that
> out proposal "IPsec Flow Monitoring MIB" can be stand alone
> or can make use of some components defined by Jenkins et al.
>
Again, there is no doubt an application specific is valuable or
needed. This is not an either-or case. My view is simply this:
any application level MIB of IPsec should use the component MIBs,
rather than re-defining the components. The flow monitoring MIB
is an application level MIB, and it should define the application,
not the components.
> Finally, I'd like to hear comments from vendors (ISPs, VPN SPs, etc)
> who are going to make use of these MIBs to provide VPN SLAs and other
> goodies: please contrast the IPsec Monitoring MIB and the
> "IPsec Flow Monitor MIB". Your comments from the trenches would be
> invaluable to us in improving our proposal.
>
> There has not been any discussion on these MIBs, leave alone
> a debate contrasting the two approaches (the Jenkins drafts and
> the IPsec Flow Monitoring MIB, proposed by us).
>
> Hence, how can it be appropriate to take these drafts to the
> final call?
Because the components MIBs define the components as defined
by the working group.
>
> Rk
> x77309
>
> ---
> S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
>
From owner-ipsec@lists.tislabs.com Mon Oct 29 17:27:21 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U1RK822675;
Mon, 29 Oct 2001 17:27:20 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08052
Mon, 29 Oct 2001 19:01:41 -0500 (EST)
Message-ID: <3BDDFE00.24788C0B@redcreek.com>
Date: Mon, 29 Oct 2001 17:10:24 -0800
From: "Scott G. Kelly" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: rks@cisco.com
CC: Theodore Tso <tytso@mit.edu>, Tim Jenkins <TJenkins@Catena.com>,
bbruins@cisco.com, bret_harrison@tivoli.com,
Barbara Fraser <byfraser@cisco.com>, cmadson@cisco.com,
ipsec@lists.tislabs.com, leot@cisco.com, pcn@cisco.com
Subject: Re: Status of ID: IPsec Flow Monitoring MIB
References: <4.3.2.7.2.20011019104307.02ebf7f0@mira-sjc5-4.cisco.com> <3BD09FDA.79BDA9D9@redcreek.com> <3BD09FDA.79BDA9D9@redcreek.com> <20011026142303.A3991@thunk.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
rks@cisco.com wrote:
>
> Hi -
>
> From: Theodore Tso <tytso@mit.edu>
> Date: On Fri, 26 Oct 2001 14:23:03 -0400
>
> >Which leads us to the next question... assuming that there
> >is only one attempt to implement the I-D's, what is the
> >working group's feeling about advancing the documents?
>
> I have looked through the IKE and IPsec monitoring MIBs
> and I am a bit confused about the purpose of these "low level" MIBs.
> Why were these defined and what problem are they meant to solve?
> MIBs that dish out bits of the protocol merely because the bits
> happen to be there, serve very little purpose (let's call
> such MIBs "protocol MIBs").
I think Tim did a nice job of answering this.
> Why would an administrator use them instead of the command
> line interface (I am not sure there is a device out there
> that supports SNMP protocol but not management through
> telnet)?
RedCreek devices support SNMP, but not telnet-based device management.
<trimmed...>
> There has not been any discussion on these MIBs, leave alone
> a debate contrasting the two approaches (the Jenkins drafts and
> the IPsec Flow Monitoring MIB, proposed by us).
>
> Hence, how can it be appropriate to take these drafts to the
> final call?
I think these drafts and MIBs have been discussed at length - just not
recently. I believe the wg minutes and archives will bear this out.
Scott
From owner-ipsec@lists.tislabs.com Mon Oct 29 20:30:20 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9U4UJ826881;
Mon, 29 Oct 2001 20:30:19 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA08456
Mon, 29 Oct 2001 22:34:20 -0500 (EST)
Subject: test
Date: Tue, 30 Oct 2001 11:42:39 +0800
MIME-Version: 1.0
Content-Type: text/plain;
charset="gb2312"
Message-ID: <286B56439214BD48A2F478D2AF1981A523B025@bjmis.marsec.net>
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Thread-Topic: test
Thread-Index: AcFg9OjTeYtxMUT/RhiwfdzkuxF5uw==
From: =?gb2312?B?WmhvdSBTdWppbmcg1twgy9W+siBbsbG+qV0=?= <sujing.zhou@marsec.net>
To: <ipsec@lists.tislabs.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id WAA08453
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
test
Öйú±±¾©Î÷³ÇÇø½ðÈÚ½Ö33ºÅ̩ͨ´óÏÃB×ù419
Marsec System Inc.
B419, Tong Tai Tower, No.33 Jin Rong St. Xi Cheng District, Beijing
100032,PR.China
Óʱࣺ100032
Tel£º£¨8610£©8808-7212 Ext. 3101
Fax£º£¨8610) 8808-7300
Email£ºsujing.zhou@marsec.net
From owner-ipsec@lists.tislabs.com Tue Oct 30 07:58:57 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UFwu827928;
Tue, 30 Oct 2001 07:58:56 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09777
Tue, 30 Oct 2001 09:56:14 -0500 (EST)
Message-ID: <3BDE061A.E3DB934B@cisco.com>
Date: Mon, 29 Oct 2001 20:44:58 -0500
From: Leo Temoshenko <leot@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Shriver, John" <john.shriver@intel.com>
CC: "'rks@cisco.com'" <rks@cisco.com>, Theodore Tso <tytso@mit.edu>,
Tim Jenkins <TJenkins@Catena.com>, bbruins@cisco.com,
bret_harrison@tivoli.com, Barbara Fraser <byfraser@cisco.com>,
cmadson@cisco.com, ipsec@lists.tislabs.com, pcn@cisco.com, leot@cisco.com
Subject: Re: Status of ID: IPsec Flow Monitoring MIB
References: <C703B434E680D511BDFD0002A50706960CCE25@hdsmsx101.hd.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
"Shriver, John" wrote:
>
> Comments inline...
>
> > -----Original Message-----
> > From: rks@cisco.com [mailto:rks@cisco.com]
> > Sent: Friday, October 26, 2001 2:23 PM
> > To: Theodore Tso
> > Cc: Tim Jenkins; bbruins@cisco.com; bret_harrison@tivoli.com; Barbara
> > Fraser; cmadson@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com;
> > pcn@cisco.com
> > Subject: Re: Status of ID: IPsec Flow Monitoring MIB
> >
> >
> > Hi -
> >
> > From: Theodore Tso <tytso@mit.edu>
> > Date: On Fri, 26 Oct 2001 14:23:03 -0400
> >
> > >Which leads us to the next question... assuming that there
> > >is only one attempt to implement the I-D's, what is the
> > >working group's feeling about advancing the documents?
> >
> >
> > I have looked through the IKE and IPsec monitoring MIBs
> > and I am a bit confused about the purpose of these "low level" MIBs.
> > Why were these defined and what problem are they meant to solve?
> > MIBs that dish out bits of the protocol merely because the bits
> > happen to be there, serve very little purpose (let's call
> > such MIBs "protocol MIBs").
>
> Well, there are IETF rules about protocols, progress along the standards
> path, and SNMP MIBs. No MIB, no Full Standard status. That's what got me
> initially interested.
So let's forward a useful MIB for the protocol.
>
> >
> > Why would an administrator use them instead of the command
> > line interface (I am not sure there is a device out there
> > that supports SNMP protocol but not management through
> > telnet)?
>
> Two reasons:
>
> Because you are using the MIB because you cannot establish an IPsec session
> with the managed system. If you can't establish an IPsec session, how are
> you going to establish a Telnet session that is secure enough to be allowed
> access to the CLI?
In contrast... Using the current "low level" MIBs , the problem event would
be so short that the MIB entry would gone before a query could be done.
>
> Because you need to automate troubleshooting, and you're not going to do
> that with a CLI management interface. These MIBs were designed according to
> criteria set out by people at BBN when we were courting them as a customer,
> to be able to troubleshoot a particular IPsec "session" WITHOUT having to do
> any table searching. That is what makes the indexing complicated. (BBN is
> famous for knowing how to manage a network.)
The Flow Monitor MIB has this capability. The "low level" MIBs do NOT.
>
> >
> > One answer to my last question could be the following:
> > Monitoring and troubleshooting are done in the context of
> > an application of IPsec (such as VPNs). Hence, if a problem
> > with the application is traced down to the underlying protocol
> > (IPsec), the ensuing troubleshooting would require the nuts and bolts
> > of the protocol. Hence, I'd argue that without a MIB that provides
> > abstractions on top of the protocol view (an "application MIB"),
> > the protocol MIB serves little purpose.
>
> I fully agree that application oriented MIBs on top of these MIBs are fully
> appropriate.
And should replace the "low level" MIBs which no one other than
an IPsec developer could understand.
>
> > There has not been any discussion on these MIBs, leave alone
> > a debate contrasting the two approaches (the Jenkins drafts and
> > the IPsec Flow Monitoring MIB, proposed by us).
>
> They have been presented at the IETF meeting, and few issues were raised.
> Those issues were addressed in revisions.
Really? I have tried to find the latest drafts of the "low level"
MIBs and only find references with "dead" links.
>
> We've had a lot of good review comments from various reviewers. I started
> as a reviewer, and progressed into co-authorship.
>
> There are admittedly some curious issues of managing a strong secure
> protocol like IPsec with the much more modestly secure protocol SNMPv3.
>
> I will admit that the drafts now have a bunch of redundant layering, since
> there may someday be a revision of IKE that "flattens out" the
> specifications. But we have put a lot of work into making them
> "well-formed" MIBs.
Right. Redundant is another word for "not useful".
>
> >
> > Hence, how can it be appropriate to take these drafts to the
> > final call?
> >
> > Rk
> > x77309
> >
> > ---
> > S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
> >
From owner-ipsec@lists.tislabs.com Tue Oct 30 08:01:33 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UG1X828887;
Tue, 30 Oct 2001 08:01:33 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09825
Tue, 30 Oct 2001 10:00:12 -0500 (EST)
Message-ID: <522FDAAFD532D511A0AB0002A51390EB2F7099@cat01s2.catena.com>
From: Tim Jenkins <TJenkins@Catena.com>
To: "'Leo Temoshenko'" <leot@cisco.com>
Cc: "'rks@cisco.com'" <rks@cisco.com>, byfraser@cisco.com, tytso@mit.edu,
bbruins@cisco.com, ipsec@lists.tislabs.com
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
Date: Tue, 30 Oct 2001 09:41:38 -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
> -----Original Message-----
> From: Leo Temoshenko [mailto:leot@cisco.com]
> Sent: Monday, October 29, 2001 8:59 PM
> To: Tim Jenkins
> Cc: 'rks@cisco.com'; byfraser@cisco.com; tytso@mit.edu;
> bbruins@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com
> Subject: Re: Status of ID: IPsec Flow Monitoring MIB
>
>
>
>
> Tim Jenkins wrote:
> >
> > > -----Original Message-----
> > > From: rks@cisco.com [mailto:rks@cisco.com]
> > > Sent: Sunday, October 28, 2001 6:17 PM
> > > To: Tim Jenkins
> > > Cc: byfraser@cisco.com; tytso@mit.edu; bbruins@cisco.com;
> > > ipsec@lists.tislabs.com; leot@cisco.com
> > > Subject: RE: Status of ID: IPsec Flow Monitoring MIB
> > >
> > >
...
>
> >
> > Since they are not application specific, and in their raw
> > form may not be what most implementors want, it is expected
> > that they will be used as the building blocks for application
> > specific MIBs. That is why I submitted the tunnel monitoring
> > MIB: as an example of how the base MIBs could be used as
> > the building block of an application specific MIB.
> >
>
> Too low level to be useful. Why would one want to implement
> "unuseful" MIBs in order implement useful MIB?
Because they provide building blocks, and a foundation if you will.
Further, they are not "unuseful". As I have repeatedly said, an
application specific MIB will be more useful to a customer. But
that does NOT mean that providing a single all-singing-all-dancing
MIB is the correct answer either.
See more below about why they are useful.
>
> > The status is that they have had minimal changes for the last
> > three revisions, and are ready for last call. We get next to
> > no comments on them now. (But we do know people are reading
> > them, since we get private questions on them.)
> >
>
> So why can't one find these revisions?? Where can one get
> a copy of these revised drafts? Since one cannot find them,
> how would/could one implement them?
If you couldn't find them, how can you read them and criticize them?
Further, I know there have been some implementations, because John
and I have received emails from implementors. Hopefully, they will
speak up.
Here are the links, found by searching with the internet-drafts site
<http://search.ietf.org/search/brokers/internet-drafts/query.html>
with the keyword "shriver":
<http://search.ietf.org/internet-drafts/draft-ietf-ipsec-doi-tc-mib-05.txt>
<http://search.ietf.org/internet-drafts/draft-ietf-ipsec-monitor-mib-05.txt>
<http://search.ietf.org/internet-drafts/draft-ietf-ipsec-ike-monitor-mib-03.
txt>
<http://search.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-0
4.txt>
...
> >
> > This version was very forcefully rejected by the working group
> > at the meeting in Orlando because it was application specific,
> > and did not separate the components out. That is why there exists
> > the series you see today that honours the separation of the IPsec
> > components as they exist today.
>
> So why are you objecting so strongly? That was then, this is now.
You keep saying that. What has changed? IPsec hasn't changed. And I
keep telling you why I object.
We still have IPsec SAs that can be created statically, using IKE or
any other key exchange protocol that you like. There is a MIB for them.
That MIB is still usable if you don't use IKE to create the SAs.
We still have ISAKMP, a framework for a key exchange protocol. There
is a MIB for that. That MIB is still usable if you build a different
key exchange protocol on top of ISAKMP.
We still have IKE, a key exchange protocol. There is a MIB for that.
Again, I agree there is a need for an application specific MIB. In
order to illustrate that, I submitted the tunnel MIB as an example.
The hope was that someone would be able to develop an application
specific MIB more quickly if there was an example available.
>
> >
> > Perhaps the working group has changed its mind. If it hasn't,
> > then I don't see how the Flow monitoring MIB can be advanced as
> > it is since it duplicates much of what is already done in the
> > collection of base MIBs.
>
> I beleive it has.
So, far the only voices I've heard that are suggesting that are
the authors of the flow monitoring MIB.
Could you provide some evidence that the working group wants
to promote a single MIB that cannot be used if a different key
exchange protocol is used to create IPsec SAs?
Could you provide some evidence that the working group wants
to promote an application specific MIB? (I actually agree with
this, but I believe it should be built on a solid foundation,
and not something that will have to be thrown away if one part
underneath it changes.)
From owner-ipsec@lists.tislabs.com Tue Oct 30 08:04:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UG4w829895;
Tue, 30 Oct 2001 08:04:58 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09817
Tue, 30 Oct 2001 09:58:15 -0500 (EST)
Message-ID: <3BDE095F.AE35B351@cisco.com>
Date: Mon, 29 Oct 2001 20:58:55 -0500
From: Leo Temoshenko <leot@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Jenkins <TJenkins@Catena.com>
CC: "'rks@cisco.com'" <rks@cisco.com>, byfraser@cisco.com, tytso@mit.edu,
bbruins@cisco.com, ipsec@lists.tislabs.com, leot@cisco.com
Subject: Re: Status of ID: IPsec Flow Monitoring MIB
References: <522FDAAFD532D511A0AB0002A51390EB2F7082@cat01s2.catena.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Tim Jenkins wrote:
>
> > -----Original Message-----
> > From: rks@cisco.com [mailto:rks@cisco.com]
> > Sent: Sunday, October 28, 2001 6:17 PM
> > To: Tim Jenkins
> > Cc: byfraser@cisco.com; tytso@mit.edu; bbruins@cisco.com;
> > ipsec@lists.tislabs.com; leot@cisco.com
> > Subject: RE: Status of ID: IPsec Flow Monitoring MIB
> >
> >
> > Hi -
> >
> > I do not understand your first objection below:
> > you are objecting to a draft because its not based
> > on another draft? What is the status of your draft?
> > Why should we base our proposal on it?
>
> Yes, I'm objecting that it's not based on the other drafts
> because the intent of those drafts was to be the MIBs
> produced by the working group to monitor the stuff that
> came out of the working group.
That was then. This is now.
>
> Since they are not application specific, and in their raw
> form may not be what most implementors want, it is expected
> that they will be used as the building blocks for application
> specific MIBs. That is why I submitted the tunnel monitoring
> MIB: as an example of how the base MIBs could be used as
> the building block of an application specific MIB.
>
Too low level to be useful. Why would one want to implement
"unuseful" MIBs in order implement useful MIB?
> The status is that they have had minimal changes for the last
> three revisions, and are ready for last call. We get next to
> no comments on them now. (But we do know people are reading
> them, since we get private questions on them.)
>
So why can't one find these revisions?? Where can one get
a copy of these revised drafts? Since one cannot find them,
how would/could one implement them?
> Why should you base yours on them? Well, if they become the
> standard MIBs for IPsec, then you'll likely have to implement
> them anyway, so it would make your application level MIB much
> smaller and easier to implement.
>
Big IF here. Which does not need comment.
> >
> > I looked through the textual conventions defined by you
> > and John Shriver <draft-ietf-ipsec-doi-tc-mib-05.txt>.
> > I find them comprehensive am willing to based our definitions
> > on them. That is the extent of layering I proposed below.
> >
> > > As a guide, I have submitted
> > <draft-jenkins-ipsec-tun-mon-mib-00.txt>
> > > as an illustration of how this can be done.
> >
> > Unfortunately, this would make it expensive for an
> > vendors of small IPsec devices to implement the MIB
> > we propose, although it details very useful abstractions
> > and correlations. I'd hate to see that happen.
>
> See what happen again?
>
> >
> > Like I said in my earlier mail, the IPsec Flow Monitor
> > MIB provides both the protocol view and an application view
> > and hence can be stand-alone.
> >
>
> Agreed it does.
>
> When I first started the MIBs, I proposed one that looked very
> similar to yours, in fact, it was similar to the tunnel MIB
> I submitted with alot of the IPsec stuff as well.
>
> This version was very forcefully rejected by the working group
> at the meeting in Orlando because it was application specific,
> and did not separate the components out. That is why there exists
> the series you see today that honours the separation of the IPsec
> components as they exist today.
So why are you objecting so strongly? That was then, this is now.
>
> Perhaps the working group has changed its mind. If it hasn't,
> then I don't see how the Flow monitoring MIB can be advanced as
> it is since it duplicates much of what is already done in the
> collection of base MIBs.
I beleive it has.
>
> > Thanks,
> >
> > Rk
> > x77309
> >
> >
> > On Wed, 10 Oct 2001, Tim Jenkins wrote:
> >
> >
> > > I have two main objections to this MIB document. They are:
> > > 1) It doesn't use the base IPsec MIBs.
> > > 2) It does things that are outside the scope of IPsec.
> >
> > > Below, there is agreement to using the base MIBs, so that
> > > deals with my first objection. As a guide, I have submitted
> > > <draft-jenkins-ipsec-tun-mon-mib-00.txt> as an illustration
> > > of how this can be done.
> >
> > > As far as I can see, the second objection has not been
> > > dealt with. While I believe that a number of these
> > > additional features are things that are user requested
> > > (such as IP address to domain name conversion; see objects
> > > ikeTunLocalName and ikeTunRemoteName as examples), it is my
> > > belief that they do not belong in an IPsec MIB. However,
> > > there are few of these, so it is likely this objection can
> > > be easily overcome.
> >
> > >
> > > > -----Original Message-----
> > > > From: rks@cisco.com [mailto:rks@cisco.com]
> > > > Sent: Tuesday, October 09, 2001 6:14 PM
> > > > To: byfraser@cisco.com; tytso@mit.edu
> > > > Cc: bbruins@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com
> > > > Subject: Status of ID: IPsec Flow Monitoring MIB
> > > >
> > > >
> > > >
> > > > We proposed the IPsec Flow Monitor MIB in 1999 to aid
> > > > IPsec monitoring applications designed to evaluate the
> > > > connectivity and performance and troubleshoot connectivity
> > > > failures. The MIB has evolved ever since based on comments
> > > > from early of VPN deployers. We would like to standardize
> > > > this MIB and want the WG chairs to advance the ID in the
> > > > standards track.
> > > >
> > > >
> > > > History:
> > > > The MIB was first defined because the MIBs available during
> > > > that time in the area were insufficient in providing the
> > > > abstractions that are desirable to make IPsec manageable.
> > > >
> > > > Tivoli Systems (a multi-vendor management company) refined
> > > > the MIB with Cisco Systems to make it a multi-vendor/standard
> > > > MIB for managing IPsec networks. After successful deployment in
> > > > the field, it was revised and the revision was submitted to
> > > > the WG early this year.
> > > >
> > > > The MIB has since been adopted by a few VPN service providers,
> > > > management vendors and users. Their comments were helpful in
> > > > further refining the MIB definition.
> > > >
> > > >
> > > > Highlights of the MIB:
> > > > Defining a MIB to merely export bits of the protocol serves no
> > > > management purpose. We defined the MIB with the
> > following features:
> > > >
> > > > 1. Build abstractions that may be used by the network
> > > > administrators
> > > > to identify traffic flows in IPsec networks. This
> > > > would allow the
> > > > correlation of the performance of the application
> > traffic with
> > > > that of the underlying IPsec networks.
> > > > 2. Help define SLAs to qualify the performance and failures.
> > > > 3. History and failure tables for trending and
> > troubleshooting.
> > > > 4. SA tables to aid low level troubleshooting.
> > > > 5. Separation of IKE and IPsec groups to allow later
> > > > extensions for
> > > > other keying protocols to be used with IPsec (such
> > as KINK).
> > > >
> > > > I'd very much like to hear comments on this from
> > administrators
> > > > or NMS developers who are facing the problem of monitoring
> > > > and troubleshooting IPsec-based VPNs.
> > > >
> > > >
> > > > Coexistence with other MIB drafts:
> > > > Our proposal may be regarded as being competing or
> > complementary to
> > > > the low level MIBs proposed by Jenkins et al. To that extent,
> > > > we are willing to layer our MIB on top of the basic definitions
> > > > provided by the Jenkins drafts.
> > > >
> > > > In 1999, it was proposed that we use the ISAKMP and
> > IPsec textual
> > > > conventions proposed by Jenkins drafts. This is quite feasible
> > > > since there is little difference between the TCs proposed by
> > > > the two drafts.
> > > >
> > > >
> > > > Please advise us on what we need to do in order to
> > advance this MIB
> > > > in the standards track.
> > > >
> > > > Thanks,
> > > >
> > > > Leo Temoshenko, Cisco Systems Inc.
> > > > Cheryl Madson, Cisco Systems Inc.
> > > > Chinna Pellacuru, Cisco Systems Inc.
> > > > Bret Harrison, Tivoli Systems Inc.
> > > > S Ramakrishnan, Cisco Systems Inc.
> >
> > ---
> > S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
> >
From owner-ipsec@lists.tislabs.com Tue Oct 30 08:07:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UG7S800874;
Tue, 30 Oct 2001 08:07:28 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09776
Tue, 30 Oct 2001 09:56:13 -0500 (EST)
Message-ID: <3BDE0345.3C1C756B@cisco.com>
Date: Mon, 29 Oct 2001 20:32:53 -0500
From: Leo Temoshenko <leot@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Jenkins <TJenkins@Catena.com>
CC: "'rks@cisco.com'" <rks@cisco.com>, Casey Carr <kcarr@nc.rr.com>,
Theodore Tso <tytso@mit.edu>, Barbara Fraser <byfraser@cisco.com>,
Barry Bruins <bbruins@cisco.com>, ipsec@lists.tislabs.com,
Cheryl Madson <cmadson@cisco.com>, Narasimha <pcn@cisco.com>,
leot@cisco.com
Subject: Re: Status of ID: IPsec Flow Monitoring MIB
References: <522FDAAFD532D511A0AB0002A51390EB2F7084@cat01s2.catena.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Tim Jenkins wrote:
>
> > Casey -
> >
> > On Fri, 26 Oct 2001, Casey Carr wrote:
> >
> > > Are there IETF alternative specifications for monitoring
> > > IPSec via SNMP? If not, what would the working group recommend
> > > for monitoring IPSec performance?
> >
> > There are indeed two competing drafts for IKE and IPsec
> > monitoring and there is an unfortunate similarity in
> > their names. The one submitted by Cisco and Tivoli Inc.
> > is...
>
> I beg to differ. The series submitted by John Shriver and me
> does not 'compete' with the flow monitoring MIB.
It sure appears to. Or why your comments to the Flow Monitoring
MIB bring in these drafts? If they don't complete, then why
the comment.
>
> The series John and I submitted defines the components of IPsec
> as developed by the working group and are application independent.
>
> If you use only some components of the work done in the IPsec WG,
> you only some of the MIBs.
This is really not possible. All the pieces are needed to
make a whole.
>
> The flow monitoring MIB is an application specific MIB which
> redefines the presentation of the components of IPsec in that
> single application specific MIB.
Application specific to most/all IPsec implementations.
>
> I think the working group really needs to ask:
>
> 1) Do the MIBs submitted by John and I represent the work developed
> by the working group?
Perhaps, but... From implementation experience, the Flow Monitoring
MIB has been found to be useful and implemented. The "other"
drafts are questionable at best.
>
> 2) Should the working group develop an application specific MIB for
> IPsec?
Absolutely. I would suggest abandoning the "low level" MIBs which
no one other than an IPsec implementor could understand. A dump of
memory may be as useful.
>
> If the answer to 2) is yes, then the obvious next question is:
>
> 3) Should any application specific MIB re-use the MIBs that represent
> the work done by the working group, or should it be a stand-alone
> MIB?
No. The MIBs should be stand-alone. Thus letting implementors
to pick and choose.
>
> Tim
>
> > -----Original Message-----
> > From: rks@cisco.com [mailto:rks@cisco.com]
> > Sent: Sunday, October 28, 2001 6:28 PM
> > To: Casey Carr
> > Cc: Theodore Tso; Barbara Fraser; Barry Bruins;
> > ipsec@lists.tislabs.com;
> > Cheryl Madson; Narasimha; leot@cisco.com
> > Subject: RE: Status of ID: IPsec Flow Monitoring MIB
> >
> >
From owner-ipsec@lists.tislabs.com Tue Oct 30 08:07:52 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UG7q801068;
Tue, 30 Oct 2001 08:07:52 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09818
Tue, 30 Oct 2001 09:58:16 -0500 (EST)
Message-ID: <3BDE21E3.41A0743A@sookmyung.ac.kr>
Date: Tue, 30 Oct 2001 12:43:31 +0900
From: Gwangsoo Rhee <rhee@sookmyung.ac.kr>
Reply-To: rhee@sookmyung.ac.kr
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: tsuruta@insi.co.jp
CC: ipsec@lists.tislabs.com
Subject: Re: IPSec SA's contents
References: <000501c1605b$66f1d620$8300a8c0@tsuruta>
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
SA in the first message can contain multiple proposals
as suggestions for IPsec SA. SA in the second message
is a single proposal selected by the responder.
Items in a proposal may include:
- protocol: ESP or AH
- Encr algo
- Auth algo
- Hash Algo
- encapsulation mode: tunnel or transport
- DH group #
- SA lifetime (in seconds and/or in KBs)
- etc.
I hope this helps.
Masafumi Tsuruta wrote:
> Hi.
>
> I have a question about IPSec SA. Please give me any suggestion if you don't
> worry.
>
> In Phase 2, Quickmode, according to RFC 2409 <5.5 Phase 2 - Quick Mode> an
> ascii art explains how works quickmode as below.
>
> -----------------------begin-----------------------------------
> Initiator | Responder
> HDR*, HASH (1), SA, Ni,
> [, KE] [, IDci, IDcr] -->
> <-- HDR*, HASH (2), SA, Nr
> [, KE] [, IDci, IDcr]
> HDR*, HASH (3) -->
> -----------------------end-------------------------------------
>
> In this figure, I can't understand what is in the "SA". Some components (ex.
> Nonce payload) are part from "SA", so I can't understand "SA" contents.
>
> Please tell me the contents of "SA". Thank you.
>
> Masafumi Tsuruta
> tsuruta@insi.co.jp
--
---------------------------------------
Gwangsoo Rhee <rhee@sookmyung.ac.kr>
tel: +82-2-710-9429 fax: 710-9296
HP: 011-9691-9541
---------------------------------------
From owner-ipsec@lists.tislabs.com Tue Oct 30 08:08:40 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UG8d801427;
Tue, 30 Oct 2001 08:08:39 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09778
Tue, 30 Oct 2001 09:56:14 -0500 (EST)
Date: Mon, 29 Oct 2001 12:49:22 -0700
From: Joel Snyder <Joel.Snyder@Opus1.COM>
Subject: Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
To: John Border <border@hns.com>
Cc: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>,
ipsec@lists.tislabs.com, narten@raleigh.ibm.com, nordmark@Eng.Sun.COM
Message-id: <3BDDB2C2.4C4C08B6@opus1.com>
Organization: Opus One
MIME-version: 1.0
X-Mailer: Mozilla 4.78C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <200110290135.UAA18324@bcn.East.Sun.COM> <3BDD713D.57B463A6@hns.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
There are two other reasons why putting compression in IKE is probably
preferable to doing it ad-hoc in protocols at the higher layer
(end-to-end argument notwithstanding):
1) VPN boxes typically have lots of spare cycles because they're heavily
overconfigured, and therefore the burden of compression is not as much
of an issue on them as it might be on end systems. Similarly, the VPN
boxes are often closer to the WAN side of the network where compression
is more of a win. In testing real compression implementations, it is
often not worth compressing on the LAN because the overhead of
compression is not compensated for by the savings in transmission.
(i.e., it goes slower when compressed sometimes) Ergo, the choice on
whether to compress or not is more topology/routing based than
end-system based.
2) IPSEC REALLY needs compression to avoid fragmentation---large packets
which can save 60 octets via compression don't have to be fragmented in
ESP. So whereas compression in general may or may not be useful in many
cases, in ESP it's a big win (for large packets) to save a few octets.
jms
--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
+1 520 324 0494 x101 (voice) +1 520 324 0495 (FAX)
jms@Opus1.COM http://www.opus1.com/jms Opus One
Electronic mail is always the best way to contact me.
John Border wrote:
>
> I have always assumed that the reason is based on advice I have often
> heard given by the Trasport ADs to Transport working groups... "Don't invent
> a new protocol if an existing protocol can be adapted to meet the
> requirements." If IKE was not used to negotiate IPcomp, then something else
> would have needed to be developed to do so.
>
> In addition (or maybe instead, see my disclaimer), there is a relationship
> between compression and encryption in that compression needs to occur first if
> both are to be used. Therefore, negotiating them at the same time seems more
> efficient in terms of the number of handshakes required.
>
> Disclaimer: I was not around when IPcomp was developed, so I do not know
> for a fact that this reasoning is correct. And, I am not sure to which
> working group mailing list to forward the question. I am pretty sure the work
> was done in the Internet Area because the Internet ADs are the ones who took
> an interest when I submitted an independent I-D for publication as an
> Informational RFC for a specific IPComp protocol (V.44)...
>
> John
>
> Radia Perlman - Boston Center for Networking wrote:
> >
> > I don't quite understand why IKE is negotiating IPcomp, and it clutters
> > up the IKE spec. Presumably IPcomp should exist outside of IPsec, as
> > in you might want to send a compressed packet even if it isn't
> > cryptographically protected. So presumably there's already some way
> > of negotiating compression algorithms, or at least there would have
> > to be in order to deploy IPcomp without IPsec. So would anyone object
> > to removing all mention of IPcomp from the IKE spec?
> >
> > If anyone likes IPcomp and wants it
> > to stay in IKE, perhaps they'd be willing to explain it to me? :-)
> >
> > Radia
From owner-ipsec@lists.tislabs.com Tue Oct 30 08:09:19 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UG9I801737;
Tue, 30 Oct 2001 08:09:19 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09816
Tue, 30 Oct 2001 09:58:14 -0500 (EST)
Message-ID: <3BDE079E.4BE70B5A@cisco.com>
Date: Mon, 29 Oct 2001 20:51:26 -0500
From: Leo Temoshenko <leot@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Jenkins <TJenkins@Catena.com>
CC: "'rks@cisco.com'" <rks@cisco.com>, Theodore Tso <tytso@mit.edu>,
bbruins@cisco.com, bret_harrison@tivoli.com,
Barbara Fraser <byfraser@cisco.com>, cmadson@cisco.com,
ipsec@lists.tislabs.com, pcn@cisco.com, leot@cisco.com
Subject: Re: Status of ID: IPsec Flow Monitoring MIB
References: <522FDAAFD532D511A0AB0002A51390EB2F7083@cat01s2.catena.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Tim Jenkins wrote:
>
> > -----Original Message-----
> > From: rks@cisco.com [mailto:rks@cisco.com]
> > Sent: Friday, October 26, 2001 2:23 PM
> > To: Theodore Tso
> > Cc: Tim Jenkins; bbruins@cisco.com; bret_harrison@tivoli.com; Barbara
> > Fraser; cmadson@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com;
> > pcn@cisco.com
> > Subject: Re: Status of ID: IPsec Flow Monitoring MIB
> >
> >
> > Hi -
> >
> > From: Theodore Tso <tytso@mit.edu>
> > Date: On Fri, 26 Oct 2001 14:23:03 -0400
> >
> > >Which leads us to the next question... assuming that there
> > >is only one attempt to implement the I-D's, what is the
> > >working group's feeling about advancing the documents?
> >
> >
> > I have looked through the IKE and IPsec monitoring MIBs
> > and I am a bit confused about the purpose of these "low level" MIBs.
> > Why were these defined and what problem are they meant to solve?
> > MIBs that dish out bits of the protocol merely because the bits
> > happen to be there, serve very little purpose (let's call
> > such MIBs "protocol MIBs").
>
> As I mentioned elsewhere, they are not application specifc because
> that is what the working group wanted, as was made clear in Orlando
> (yes, that long ago).
Right, but the need was there and in took awhile for it to
become clear.
>
> The split as is allows parts of them to be used if you use IPsec SAs
> with manual keying or some other key exchange protocol. It allows
> you to use the ISAKMP portion if you build a different key exchange
> protocol on top of ISAKMP.
The split makes no sense in current implementations. One cannot
do one without the other.
>
> This is what the working group wanted and I believe we have provided.
>
> Further, I believe, and I said this when the Flow monitoring MIB
> was first presented, that any application level MIB should use these
> base MIBs, rather than forcing a second presentation of the same
> information in another way.
We could should keep them independent and let the implementor choose.
>
> >
> > Why would an administrator use them instead of the command
> > line interface (I am not sure there is a device out there
> > that supports SNMP protocol but not management through
> > telnet)?
> >
> > One answer to my last question could be the following:
> > Monitoring and troubleshooting are done in the context of
> > an application of IPsec (such as VPNs). Hence, if a problem
> > with the application is traced down to the underlying protocol
> > (IPsec), the ensuing troubleshooting would require the nuts and bolts
> > of the protocol. Hence, I'd argue that without a MIB that provides
> > abstractions on top of the protocol view (an "application MIB"),
> > the protocol MIB serves little purpose.
> >
> > Its precisely for this reason that we (Tivoli Inc and Cisco)
> > drafted the IPsec Flow Monitoring MIB and proposed it to
> > IETF in Fall 1999. We were looking to building monitoring
> > and troubleshooting applications for IPsec-based VPNs. The MIBs
> > available in the WG at that time were too low level and hence
> > unsuitable for our purposes. The result of our work was a MIB
> > that provides both the views: it provides the abstractions of
> > IKE and IPsec Flows ("tunnels"), provides low level SA view of the
> > IPsec flows and correlates between the two views. I contend that
> > out proposal "IPsec Flow Monitoring MIB" can be stand alone
> > or can make use of some components defined by Jenkins et al.
> >
>
> Again, there is no doubt an application specific is valuable or
> needed. This is not an either-or case. My view is simply this:
> any application level MIB of IPsec should use the component MIBs,
> rather than re-defining the components. The flow monitoring MIB
> is an application level MIB, and it should define the application,
> not the components.
>
> > Finally, I'd like to hear comments from vendors (ISPs, VPN SPs, etc)
> > who are going to make use of these MIBs to provide VPN SLAs and other
> > goodies: please contrast the IPsec Monitoring MIB and the
> > "IPsec Flow Monitor MIB". Your comments from the trenches would be
> > invaluable to us in improving our proposal.
> >
> > There has not been any discussion on these MIBs, leave alone
> > a debate contrasting the two approaches (the Jenkins drafts and
> > the IPsec Flow Monitoring MIB, proposed by us).
> >
> > Hence, how can it be appropriate to take these drafts to the
> > final call?
>
> Because the components MIBs define the components as defined
> by the working group.
This is an unacceptable answer as new issue have arose.
>
> >
> > Rk
> > x77309
> >
> > ---
> > S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
> >
From owner-ipsec@lists.tislabs.com Tue Oct 30 08:50:28 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UGoR806372;
Tue, 30 Oct 2001 08:50:27 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10205
Tue, 30 Oct 2001 10:57:13 -0500 (EST)
Message-ID: <00b001c16159$4987ba60$0300a8c0@payampardaz>
From: "mahdavi" <mahdavi@sepahan.iut.ac.ir>
To: <ipsec@lists.tislabs.com>
Subject: CBC makes Implementations too Slow.
Date: Tue, 30 Oct 2001 18:54:03 +0330
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_002E_01C16174.3E8E5360"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_002E_01C16174.3E8E5360
Content-Type: text/plain;
charset="windows-1256"
Content-Transfer-Encoding: quoted-printable
Hi Sirs.=20
Hardware implementation of IPSEC is our activity.=20
now we face with a problem about CBC mode.=20
In software CBC makes no trouble for implementation but in hardware it =
is another story.=20
If CBC mode was not mandate, acheiving high speed cryptography was easy. =
for example for 3des every block needs 48 pulses to be encrypted. ( 16 =
round )
This leads us to a Pipeline that can generate one encrypted block per =
clock. but with CBC we can not reach to this speed. result of evry block =
has an effective role in making next block.=20
in another word feeding every block needs result of pervious block at =
first.=20
so our pipeline faces with terrible lack of efficiency.=20
now how can we face with this problem.=20
can any body shows us some guide lines?
sincerely yours=20
mahdavi
------=_NextPart_000_002E_01C16174.3E8E5360
Content-Type: text/html;
charset="windows-1256"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1256" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#fffbf0>
<DIV><FONT face=3DArial size=3D2>Hi Sirs. <BR>Hardware implementation of =
IPSEC is=20
our activity. <BR>now we face with a problem about CBC mode. =
</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>In software CBC makes no trouble for =
implementation=20
but in hardware it is another story. <BR>If CBC mode was not mandate, =
acheiving=20
high speed cryptography was easy. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>for example for 3des every block needs =
48 pulses to=20
be encrypted. ( 16 round )</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>This leads us to a Pipeline that can =
generate one=20
encrypted block per clock. but with CBC we can not reach to this speed. =
result=20
of evry block has an effective role in making next block. <BR>in another =
word=20
feeding every block needs result of pervious block at first. =
</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>so our pipeline faces with terrible =
lack of=20
efficiency. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>now how can we face with this problem.=20
</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>can any body shows us some guide=20
lines?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>sincerely yours=20
<BR>mahdavi</FONT></DIV></BODY></HTML>
------=_NextPart_000_002E_01C16174.3E8E5360--
From owner-ipsec@lists.tislabs.com Tue Oct 30 09:53:24 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UHrO809159;
Tue, 30 Oct 2001 09:53:24 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10300
Tue, 30 Oct 2001 11:42:10 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: "mahdavi" <mahdavi@sepahan.iut.ac.ir>
Cc: ipsec@lists.tislabs.com
Subject: Re: CBC makes Implementations too Slow.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 30 Oct 2001 11:51:01 -0500
Message-Id: <20011030165102.006DF7C03@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <00b001c16159$4987ba60$0300a8c0@payampardaz>, "mahdavi" writes:
>This is a multi-part message in MIME format.
>
>------=_NextPart_000_002E_01C16174.3E8E5360
>Content-Type: text/plain;
> charset="windows-1256"
>Content-Transfer-Encoding: quoted-printable
>
>Hi Sirs.=20
>Hardware implementation of IPSEC is our activity.=20
>now we face with a problem about CBC mode.=20
>
>In software CBC makes no trouble for implementation but in hardware it =
>is another story.=20
>If CBC mode was not mandate, acheiving high speed cryptography was easy. =
>
>
>for example for 3des every block needs 48 pulses to be encrypted. ( 16 =
>round )
>
>This leads us to a Pipeline that can generate one encrypted block per =
>clock. but with CBC we can not reach to this speed. result of evry block =
>has an effective role in making next block.=20
>in another word feeding every block needs result of pervious block at =
>first.=20
>
>so our pipeline faces with terrible lack of efficiency.=20
>
>now how can we face with this problem.=20
>
>can any body shows us some guide lines?
This complaint is common for all sorts of encryption, not just IPsec.
The Security Area has decided to wait for the forthcoming
recommendations from NIST for new modes of operation that are
specifically designed to address this problem.
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Tue Oct 30 12:24:49 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UKOn816997;
Tue, 30 Oct 2001 12:24:49 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10632
Tue, 30 Oct 2001 14:19:03 -0500 (EST)
Message-ID: <C703B434E680D511BDFD0002A507069602978DF9@hdsmsx101.hd.intel.com>
From: "Shriver, John" <john.shriver@intel.com>
To: "'Leo Temoshenko'" <leot@cisco.com>,
"Shriver, John" <john.shriver@intel.com>
Cc: "'rks@cisco.com'" <rks@cisco.com>, Theodore Tso <tytso@mit.edu>,
Tim Jenkins <TJenkins@Catena.com>, bbruins@cisco.com,
bret_harrison@tivoli.com, Barbara Fraser <byfraser@cisco.com>,
cmadson@cisco.com, ipsec@lists.tislabs.com, pcn@cisco.com
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
Date: Tue, 30 Oct 2001 11:28:41 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I think I need to remind the participants of this discussion of an important
point:
***** This is not the VPN working group. This is the IPsec working group.
*****
I think this has been emphasized MANY times by the chairs and area
directors. They will NOT budge on this issue.
The phrases "VPN" and "Virtual Private Network" do not appear in our
charter. Please re-read it:
http://www.ietf.org/html.charters/ipsec-charter.html
Our job is to develop useful MIBs for the "protocol" named IPsec. It
consists of ESP, AH, static keying, ISAKMP, and IKE.
I will not claim that the IPsec Monitoring MIBs are trivial to implement.
Nor is IPsec trivial to implement. Many complain that it is too
complicated, the MIBs make the complexity visible. Much of that complexity
is in the extreme flexibility of IPsec.
If you want to make the MIBs simpler, please propose which options to delete
from IPsec. (That is a relatively rhetorical question, I do NOT want to
drag THAT discussion into this discussion!)
You may validly pick on the monitoring MIBs in that we split ISAKMP and IKE,
and that the working group has since decided that said layering of
documentation and specification is no longer appropriate. Fine. It would
be a trivial change to the monitoring MIBs to merge the ISAKMP and IKE
documents into one MIB. For the most part, the tables in the IKE MIB merely
augment tables that already exist in the ISAKMP MIB, so it's just a matter
of stiching them into one table. It would also allow us to remove the
columns in the "ISAKMP" tables that say "this row is IKE".
But, as for layering IPsec (AH and ESP proper) separately from ISAKMP/IKE,
nobody has published a revision of RFC 2401 that makes ISAKMP/IKE mandatory
for IP Version 4.
I think that the MIBs do provide the lookup tables to examine the status of
one "phase 2 security association suite". I do not think that these are
generally so short-lived that an SNMP manager could not find it before it
was replaced with a new one (rekeying, I presume). (Maybe I'm wrong on
this, maybe the bandwidths are now so high that rekeying is done once a
minute.)
> And should replace the "low level" MIBs which no one other than
> an IPsec developer could understand.
The idea of SNMP was never that users would "understand" a MIB. I think
that the providers of SNMP management stations were supposed to provide the
"understanding". Unfortunately, a lot of them never got past MIB walkers
and pretty network maps that turn nodes red and green. This is partly
because the MIB syntax isn't really very descriptive, is weak on explaining
table relationships, etc. This also leads to people wanting to write flat
"application-specific" MIBs, because all the layering has to be described in
text, rather than as a formal part of the syntax.
I'm interested in knowing what particular parts of these monitoring MIBs
people think are really useless. I do know that there are places where only
one type of "identity" make any sense, yet we support any of the defined
ones, because ISAKMP/IKE does. So let's strike those, hopefully they will
also be striken in the "son of IKE" document.
I don't see that the Flow Monitoring MIB would be very useful for
"opportunistic IPsec" with transport mode.
Looking just at the IKE phase 1 area, you have two tables. One is
ikePeerTable, which is about concrete peer entity relationships. That's a
layer we don't have, and is a table I agree is useful. It is in turn
layered on ikeTunnelTable. That is quite equivalent to our saTable, in
particular the rows that show up in ikeSaTable. The contents of
ikeTunnelTable and ikeSaTable are quite comprable. The difference is that
you cannot do a meaningful direct lookup of ikeTunnelTable, since it is
indexed by a "meaningless" arbitrary index. The ikeSaTable is indexed by
the "real" fields of the ISAKMP/IKE negotiation that identify one Phase 1
connection.
It would be quite simple to expand ikePeerTable to have the full index data
to identify a real ISAKMP/IKE phase 1 tunnel (address types, addresses, and
cookies), and then replace ikeTunnelTable with a merged saTable/ikeSaTable.
I also note that ikeTunnelTable has even more statistics than ikeSaTable.
Nothing wrong with that. The more the merrier.
However, there is a visible strategy difference on how the two MIBs count
exchanges. ikeTunnelTable keeps some global counters of all exchanges, and
then has counters for each of the exchanges currently defined. This means
that the MIB will require revision every time a new exchange gets defined,
and will never reach Full Standard status. (I've been in that endless loop
on other MIBs, like the dot3 MIB.) We put in a table for counting
exchanges, exchangeTable, that is indexed by the same indices as ikeSaTable,
plus an additional index of the exchange type. (Think of it as another
dimension on ikeSaTable.) This means that we don't need to revise the MIB
when a new exchange type is assigned, the IANA edits the textual-convention
MIB, and the new rows magically exist.
I would also note that the Tunnel MIB doesn't conform to RFC 2581.
I will admit that our progress has been slow. Some of the drafts expired.
Neither of us are developing IPsec products for a living anymore, we
finished this project out of a dedication to the needs of this IETF working
group, and (slowly) living up to our committments thereto.
From owner-ipsec@lists.tislabs.com Tue Oct 30 12:59:54 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UKxs818068;
Tue, 30 Oct 2001 12:59:54 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10773
Tue, 30 Oct 2001 15:14:11 -0500 (EST)
From: rks@cisco.com
Date: Tue, 30 Oct 2001 12:21:11 -0800 (PST)
To: Tim Jenkins <TJenkins@Catena.com>
cc: <byfraser@cisco.com>, <tytso@mit.edu>, <bbruins@cisco.com>,
<ipsec@lists.tislabs.com>, <leot@cisco.com>
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
In-Reply-To: <522FDAAFD532D511A0AB0002A51390EB2F7082@cat01s2.catena.com>
Message-ID: <Pine.GSO.4.33.0110301156220.24597-100000@nm-vdm-build1.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi -
I hope I am addressing all your questions
and remarks in the following points:
1. NOT application-specific:
We are not proposing an "application-specific MIB".
This term is misleading and is biasing this
discussion. (I am gong to delete the term VPN from
the glossary of the MIB altogether).
I would henceforth use the terms "bit level MIB" and
"high level MIB" instead.
2. Judicious combination of two views needed:
We are proposing a MIB that provides a high level
abstraction of flows and correlations that is NOT
specific to any application of IPsec.
Simultaneously, we are also providing an SA level view
in such a way that the NMS may implement correlation
both ways (flows -> components nuts and bolts,
nuts and bolts -> flows).
Hence, we are seeking to judiciously combone
both monitoring and troubleshooting requirements.
3. Why your MIBs are unacceptable:
You have defined many layers of MIBs and now
you want to base the abstractions we porpose
on these layers.
This makes the cost of SNMP-manageability unacceptably high.
Vendors of small IPsec devices would clearly shy away
from providing management support (heck, big vendors
such as Cisco may partly shy away).
Let's have a quick show of hands on how many vendors
would implement layers of bit-level MIBs and then on top of
that implement the abstractions defined by us, merely so
as to provide SNMP manageability.
5. With regards to WG dictating MIB requirements:
You appear to suggest that WG wants a token MIB to
represent faithfully the protocol defined by them. I
would like to hear from the WG chair on this. I would
suggest that to WG make manageability its aim in defining
these MIBs.
Manageability is improved by abstracting details; if the WG
wants a to define a MIB to reveal the bits of the protocol,
they would make the task of managing the IPsec devices very
difficult and management applications very complex. Such a
MIB had better not be defined at all.
Thanks,
Rk
x77309
---
S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
On Mon, 29 Oct 2001, Tim Jenkins wrote:
> > -----Original Message-----
> > From: rks@cisco.com [mailto:rks@cisco.com]
> > Sent: Sunday, October 28, 2001 6:17 PM
> > To: Tim Jenkins
> > Cc: byfraser@cisco.com; tytso@mit.edu; bbruins@cisco.com;
> > ipsec@lists.tislabs.com; leot@cisco.com
> > Subject: RE: Status of ID: IPsec Flow Monitoring MIB
> >
> >
> > Hi -
> >
> > I do not understand your first objection below:
> > you are objecting to a draft because its not based
> > on another draft? What is the status of your draft?
> > Why should we base our proposal on it?
>
> Yes, I'm objecting that it's not based on the other drafts
> because the intent of those drafts was to be the MIBs
> produced by the working group to monitor the stuff that
> came out of the working group.
>
> Since they are not application specific, and in their raw
> form may not be what most implementors want, it is expected
> that they will be used as the building blocks for application
> specific MIBs. That is why I submitted the tunnel monitoring
> MIB: as an example of how the base MIBs could be used as
> the building block of an application specific MIB.
>
> The status is that they have had minimal changes for the last
> three revisions, and are ready for last call. We get next to
> no comments on them now. (But we do know people are reading
> them, since we get private questions on them.)
>
> Why should you base yours on them? Well, if they become the
> standard MIBs for IPsec, then you'll likely have to implement
> them anyway, so it would make your application level MIB much
> smaller and easier to implement.
>
> >
> > I looked through the textual conventions defined by you
> > and John Shriver <draft-ietf-ipsec-doi-tc-mib-05.txt>.
> > I find them comprehensive am willing to based our definitions
> > on them. That is the extent of layering I proposed below.
> >
> > > As a guide, I have submitted
> > <draft-jenkins-ipsec-tun-mon-mib-00.txt>
> > > as an illustration of how this can be done.
> >
> > Unfortunately, this would make it expensive for an
> > vendors of small IPsec devices to implement the MIB
> > we propose, although it details very useful abstractions
> > and correlations. I'd hate to see that happen.
>
> See what happen again?
>
> >
> > Like I said in my earlier mail, the IPsec Flow Monitor
> > MIB provides both the protocol view and an application view
> > and hence can be stand-alone.
> >
>
> Agreed it does.
>
> When I first started the MIBs, I proposed one that looked very
> similar to yours, in fact, it was similar to the tunnel MIB
> I submitted with alot of the IPsec stuff as well.
>
> This version was very forcefully rejected by the working group
> at the meeting in Orlando because it was application specific,
> and did not separate the components out. That is why there exists
> the series you see today that honours the separation of the IPsec
> components as they exist today.
>
> Perhaps the working group has changed its mind. If it hasn't,
> then I don't see how the Flow monitoring MIB can be advanced as
> it is since it duplicates much of what is already done in the
> collection of base MIBs.
>
> > Thanks,
> >
> > Rk
> > x77309
> >
> >
> > On Wed, 10 Oct 2001, Tim Jenkins wrote:
> >
> >
> > > I have two main objections to this MIB document. They are:
> > > 1) It doesn't use the base IPsec MIBs.
> > > 2) It does things that are outside the scope of IPsec.
> >
> > > Below, there is agreement to using the base MIBs, so that
> > > deals with my first objection. As a guide, I have submitted
> > > <draft-jenkins-ipsec-tun-mon-mib-00.txt> as an illustration
> > > of how this can be done.
> >
> > > As far as I can see, the second objection has not been
> > > dealt with. While I believe that a number of these
> > > additional features are things that are user requested
> > > (such as IP address to domain name conversion; see objects
> > > ikeTunLocalName and ikeTunRemoteName as examples), it is my
> > > belief that they do not belong in an IPsec MIB. However,
> > > there are few of these, so it is likely this objection can
> > > be easily overcome.
> >
> > >
> > > > -----Original Message-----
> > > > From: rks@cisco.com [mailto:rks@cisco.com]
> > > > Sent: Tuesday, October 09, 2001 6:14 PM
> > > > To: byfraser@cisco.com; tytso@mit.edu
> > > > Cc: bbruins@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com
> > > > Subject: Status of ID: IPsec Flow Monitoring MIB
> > > >
> > > >
> > > >
> > > > We proposed the IPsec Flow Monitor MIB in 1999 to aid
> > > > IPsec monitoring applications designed to evaluate the
> > > > connectivity and performance and troubleshoot connectivity
> > > > failures. The MIB has evolved ever since based on comments
> > > > from early of VPN deployers. We would like to standardize
> > > > this MIB and want the WG chairs to advance the ID in the
> > > > standards track.
> > > >
> > > >
> > > > History:
> > > > The MIB was first defined because the MIBs available during
> > > > that time in the area were insufficient in providing the
> > > > abstractions that are desirable to make IPsec manageable.
> > > >
> > > > Tivoli Systems (a multi-vendor management company) refined
> > > > the MIB with Cisco Systems to make it a multi-vendor/standard
> > > > MIB for managing IPsec networks. After successful deployment in
> > > > the field, it was revised and the revision was submitted to
> > > > the WG early this year.
> > > >
> > > > The MIB has since been adopted by a few VPN service providers,
> > > > management vendors and users. Their comments were helpful in
> > > > further refining the MIB definition.
> > > >
> > > >
> > > > Highlights of the MIB:
> > > > Defining a MIB to merely export bits of the protocol serves no
> > > > management purpose. We defined the MIB with the
> > following features:
> > > >
> > > > 1. Build abstractions that may be used by the network
> > > > administrators
> > > > to identify traffic flows in IPsec networks. This
> > > > would allow the
> > > > correlation of the performance of the application
> > traffic with
> > > > that of the underlying IPsec networks.
> > > > 2. Help define SLAs to qualify the performance and failures.
> > > > 3. History and failure tables for trending and
> > troubleshooting.
> > > > 4. SA tables to aid low level troubleshooting.
> > > > 5. Separation of IKE and IPsec groups to allow later
> > > > extensions for
> > > > other keying protocols to be used with IPsec (such
> > as KINK).
> > > >
> > > > I'd very much like to hear comments on this from
> > administrators
> > > > or NMS developers who are facing the problem of monitoring
> > > > and troubleshooting IPsec-based VPNs.
> > > >
> > > >
> > > > Coexistence with other MIB drafts:
> > > > Our proposal may be regarded as being competing or
> > complementary to
> > > > the low level MIBs proposed by Jenkins et al. To that extent,
> > > > we are willing to layer our MIB on top of the basic definitions
> > > > provided by the Jenkins drafts.
> > > >
> > > > In 1999, it was proposed that we use the ISAKMP and
> > IPsec textual
> > > > conventions proposed by Jenkins drafts. This is quite feasible
> > > > since there is little difference between the TCs proposed by
> > > > the two drafts.
> > > >
> > > >
> > > > Please advise us on what we need to do in order to
> > advance this MIB
> > > > in the standards track.
> > > >
> > > > Thanks,
> > > >
> > > > Leo Temoshenko, Cisco Systems Inc.
> > > > Cheryl Madson, Cisco Systems Inc.
> > > > Chinna Pellacuru, Cisco Systems Inc.
> > > > Bret Harrison, Tivoli Systems Inc.
> > > > S Ramakrishnan, Cisco Systems Inc.
> >
> > ---
> > S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
From owner-ipsec@lists.tislabs.com Tue Oct 30 14:14:56 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UMEt819944;
Tue, 30 Oct 2001 14:14:55 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10885
Tue, 30 Oct 2001 16:20:58 -0500 (EST)
Message-ID: <5BFDB1D553A1D411A48200508BB0F6ECB5EEF8@k2>
From: Hien Nguyen <hnguyen@watercove.com>
To: "'henry@campio.com'" <henry@campio.com>
Cc: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: ipsec configuration mib
Date: Tue, 30 Oct 2001 10:46:56 -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
Hi Henry,
I am also looking for a copy of the IPSec Configuration MIB. If you have
any, would you please share it with me?
Thanks!
Hien
Hien Nguyen (978) 608-2136
Fax (978) 256-9852
hnguyen@watercove.com
From owner-ipsec@lists.tislabs.com Tue Oct 30 14:15:38 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UMFb819970;
Tue, 30 Oct 2001 14:15:37 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10886
Tue, 30 Oct 2001 16:21:03 -0500 (EST)
Message-Id: <200110302032.f9UKWFA05266@hygro.adsl.duke.edu>
To: Joel Snyder <Joel.Snyder@Opus1.COM>
cc: John Border <border@hns.com>,
Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>,
ipsec@lists.tislabs.com, nordmark@Eng.Sun.COM,
Avram Shacham <shacham@shacham.net>
Subject: Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
In-Reply-To: Message from Joel Snyder <Joel.Snyder@Opus1.COM>
of "Mon, 29 Oct 2001 12:49:22 MST." <3BDDB2C2.4C4C08B6@opus1.com>
Date: Tue, 30 Oct 2001 15:32:13 -0500
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The need for IPComp (RFC 3173) came from IPsec originally. There were
folks who argued they could not deploy IPsec for remote access unless
it had some pre-IPsec compression. Existing remote access traffic was
compressible, IPsec would make such compression ineffective. Customers
would (presumably) find that unacceptable.
To just use IKE was sort of the obvious thing to do. No one really
thought IPComp would be used except with IPsec.
The old mailing list still lives, at ippcp@cisco.com.
Thomas
From: Joel Snyder <Joel.Snyder@Opus1.COM>
To: John Border <border@hns.com>
Cc: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>,
ipsec@lists.tislabs.com, narten@raleigh.ibm.com, nordmark@Eng.Sun.COM
Date: Mon, 29 Oct 2001 12:49:22 -0700
Subject: Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
There are two other reasons why putting compression in IKE is probably
preferable to doing it ad-hoc in protocols at the higher layer
(end-to-end argument notwithstanding):
1) VPN boxes typically have lots of spare cycles because they're heavily
overconfigured, and therefore the burden of compression is not as much
of an issue on them as it might be on end systems. Similarly, the VPN
boxes are often closer to the WAN side of the network where compression
is more of a win. In testing real compression implementations, it is
often not worth compressing on the LAN because the overhead of
compression is not compensated for by the savings in transmission.
(i.e., it goes slower when compressed sometimes) Ergo, the choice on
whether to compress or not is more topology/routing based than
end-system based.
2) IPSEC REALLY needs compression to avoid fragmentation---large packets
which can save 60 octets via compression don't have to be fragmented in
ESP. So whereas compression in general may or may not be useful in many
cases, in ESP it's a big win (for large packets) to save a few octets.
jms
--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
+1 520 324 0494 x101 (voice) +1 520 324 0495 (FAX)
jms@Opus1.COM http://www.opus1.com/jms Opus One
Electronic mail is always the best way to contact me.
John Border wrote:
>
> I have always assumed that the reason is based on advice I have often
> heard given by the Trasport ADs to Transport working groups... "Don't invent
> a new protocol if an existing protocol can be adapted to meet the
> requirements." If IKE was not used to negotiate IPcomp, then something else
> would have needed to be developed to do so.
>
> In addition (or maybe instead, see my disclaimer), there is a relationship
> between compression and encryption in that compression needs to occur first if
> both are to be used. Therefore, negotiating them at the same time seems more
> efficient in terms of the number of handshakes required.
>
> Disclaimer: I was not around when IPcomp was developed, so I do not know
> for a fact that this reasoning is correct. And, I am not sure to which
> working group mailing list to forward the question. I am pretty sure the work
> was done in the Internet Area because the Internet ADs are the ones who took
> an interest when I submitted an independent I-D for publication as an
> Informational RFC for a specific IPComp protocol (V.44)...
>
> John
>
> Radia Perlman - Boston Center for Networking wrote:
> >
> > I don't quite understand why IKE is negotiating IPcomp, and it clutters
> > up the IKE spec. Presumably IPcomp should exist outside of IPsec, as
> > in you might want to send a compressed packet even if it isn't
> > cryptographically protected. So presumably there's already some way
> > of negotiating compression algorithms, or at least there would have
> > to be in order to deploy IPcomp without IPsec. So would anyone object
> > to removing all mention of IPcomp from the IKE spec?
> >
> > If anyone likes IPcomp and wants it
> > to stay in IKE, perhaps they'd be willing to explain it to me? :-)
> >
> > Radia
From owner-ipsec@lists.tislabs.com Tue Oct 30 14:41:09 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UMf8820538;
Tue, 30 Oct 2001 14:41:08 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11064
Tue, 30 Oct 2001 16:56:18 -0500 (EST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05101015b804d4112718@[165.227.249.20]>
Date: Tue, 30 Oct 2001 14:05:05 -0800
To: ipsec@lists.tislabs.com
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: NAT traversal documents: are we close to done?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Greetings again. The past few weeks have seen new drafts for the two
main NAT traversal documents, draft-ietf-ipsec-nat-t-ike-01.txt
(Negotiation of NAT-Traversal in the IKE and
draft-ietf-ipsec-udp-encaps-01.txt (UDP Encapsulation of IPsec
Packets). Are there any outstanding issues on them? Might we have
these finished soon?
--Paul Hoffman, Director
--VPN Consortium
From owner-ipsec@lists.tislabs.com Tue Oct 30 15:23:26 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UNNP821406;
Tue, 30 Oct 2001 15:23:25 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11140
Tue, 30 Oct 2001 17:38:20 -0500 (EST)
Message-ID: <3BDF2ED2.565F0733@redcreek.com>
Date: Tue, 30 Oct 2001 14:50:58 -0800
From: Ricky Charlet <rcharlet@redcreek.com>
Organization: Redcreek Communications
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Hien Nguyen <hnguyen@watercove.com>
CC: "'henry@campio.com'" <henry@campio.com>,
"'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>
Subject: Re: ipsec configuration mib
References: <5BFDB1D553A1D411A48200508BB0F6ECB5EEF8@k2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hien Nguyen wrote:
>
> Hi Henry,
>
> I am also looking for a copy of the IPSec Configuration MIB. If you have
> any, would you please share it with me?
>
> Thanks!
> Hien
>
> Hien Nguyen (978) 608-2136
> Fax (978) 256-9852
> hnguyen@watercove.com
Howdy,
Certianly. The draft is available at the ietf website.
http://www.ietf.org/internet-drafts/draft-ietf-ipsp-ipsec-conf-mib-01.txt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin
Ricky Charlet : Redcreek Communications : usa (510) 497-2103
From owner-ipsec@lists.tislabs.com Tue Oct 30 17:47:58 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9V1lv824405;
Tue, 30 Oct 2001 17:47:57 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11421
Tue, 30 Oct 2001 19:47:04 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: "Khaja E. Ahmed" <khaja.ahmed@cavium.com>
Cc: "mahdavi" <mahdavi@sepahan.iut.ac.ir>, ipsec@lists.tislabs.com
Subject: Re: CBC makes Implementations too Slow.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 30 Oct 2001 19:55:33 -0500
Message-Id: <20011031005533.B51867C01@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <GCEGKDEGCPFGJNGILFIPMEJHCHAA.khaja.ahmed@cavium.com>, "Khaja E. Ahm
ed" writes:
>Steve,
>
>I am not sure I understand why this (3DES CBC in silicon) is considered a
>problem and in what types of applications and devices? Is the problem cost?
>I am not sure that there would be much benefit in waiting for other modes to
>emerge given how cheap and fast silicon is getting.
>
>There are cheaper and faster crypto accelerators available today than ever
>before. Currently shipping chips deliver, 600 mbps throughput on a single
>stream of 3DES IPsec traffic. There are also chips that use multiple cores
>to do 2.4 gbps. We (Cavium) and others have announced even faster chips. We
>expect to deliver chips in Jan that will do 2 gbps in each core. Given the
>multi core architecture of these chips, they can handle as much 3DES CBC
>IPSec (or SSL/TLS) traffic as the PCI, PCIX and LDT buses can handle. Mid
>2002 versions will handle at line rate (OC48 and OC192) IPsec and SSL/TLS
>traffic not only 3DES CBC but also AES and arc4. Is this not sufficient?
I'm not a hardware person; all I can do is listen when hardware folk
tell me that they can or cannot do certain things. CBC mode requires
feedback, which makes it impossible to pipeline encryptions; you can't
encrypt plaintext block P[n+1] until you have the ciphertext from
encrypting P[n]. That in turn makes me wonder how multiple cores help
you, unless it's to let you encrypt two different packets
simultaneously, for a high aggregate throughput rate.
Anyway -- enough people complained to NIST that they decided that a new
mode was necessary. I'm not completely convinced, and I don't think
that most of the proposed new modes (especially counter mode) will
really do the job. Specifically, it does no good to encrypt at such
rates if you can't authenticate at such rates, too. (Matt Blaze and I
wrote a short paper on our concerns for any new modes of operation; see
http://www.research.att.com/~smb/papers/internet-modes.ps or
http://www.research.att.com/~smb/papers/internet-modes.pdf .)
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Tue Oct 30 19:05:36 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9V35Z826628;
Tue, 30 Oct 2001 19:05:36 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11650
Tue, 30 Oct 2001 21:29:13 -0500 (EST)
From: rks@cisco.com
Date: Tue, 30 Oct 2001 18:37:35 -0800 (PST)
To: "Scott G. Kelly" <skelly@redcreek.com>
cc: Theodore Tso <tytso@mit.edu>, Tim Jenkins <TJenkins@Catena.com>,
<bbruins@cisco.com>, <bret_harrison@tivoli.com>,
Barbara Fraser <byfraser@cisco.com>, <cmadson@cisco.com>,
<ipsec@lists.tislabs.com>, <leot@cisco.com>, <pcn@cisco.com>
Subject: Re: Status of ID: IPsec Flow Monitoring MIB
In-Reply-To: <3BDDFE00.24788C0B@redcreek.com>
Message-ID: <Pine.GSO.4.33.0110301832070.27487-100000@nm-vdm-build1.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Mon, 29 Oct 2001, Scott G. Kelly wrote:
> rks@cisco.com wrote:
> >
> > Hi -
> >
> > From: Theodore Tso <tytso@mit.edu>
> > Date: On Fri, 26 Oct 2001 14:23:03 -0400
> >
> > Why would an administrator use them instead of the command
> > line interface (I am not sure there is a device out there
> > that supports SNMP protocol but not management through
> > telnet)?
>
> RedCreek devices support SNMP, but not telnet-based device management.
If you are using SNMP as a replacement for
telnet, I can understand why you'd want these
MIBs. VPN service providers looking to build
SLAs and trend monitoring tools are looking
for manageability that cannot be provided by
these MIBs.
Frankly, I find it strange that you provide no
console access but do support SNMP.
Rk
x77309
---
S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
From owner-ipsec@lists.tislabs.com Tue Oct 30 19:05:48 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9V35l826644;
Tue, 30 Oct 2001 19:05:47 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA11612
Tue, 30 Oct 2001 21:18:57 -0500 (EST)
From: rks@cisco.com
Date: Tue, 30 Oct 2001 18:27:20 -0800 (PST)
To: "Shriver, John" <john.shriver@intel.com>
cc: "'Leo Temoshenko'" <leot@cisco.com>, Theodore Tso <tytso@mit.edu>,
Tim Jenkins <TJenkins@Catena.com>, <bbruins@cisco.com>,
<bret_harrison@tivoli.com>, Barbara Fraser <byfraser@cisco.com>,
<cmadson@cisco.com>, <ipsec@lists.tislabs.com>, <pcn@cisco.com>
Subject: RE: Status of ID: IPsec Flow Monitoring MIB
In-Reply-To: <C703B434E680D511BDFD0002A507069602978DF9@hdsmsx101.hd.intel.com>
Message-ID: <Pine.GSO.4.33.0110301825320.27487-100000@nm-vdm-build1.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi -
From: "Shriver, John" <john.shriver@intel.com>
Date: Tue, 30 Oct 2001 11:28:41 -0800
>***** This is not the VPN working group.
> This is the IPsec working group.
>*****
Good. We are on the same page.
>Our job is to develop useful MIBs for the "protocol" named IPsec.
>It consists of ESP, AH, static keying, ISAKMP, and IKE.
Whether its "useful" depends on what requirements you
you are seeking to address by the design. Exactly what are they?
Or did the IPsec WG say "Gee, we designed a protocol and
now lets have a MIB to go with it"?
>You may validly pick on the monitoring MIBs in that [...]
Specific objections:
1. you have too many layers of MIBs and makes the implementation
of SNMP manageability expensive
2. you acknowledge further that abstractions and correlations
(such as those defined by us) are needed on top of these
bit-level MIBs, adding more cost to the implementation.
3. the structures you define are too ephemeral to be of much
value. Flows are steady; your "suites" change with every
QM. An NMS that wants to monitor the summary status of
traffic flows would have to juggle multiple suites. Such
applications would be complex.
Now to your criticisms:
(a)
>But, as for layering IPsec (AH and ESP proper) separately from
>ISAKMP/IKE, nobody has published a revision of RFC 2401 that
>makes ISAKMP/IKE mandatory for IP Version 4.
This is a valid point and we plan to fix this in a more general
way than you have. Your dedicating a whole MIB to a specific
keying protocol is problematic (but that's a different discussion).
(b)
>The idea of SNMP was never that users would "understand" a MIB.
I couldn't disagree more. A well-defined MIB for a technology
would summarily reflect the working of the technology, just as
a database schema for an application reflects the essence of
the application.
If you can't understand the essence of a technology modelled by
the MIB designed for the technology, please blame the MIB designer.
(Btw, users of managed entities often times inspect the
conformance clauses in the supported MIBs - for obvious
reasons.)
(c)
>I don't see that the Flow Monitoring MIB would be very useful
>for "opportunistic IPsec" with transport mode.
Please elaborate. I do not see how the Flow Monitoring MIB
would fail with opportunistic encryption.
I am disregarding your comparison of the details because
we have a basic problem with your proposals: I believe that
the MIB should judiciously combine abstractions with low
level details while at the same time providing back and forth
correlations between the two views.
Your proposal is lopsided with too many details and no
abstractions; this makes management complex.
Thanks,
Rk
x77309
---
S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
From owner-ipsec@lists.tislabs.com Tue Oct 30 20:30:23 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9V4UM828569;
Tue, 30 Oct 2001 20:30:22 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11769
Tue, 30 Oct 2001 22:38:54 -0500 (EST)
From: ji@research.att.com
Date: Tue, 30 Oct 2001 22:44:59 -0500 (EST)
Message-Id: <200110310344.WAA09869@bual.research.att.com>
To: khaja.ahmed@cavium.com, smb@research.att.com
Cc: ipsec@lists.tislabs.com, mahdavi@sepahan.iut.ac.ir
Subject: Re: CBC makes Implementations too Slow.
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Maybe I'm missing something, but packets are sent in a bit-serial manner
in almost all cases; you can be encrypting block n+1 while you are
transmitting the (already encrypted) block n. Since you have to transmit
some headers in the clear, you can start encryption of the payload at the
same time as the cleartext headers are being transmitted; so long as
you can encrypt at line speeds, you keep the pipelines full. Isn't that
what we want?
/ji
--
/\ ASCII ribbon | John "JI" Ioannidis * Secure Systems Research Department
\/ campaign | AT&T Labs - Research * Florham Park, NJ 07932 * USA
/\ against | "Intellectuals trying to out-intellectual
/ \ HTML email. | other intellectuals" (Fritz the Cat)
From owner-ipsec@lists.tislabs.com Tue Oct 30 21:33:11 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9V5XA829756;
Tue, 30 Oct 2001 21:33:11 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA11889
Tue, 30 Oct 2001 23:45:29 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
x-receiver: m.gratton@adga.ca
Content-Transfer-Encoding: 7bit
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
From: <ji@research.att.com>
Date: Tue, 30 Oct 2001 22:44:59 -0500 (EST)
Message-ID: <200110310344.WAA09869@bual.research.att.com>
To: <khaja.ahmed@cavium.com>, <smb@research.att.com>
Cc: <ipsec@lists.tislabs.com>, <mahdavi@sepahan.iut.ac.ir>
Subject: Re: CBC makes Implementations too Slow.
X-OriginalArrivalTime: 31 Oct 2001 04:49:21.0046 (UTC) FILETIME=[67C56360:01C161C7]
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Maybe I'm missing something, but packets are sent in a bit-serial manner
in almost all cases; you can be encrypting block n+1 while you are
transmitting the (already encrypted) block n. Since you have to transmit
some headers in the clear, you can start encryption of the payload at the
same time as the cleartext headers are being transmitted; so long as
you can encrypt at line speeds, you keep the pipelines full. Isn't that
what we want?
/ji
--
/\ ASCII ribbon | John "JI" Ioannidis * Secure Systems Research Department
\/ campaign | AT&T Labs - Research * Florham Park, NJ 07932 * USA
/\ against | "Intellectuals trying to out-intellectual
/ \ HTML email. | other intellectuals" (Fritz the Cat)
From owner-ipsec@lists.tislabs.com Wed Oct 31 06:35:29 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VEZS819968;
Wed, 31 Oct 2001 06:35:28 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA12580
Wed, 31 Oct 2001 08:37:09 -0500 (EST)
From: "Joseph D. Harwood" <jharwood@vesta-corp.com>
To: <ji@research.att.com>, <khaja.ahmed@cavium.com>, <smb@research.att.com>
Cc: <ipsec@lists.tislabs.com>, <mahdavi@sepahan.iut.ac.ir>
Subject: RE: CBC makes Implementations too Slow.
Date: Wed, 31 Oct 2001 05:46:46 -0800
Message-ID: <000001c16212$7b522940$c7d0fea9@vesta>
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 V5.50.4133.2400
In-Reply-To: <200110310344.WAA09869@bual.research.att.com>
Importance: Normal
X-Loop-Detect: 1
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
If a single engine can't run fast enough to encrypt at line speed, one
possible solution is to put two engines on chip and have them work on
different blocks of the same packet in parallel. However, this isn't
possible in CBC mode because you can't start encrypting block n+1 until
you've finished with block n.
Best Regards,
Joseph D. Harwood
(408) 838-9434
jharwood@vesta-corp.com
www.vesta-corp.com
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ji@research.att.com
> Sent: Tuesday, October 30, 2001 7:45 PM
> To: khaja.ahmed@cavium.com; smb@research.att.com
> Cc: ipsec@lists.tislabs.com; mahdavi@sepahan.iut.ac.ir
> Subject: Re: CBC makes Implementations too Slow.
>
>
> Maybe I'm missing something, but packets are sent in a bit-serial manner
> in almost all cases; you can be encrypting block n+1 while you are
> transmitting the (already encrypted) block n. Since you have to transmit
> some headers in the clear, you can start encryption of the payload at the
> same time as the cleartext headers are being transmitted; so long as
> you can encrypt at line speeds, you keep the pipelines full. Isn't that
> what we want?
>
> /ji
>
> --
> /\ ASCII ribbon | John "JI" Ioannidis * Secure Systems
> Research Department
> \/ campaign | AT&T Labs - Research * Florham Park, NJ 07932 * USA
> /\ against | "Intellectuals trying to out-intellectual
> / \ HTML email. | other intellectuals" (Fritz the Cat)
>
>
From owner-ipsec@lists.tislabs.com Wed Oct 31 07:23:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VFNh823641;
Wed, 31 Oct 2001 07:23:43 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12621
Wed, 31 Oct 2001 09:33:32 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010400b805bb285388@[128.89.88.34]>
In-Reply-To: <20011031005533.B51867C01@berkshire.research.att.com>
References: <20011031005533.B51867C01@berkshire.research.att.com>
Date: Wed, 31 Oct 2001 09:31:14 -0500
To: "Steven M. Bellovin" <smb@research.att.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: CBC makes Implementations too Slow.
Cc: "Khaja E. Ahmed" <khaja.ahmed@cavium.com>,
"mahdavi" <mahdavi@sepahan.iut.ac.ir>, ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 7:55 PM -0500 10/30/01, Steven M. Bellovin wrote:
>In message <GCEGKDEGCPFGJNGILFIPMEJHCHAA.khaja.ahmed@cavium.com>,
>"Khaja E. Ahm
>ed" writes:
>>Steve,
>>
>>I am not sure I understand why this (3DES CBC in silicon) is considered a
>>problem and in what types of applications and devices? Is the problem cost?
>>I am not sure that there would be much benefit in waiting for other modes to
>>emerge given how cheap and fast silicon is getting.
>>
>>There are cheaper and faster crypto accelerators available today than ever
>>before. Currently shipping chips deliver, 600 mbps throughput on a single
>>stream of 3DES IPsec traffic. There are also chips that use multiple cores
>>to do 2.4 gbps. We (Cavium) and others have announced even faster chips. We
>>expect to deliver chips in Jan that will do 2 gbps in each core. Given the
>>multi core architecture of these chips, they can handle as much 3DES CBC
>>IPSec (or SSL/TLS) traffic as the PCI, PCIX and LDT buses can handle. Mid
>>2002 versions will handle at line rate (OC48 and OC192) IPsec and SSL/TLS
>>traffic not only 3DES CBC but also AES and arc4. Is this not sufficient?
>
>I'm not a hardware person; all I can do is listen when hardware folk
>tell me that they can or cannot do certain things. CBC mode requires
>feedback, which makes it impossible to pipeline encryptions; you can't
>encrypt plaintext block P[n+1] until you have the ciphertext from
>encrypting P[n]. That in turn makes me wonder how multiple cores help
>you, unless it's to let you encrypt two different packets
>simultaneously, for a high aggregate throughput rate.
Steve,
I think Khaja's comments indicate that the Cavium chips cam support a
single SA at up to 600 Mb/s and multiple cores allow an aggregate
throughout of 2.4 Gb/s, e.g., if one has traffic for multiple SAs,
since each SA can be independently encrypted.
Steve
From owner-ipsec@lists.tislabs.com Wed Oct 31 07:31:41 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VFVe824037;
Wed, 31 Oct 2001 07:31:41 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12649
Wed, 31 Oct 2001 09:45:19 -0500 (EST)
From: "Khaja E. Ahmed" <khaja.ahmed@cavium.com>
To: "Steven M. Bellovin" <smb@research.att.com>,
"mahdavi" <mahdavi@sepahan.iut.ac.ir>
Cc: <ipsec@lists.tislabs.com>
Subject: RE: CBC makes Implementations too Slow.
Date: Tue, 30 Oct 2001 16:44:57 -0800
Message-ID: <GCEGKDEGCPFGJNGILFIPMEJHCHAA.khaja.ahmed@cavium.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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <20011030165102.006DF7C03@berkshire.research.att.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Steve,
I am not sure I understand why this (3DES CBC in silicon) is considered a
problem and in what types of applications and devices? Is the problem cost?
I am not sure that there would be much benefit in waiting for other modes to
emerge given how cheap and fast silicon is getting.
There are cheaper and faster crypto accelerators available today than ever
before. Currently shipping chips deliver, 600 mbps throughput on a single
stream of 3DES IPsec traffic. There are also chips that use multiple cores
to do 2.4 gbps. We (Cavium) and others have announced even faster chips. We
expect to deliver chips in Jan that will do 2 gbps in each core. Given the
multi core architecture of these chips, they can handle as much 3DES CBC
IPSec (or SSL/TLS) traffic as the PCI, PCIX and LDT buses can handle. Mid
2002 versions will handle at line rate (OC48 and OC192) IPsec and SSL/TLS
traffic not only 3DES CBC but also AES and arc4. Is this not sufficient?
Khaja
===============================
Cavium Networks, Inc.
2880 Zanker Rd, Suite 102
San Jose, CA 95134
Khaja E. Ahmed
VP Software Engineering
(408) 570-0911 Ext 13
(925) 462-0453 Home office
(925) 989-6564 Cell Phone
khaja.ahmed@cavium.com
http://www.cavium.com/
================================
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Steven M. Bellovin
> Sent: Tuesday, October 30, 2001 8:51 AM
> To: mahdavi
> Cc: ipsec@lists.tislabs.com
> Subject: Re: CBC makes Implementations too Slow.
>
>
> In message <00b001c16159$4987ba60$0300a8c0@payampardaz>, "mahdavi" writes:
> >This is a multi-part message in MIME format.
> >
> >------=_NextPart_000_002E_01C16174.3E8E5360
> >Content-Type: text/plain;
> > charset="windows-1256"
> >Content-Transfer-Encoding: quoted-printable
> >
> >Hi Sirs.=20
> >Hardware implementation of IPSEC is our activity.=20
> >now we face with a problem about CBC mode.=20
> >
> >In software CBC makes no trouble for implementation but in hardware it =
> >is another story.=20
> >If CBC mode was not mandate, acheiving high speed cryptography
> was easy. =
> >
> >
> >for example for 3des every block needs 48 pulses to be encrypted. ( 16 =
> >round )
> >
> >This leads us to a Pipeline that can generate one encrypted block per =
> >clock. but with CBC we can not reach to this speed. result of
> evry block =
> >has an effective role in making next block.=20
> >in another word feeding every block needs result of pervious block at =
> >first.=20
> >
> >so our pipeline faces with terrible lack of efficiency.=20
> >
> >now how can we face with this problem.=20
> >
> >can any body shows us some guide lines?
>
> This complaint is common for all sorts of encryption, not just IPsec.
> The Security Area has decided to wait for the forthcoming
> recommendations from NIST for new modes of operation that are
> specifically designed to address this problem.
>
> --Steve Bellovin, http://www.research.att.com/~smb
> Full text of "Firewalls" book now at
http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Wed Oct 31 07:34:36 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VFYa824179;
Wed, 31 Oct 2001 07:34:36 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12661
Wed, 31 Oct 2001 09:46:20 -0500 (EST)
To: ipsec@lists.tislabs.com
Subject: Re: NAT traversal documents: are we close to done?
References: <p05101015b804d4112718@[165.227.249.20]>
Organization: SSH Communications Security
From: Markus Stenberg <mstenber@ssh.com>
Date: 31 Oct 2001 09:42:51 +0200
In-Reply-To: <p05101015b804d4112718@[165.227.249.20]>
Message-ID: <87k7xc8dc4.fsf@porsas.hel.fi.ssh.com>
Lines: 20
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
paul.hoffman@vpnc.org (Paul Hoffman / VPNC) writes:
> Greetings again. The past few weeks have seen new drafts for the two
> main NAT traversal documents, draft-ietf-ipsec-nat-t-ike-01.txt
> (Negotiation of NAT-Traversal in the IKE and
> draft-ietf-ipsec-udp-encaps-01.txt (UDP Encapsulation of IPsec
> Packets). Are there any outstanding issues on them? Might we have
> these finished soon?
I believe they're done (although we noted later on that our Expires: header
in the draft-ietf-ipsec-nat-t-ike-01 looks amusing, but apparently it's not
checked by anyone ;->).
At least, those are all to-do items related to drafts that I know of (the
IKE draft contains few clarifications and udp-encap draft removed AH
support and had some clarifications).
> --Paul Hoffman, Director
> --VPN Consortium
-Markus
From owner-ipsec@lists.tislabs.com Wed Oct 31 07:37:13 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VFbC824227;
Wed, 31 Oct 2001 07:37:13 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12660
Wed, 31 Oct 2001 09:46:20 -0500 (EST)
From: "Khaja E. Ahmed" <khaja.ahmed@cavium.com>
To: "Steven M. Bellovin" <smb@research.att.com>
Cc: "mahdavi" <mahdavi@sepahan.iut.ac.ir>, <ipsec@lists.tislabs.com>
Subject: RE: CBC makes Implementations too Slow.
Date: Tue, 30 Oct 2001 22:39:18 -0800
Message-ID: <GCEGKDEGCPFGJNGILFIPEEJKCHAA.khaja.ahmed@cavium.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 IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <20011031005533.B51867C01@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Steve,
You are quite right - sorry if I did not make this clear. Multiple cores
only help if there are multiple streams or IPsec tunnels. As you point out
a single stream can not be parallelised and the packets would have to be
serially processed. This limts the performance to that of a single core - 2
gbps for example. That said, I am not sure that this is a major limitation.
Having multiple cores only helps when you have multiple IPsec tunnels for
example. Thus 8 cores could provide bandwidth of 16 gbps, assuming >= 8
tunnels and that no single tunnel requires bandwidth in excess of 2 gbps.
The devices available also have authentication, look up and other
capabilities that are necessary to not only do 3DES-CBC but full IPsec
packet processing at these rates.
Thus the point remains that it may not be necessary or helpful to
invent/explore other modes of DES when the problem of too slow encryption
has essentially been eliminated.
Khaja
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Steven M. Bellovin
> Sent: Tuesday, October 30, 2001 4:56 PM
> To: Khaja E. Ahmed
> Cc: mahdavi; ipsec@lists.tislabs.com
> Subject: Re: CBC makes Implementations too Slow.
>
>
> In message <GCEGKDEGCPFGJNGILFIPMEJHCHAA.khaja.ahmed@cavium.com>,
> "Khaja E. Ahm
> ed" writes:
> >Steve,
> >
> >I am not sure I understand why this (3DES CBC in silicon) is considered a
> >problem and in what types of applications and devices? Is the
> problem cost?
> >I am not sure that there would be much benefit in waiting for
> other modes to
> >emerge given how cheap and fast silicon is getting.
> >
> >There are cheaper and faster crypto accelerators available today
> than ever
> >before. Currently shipping chips deliver, 600 mbps throughput
> on a single
> >stream of 3DES IPsec traffic. There are also chips that use
> multiple cores
> >to do 2.4 gbps. We (Cavium) and others have announced even
> faster chips. We
> >expect to deliver chips in Jan that will do 2 gbps in each core.
> Given the
> >multi core architecture of these chips, they can handle as much 3DES CBC
> >IPSec (or SSL/TLS) traffic as the PCI, PCIX and LDT buses can
> handle. Mid
> >2002 versions will handle at line rate (OC48 and OC192) IPsec and SSL/TLS
> >traffic not only 3DES CBC but also AES and arc4. Is this not sufficient?
>
> I'm not a hardware person; all I can do is listen when hardware folk
> tell me that they can or cannot do certain things. CBC mode requires
> feedback, which makes it impossible to pipeline encryptions; you can't
> encrypt plaintext block P[n+1] until you have the ciphertext from
> encrypting P[n]. That in turn makes me wonder how multiple cores help
> you, unless it's to let you encrypt two different packets
> simultaneously, for a high aggregate throughput rate.
>
> Anyway -- enough people complained to NIST that they decided that a new
> mode was necessary. I'm not completely convinced, and I don't think
> that most of the proposed new modes (especially counter mode) will
> really do the job. Specifically, it does no good to encrypt at such
> rates if you can't authenticate at such rates, too. (Matt Blaze and I
> wrote a short paper on our concerns for any new modes of operation; see
> http://www.research.att.com/~smb/papers/internet-modes.ps or
> http://www.research.att.com/~smb/papers/internet-modes.pdf .)
>
> --Steve Bellovin, http://www.research.att.com/~smb
> Full text of "Firewalls" book now at
> http://www.wilyhacker.com
>
>
>
From owner-ipsec@lists.tislabs.com Wed Oct 31 07:39:51 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VFdo824340;
Wed, 31 Oct 2001 07:39:50 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12648
Wed, 31 Oct 2001 09:45:19 -0500 (EST)
Message-ID: <3BDF4442.C8FAFF83@cisco.com>
Date: Tue, 30 Oct 2001 19:22:26 -0500
From: Leo Temoshenko <leot@cisco.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Shriver, John" <john.shriver@intel.com>
CC: "'rks@cisco.com'" <rks@cisco.com>, Theodore Tso <tytso@mit.edu>,
Tim Jenkins <TJenkins@Catena.com>, bbruins@cisco.com,
bret_harrison@tivoli.com, Barbara Fraser <byfraser@cisco.com>,
cmadson@cisco.com, ipsec@lists.tislabs.com, pcn@cisco.com
Subject: Re: Status of ID: IPsec Flow Monitoring MIB
References: <C703B434E680D511BDFD0002A507069602978DF9@hdsmsx101.hd.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I believe all of points were addressed by rks in his response
to Tim Jenkins (timestamp Tue, 30 Oct 2001 12:21:11 -0800).
His responses were great and right-on-the-money.
I would like to add several comments...
1) Your note is very interesting and touching. It covers
all the points that one learns in an "how to influence
others" class - fear, justification, authorization advice
and ends with sympathy. Very nice.
2) However, I would really like the IPsec Group to
have a MIB which is useable/meaningful. The "bit level" MIB
drafts are not even close.
I work with VERY competent developers (in other areas)
who cannot make sense of these "bit level" MIBs and
use IPsec. And then there are the application developers,
network operators, and poor users which find the "bit level"
MIBs COMPLETELY meaningless. They do not understand the
objects or their meaning. NOT good and NOT normal in other MIBs.
3) The "bit level" MIBs have not been widely accepted,
implemented nor gone though review/updates based on
on experience. A real issue for standardization and
moving forward.
4) On the other hand, the Flow Monitoring MIB has.
This MIB been implemented in at least 4 FAMILIES
of products for 3 different vendors/implementors
that I have worked for and has undergone at least
5 revisions based on input/feedback from developers
to customers.
It continues to be my belief that the "bit level" MIBs
should be abandoned as they are not useful and move to
a useable MIB IPsec which ALL can understand and use
to make the protocol VERY manageable.
"Shriver, John" wrote:
>
> I think I need to remind the participants of this discussion of an important
> point:
>
> ***** This is not the VPN working group. This is the IPsec working group.
> *****
>
> I think this has been emphasized MANY times by the chairs and area
> directors. They will NOT budge on this issue.
>
> The phrases "VPN" and "Virtual Private Network" do not appear in our
> charter. Please re-read it:
> http://www.ietf.org/html.charters/ipsec-charter.html
>
> Our job is to develop useful MIBs for the "protocol" named IPsec. It
> consists of ESP, AH, static keying, ISAKMP, and IKE.
>
> I will not claim that the IPsec Monitoring MIBs are trivial to implement.
> Nor is IPsec trivial to implement. Many complain that it is too
> complicated, the MIBs make the complexity visible. Much of that complexity
> is in the extreme flexibility of IPsec.
>
> If you want to make the MIBs simpler, please propose which options to delete
> from IPsec. (That is a relatively rhetorical question, I do NOT want to
> drag THAT discussion into this discussion!)
>
> You may validly pick on the monitoring MIBs in that we split ISAKMP and IKE,
> and that the working group has since decided that said layering of
> documentation and specification is no longer appropriate. Fine. It would
> be a trivial change to the monitoring MIBs to merge the ISAKMP and IKE
> documents into one MIB. For the most part, the tables in the IKE MIB merely
> augment tables that already exist in the ISAKMP MIB, so it's just a matter
> of stiching them into one table. It would also allow us to remove the
> columns in the "ISAKMP" tables that say "this row is IKE".
>
> But, as for layering IPsec (AH and ESP proper) separately from ISAKMP/IKE,
> nobody has published a revision of RFC 2401 that makes ISAKMP/IKE mandatory
> for IP Version 4.
>
> I think that the MIBs do provide the lookup tables to examine the status of
> one "phase 2 security association suite". I do not think that these are
> generally so short-lived that an SNMP manager could not find it before it
> was replaced with a new one (rekeying, I presume). (Maybe I'm wrong on
> this, maybe the bandwidths are now so high that rekeying is done once a
> minute.)
>
> > And should replace the "low level" MIBs which no one other than
> > an IPsec developer could understand.
>
> The idea of SNMP was never that users would "understand" a MIB. I think
> that the providers of SNMP management stations were supposed to provide the
> "understanding". Unfortunately, a lot of them never got past MIB walkers
> and pretty network maps that turn nodes red and green. This is partly
> because the MIB syntax isn't really very descriptive, is weak on explaining
> table relationships, etc. This also leads to people wanting to write flat
> "application-specific" MIBs, because all the layering has to be described in
> text, rather than as a formal part of the syntax.
>
> I'm interested in knowing what particular parts of these monitoring MIBs
> people think are really useless. I do know that there are places where only
> one type of "identity" make any sense, yet we support any of the defined
> ones, because ISAKMP/IKE does. So let's strike those, hopefully they will
> also be striken in the "son of IKE" document.
>
> I don't see that the Flow Monitoring MIB would be very useful for
> "opportunistic IPsec" with transport mode.
>
> Looking just at the IKE phase 1 area, you have two tables. One is
> ikePeerTable, which is about concrete peer entity relationships. That's a
> layer we don't have, and is a table I agree is useful. It is in turn
> layered on ikeTunnelTable. That is quite equivalent to our saTable, in
> particular the rows that show up in ikeSaTable. The contents of
> ikeTunnelTable and ikeSaTable are quite comprable. The difference is that
> you cannot do a meaningful direct lookup of ikeTunnelTable, since it is
> indexed by a "meaningless" arbitrary index. The ikeSaTable is indexed by
> the "real" fields of the ISAKMP/IKE negotiation that identify one Phase 1
> connection.
>
> It would be quite simple to expand ikePeerTable to have the full index data
> to identify a real ISAKMP/IKE phase 1 tunnel (address types, addresses, and
> cookies), and then replace ikeTunnelTable with a merged saTable/ikeSaTable.
>
> I also note that ikeTunnelTable has even more statistics than ikeSaTable.
> Nothing wrong with that. The more the merrier.
>
> However, there is a visible strategy difference on how the two MIBs count
> exchanges. ikeTunnelTable keeps some global counters of all exchanges, and
> then has counters for each of the exchanges currently defined. This means
> that the MIB will require revision every time a new exchange gets defined,
> and will never reach Full Standard status. (I've been in that endless loop
> on other MIBs, like the dot3 MIB.) We put in a table for counting
> exchanges, exchangeTable, that is indexed by the same indices as ikeSaTable,
> plus an additional index of the exchange type. (Think of it as another
> dimension on ikeSaTable.) This means that we don't need to revise the MIB
> when a new exchange type is assigned, the IANA edits the textual-convention
> MIB, and the new rows magically exist.
>
> I would also note that the Tunnel MIB doesn't conform to RFC 2581.
>
> I will admit that our progress has been slow. Some of the drafts expired.
> Neither of us are developing IPsec products for a living anymore, we
> finished this project out of a dedication to the needs of this IETF working
> group, and (slowly) living up to our committments thereto.
From owner-ipsec@lists.tislabs.com Wed Oct 31 10:11:35 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VIBX807570;
Wed, 31 Oct 2001 10:11:34 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13099
Wed, 31 Oct 2001 12:11:06 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15328.12958.21408.546543@pkoning.dev.equallogic.com>
Date: Wed, 31 Oct 2001 12:19:26 -0500 (EST)
From: Paul Koning <ni1d@arrl.net>
To: leot@cisco.com
Cc: john.shriver@intel.com, rks@cisco.com, ipsec@lists.tislabs.com
Subject: Re: Status of ID: IPsec Flow Monitoring MIB
References: <C703B434E680D511BDFD0002A507069602978DF9@hdsmsx101.hd.intel.com>
<3BDF4442.C8FAFF83@cisco.com>
X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
>>>>> "Leo" == Leo Temoshenko <leot@cisco.com> writes:
Leo> I believe all of points were addressed by rks in his response to
Leo> Tim Jenkins (timestamp Tue, 30 Oct 2001 12:21:11 -0800). His
Leo> responses were great and right-on-the-money.
Leo> I would like to add several comments...
Leo> 1) Your note is very interesting and touching. It covers all
Leo> the points that one learns in an "how to influence others" class
Leo> - fear, justification, authorization advice and ends with
Leo> sympathy. Very nice.
I've been watching this argument for a while now.
Frankly, a lot of it has been at a level that prompts me to reach for
the Delete key right away. I haven't been able to find much substance
in between all the childish remarks, unfortunately. In particular,
I've seen a lot of messages that are not even close to the level of
maturity and technical substance one would expect to see from people
who claim to represent Cisco.
It may help feed your own sense of self-importance to write comments
such as the one quoted above, but it does not help at all in advancing
your argument to a disinterested observer. If you have a desire to
influence the direction of the group, maybe you should have a
conversation with some of your more senior colleagues on what to do
and what not to do in IETF WG interactions.
paul
From owner-ipsec@lists.tislabs.com Wed Oct 31 10:40:17 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VIeH809115;
Wed, 31 Oct 2001 10:40:17 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13151
Wed, 31 Oct 2001 12:40:00 -0500 (EST)
Message-ID: <3BE03968.80705@isi.edu>
Date: Wed, 31 Oct 2001 09:48:24 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: ji@research.att.com
CC: khaja.ahmed@cavium.com, smb@research.att.com, ipsec@lists.tislabs.com,
mahdavi@sepahan.iut.ac.ir
Subject: Re: CBC makes Implementations too Slow.
References: <200110310344.WAA09869@bual.research.att.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
ji@research.att.com wrote:
> Maybe I'm missing something, but packets are sent in a bit-serial manner
> in almost all cases; you can be encrypting block n+1 while you are
> transmitting the (already encrypted) block n. Since you have to transmit
> some headers in the clear, you can start encryption of the payload at the
> same time as the cleartext headers are being transmitted; so long as
> you can encrypt at line speeds, you keep the pipelines full. Isn't that
> what we want?
Except that the hash of the data is placed in a field of the header :-)
Encryption at 'line rate' necessarily implies at least a 1-packet
latency on the sender's end.
(note - this happens even for TCP, which requires two passes of delay -
one to calculate the checksum and place it in the TCP header, one to
calculate the hash)
Joe
From owner-ipsec@lists.tislabs.com Wed Oct 31 10:44:44 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VIii809202;
Wed, 31 Oct 2001 10:44:44 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13165
Wed, 31 Oct 2001 12:46:23 -0500 (EST)
Message-Id: <200110311749.f9VHnugl012629@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@East.Sun.COM>
To: "Khaja E. Ahmed" <khaja.ahmed@cavium.com>
cc: "Steven M. Bellovin" <smb@research.att.com>,
"mahdavi" <mahdavi@sepahan.iut.ac.ir>, ipsec@lists.tislabs.com
Subject: Re: CBC makes Implementations too Slow.
In-Reply-To: Your message of "Tue, 30 Oct 2001 22:39:18 PST."
<GCEGKDEGCPFGJNGILFIPEEJKCHAA.khaja.ahmed@cavium.com>
Reply-to: sommerfeld@East.Sun.COM
Date: Wed, 31 Oct 2001 12:49:55 -0500
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> You are quite right - sorry if I did not make this clear. Multiple cores
> only help if there are multiple streams or IPsec tunnels.
Multiple streams? or multiple packets to work on at a time?
The crypto per se shouldn't have inter-packet dependancies, though
some interlocking would be necessary for sequence number generation
and replay detection ..
- Bill
From owner-ipsec@lists.tislabs.com Wed Oct 31 10:50:32 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VIoV809315;
Wed, 31 Oct 2001 10:50:31 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13180
Wed, 31 Oct 2001 12:56:00 -0500 (EST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
From: "Steven M. Bellovin" <smb@research.att.com>
To: Joe Touch <touch@ISI.EDU>
Cc: ji@research.att.com, khaja.ahmed@cavium.com, ipsec@lists.tislabs.com,
mahdavi@sepahan.iut.ac.ir
Subject: Re: CBC makes Implementations too Slow.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 31 Oct 2001 13:03:42 -0500
Message-Id: <20011031180342.4353D7C01@berkshire.research.att.com>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In message <3BE03968.80705@isi.edu>, Joe Touch writes:
>
>
>ji@research.att.com wrote:
>
>> Maybe I'm missing something, but packets are sent in a bit-serial manner
>> in almost all cases; you can be encrypting block n+1 while you are
>> transmitting the (already encrypted) block n. Since you have to transmit
>> some headers in the clear, you can start encryption of the payload at the
>> same time as the cleartext headers are being transmitted; so long as
>> you can encrypt at line speeds, you keep the pipelines full. Isn't that
>> what we want?
>
>
>Except that the hash of the data is placed in a field of the header :-)
Only with AH -- ESP doesn't have that problem....
--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com
From owner-ipsec@lists.tislabs.com Wed Oct 31 11:46:22 2001
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101])
by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VJkM811342;
Wed, 31 Oct 2001 11:46:22 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13325
Wed, 31 Oct 2001 13:47:34 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po1.bbn.com
Message-Id: <p05010415b805f0b0e75f@[128.89.88.34]>
In-Reply-To: <200110311749.f9VHnugl012629@thunk.east.sun.com>
References: <200110311749.f9VHnugl012629@thunk.east.sun.com>
Date: Wed, 31 Oct 2001 13:46:08 -0500
To: sommerfeld@East.Sun.COM
From: Stephen Kent <kent@bbn.com>
Subject: Re: CBC makes Implementations too Slow.
Cc: "Khaja E. Ahmed" <khaja.ahmed@cavium.com>,
"Steven M. Bellovin" <smb@research.att.com>,
"mahdavi" <mahdavi@sepahan.iut.ac.ir>, ipsec@lists.tislabs.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
At 12:49 PM -0500 10/31/01, Bill Sommerfeld wrote:
> > You are quite right - sorry if I did not make this clear. Multiple cores
>> only help if there are multiple streams or IPsec tunnels.
>
>Multiple streams? or multiple packets to work on at a time?
>
>The crypto per se shouldn't have inter-packet dependancies, though
>some interlocking would be necessary for sequence number generation
>and replay detection ..
>
> - Bill
Multiple SAs are easy, which is why I used that example.
Multiple packets in the same SA could be reordered if farmed out to
multiple crypto units in a chip, e.g., a later, small packet could
emerge sooner than a larger, previously received packet. You can fix
this with more complexity and buffering on the black side, but it
takes work, memory, etc.
Steve