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" To: "ipsec" 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
hi all.
I sent a wrong mail to the group. =
 
please ignore my last = Email.
 
bye
 
many thanks before
 
------=_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 Reply-To: Rajesh Bhattacharya 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 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: 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)" To: , 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 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" To: "Rajesh Bhattacharya" , Subject: RE: Initial Contact Message in IKE Date: Mon, 1 Oct 2001 13:35:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) 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 - 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 > > 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: From: "Andrew Krywaniuk" To: , 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: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: 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: 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: From: "Andrew Krywaniuk" 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: Cc: , Subject: Re: AES with SHA-2 References: <002101c14ad1$14537a80$1e72788a@andrewk3.ca.newbridge.com> From: "Perry E. Metzger" 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" 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 To: "'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 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" To: "Alex Alten" Cc: 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" To: Cc: Subject: RE: IPSec still too slow? Date: Fri, 5 Oct 2001 16:28:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <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 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" , "Alex Alten" From: Pravin Kantak Subject: RE: IPSec still too slow? Cc: 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" To: "Pravin Kantak" , "Alex Alten" Cc: 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 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 , ipsec@lists.tislabs.com From: Alex Alten 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" To: Alex Alten Cc: Joel M Snyder , 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: Thread-Topic: IPSec still too slow? Thread-Index: AcFOaXaGXXce/Za8TRqC3cT0fL5IAAAO4y7Q From: "Qiang Zhang" To: 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" 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" CC: Alex Alten , Joel M Snyder , 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 , Joel M Snyder , ipsec@lists.tislabs.com From: Natalie Timms 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" To: "Natalie Timms" , "Alex Alten" , "Joel M Snyder" , 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 Subject: RE: IPSec still too slow? Cc: In-Reply-To: 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 Subject: Re: IPSec still too slow? To: Alex Alten 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 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" 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 Subject: Re: IPSec still too slow? To: ipsec@lists.tislabs.com Cc: Natalie Timms 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 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 Cc: ipsec@lists.tislabs.com, Natalie Timms 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/AuzN4mu!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 Reply-To: sleepy-cat@263.net To: Alexey Vyskubov , "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?= To: 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" 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: 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 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_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 X-Mailer: The Bat! (v1.53bis) Educational Reply-To: Marco Ender 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)" To: ??? , 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"
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-- 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 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 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: From: "Peter Onufryk" To: 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 Subject: Re: IPSec still too slow? Cc: ipsec@lists.tislabs.com In-Reply-To: <20011009190124.D8D3F54C44@tailor.sailpix.com> References: 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 To: dxh cc: Alexey Vyskubov , "ipsec@lists.tislabs.com" Subject: Re: Re: Does an outbound packet need to be reroute? In-Reply-To: <200110090203.KAA15413@csnet1> Message-ID: 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: Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: 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" 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 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: 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: From: "Andrew Krywaniuk" To: "'Jerome Freedman Jr'" , 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 who is implementing rekey and how
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.
 
Andrew
------------------------------------------- =
Upon closer inspection, I = saw that the=20 line
dividing=20 black from white was in fact a shade
of grey. As I drew nearer still, the grey=20 area
grew=20 larger. And then I was enlightened.
 
-----Original Message-----
From:=20 owner-ipsec@lists.tislabs.com = [mailto:owner-ipsec@lists.tislabs.com]On=20 Behalf Of Jerome Freedman Jr
Sent: Tuesday, October 09, = 2001=20 9:56 AM
To: ipsec@lists.tislabs.com
Subject: who = is=20 implementing rekey and how


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).

Jerry Freedman

          = >\ =20 |  /<
           = (@)=20 (@)
 ------=20 o00o-(_)-o00o--------------- =


------=_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 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: From: Raghunath Tilak To: "'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 Question regarding sensitivity check in RFC 2401

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

       =20

------_=_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" Reply-To: "sunil kumar chirra" To: 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" To: "Marco Ender" , 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" To: 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 X-Mailer: The Bat! (v1.53bis) Educational Reply-To: Marco Ender 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 X-Mailer: The Bat! (v1.53bis) Educational Reply-To: Marco Ender X-Priority: 3 (Normal) Message-ID: <1413809303.20011011125158@dungeonmaster.at> To: "Hong Gie Ong" , 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 To: "'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 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: 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"
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_=-- 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 Subject: Re: IPComp CPI's In-Reply-To: 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?= 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?= 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: 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)" To: 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 X-Mailer: The Bat! (v1.53bis) Educational Reply-To: Marco Ender 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" To: "Marco Ender" , 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" Reply-To: "sunil kumar chirra" To: 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: In-Reply-To: References: Date: Sat, 13 Oct 2001 15:33:08 -0400 To: "Li Man.M (NRC/Boston)" From: Stephen Kent Subject: Re: Precedence on selectors, policy entries or both? Cc: 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: 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 From: Stephen Kent 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" 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: 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" To: "Amey Gokhale" 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 , "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 Reply-To: sleepy-cat@263.net To: "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" To: "'sleepy-cat@263.net'" Cc: "'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: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Mon, 15 Oct 2001 11:36:40 -0600 From: "Hilarie Orman" To: , Cc: 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" 10/15/01 04:52AM >>> In message , "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" To: "Hilarie Orman" 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 , "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: 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" From: Stephen Kent Subject: Re: DataStructure for Storing SPD,SA Entries Cc: "Hilarie Orman" , 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 , "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 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'" CC: "'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 To: "'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 ipsec masqueradin

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.

=A0

  • 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
=A0
-Bik

---------------------------------------------------------= ---------------------------------
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)
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)
Product = Development=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A031355 = Agoura Road
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

=A0

------_=_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 To: "'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

Hi

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.

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.

is there a way to distinguish tunnel mode from transport mode just = by looking=20 at an ESP packet.

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).

Thanks a lot

-Bik

---------------------------------------------------------------= ---------------------------=20
Bik=20 Singh           &= nbsp;           &= nbsp;          =20 818-575-2518 (Off)
Research=20 Scientist          &nb= sp;          =20 818-597-1502 (Fax)
Product=20 Development          &= nbsp;       31355=20 Agoura Road
Nomadix=20        =20        =20         Westlake Village, CA = 91361=20

 
------_=_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?= Subject: Re: DataStructure for Storing SPD,SA Entries To: Puja Puri 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 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" > To: > 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" To: "ranjeet barve" Cc: 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" To: "Puja Puri" Cc: 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 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" > > To: > > 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" Subject: Re: To: Bikramjit Singh Cc: "'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: 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 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

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

 
------------=_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" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com, "ranjeet barve" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: 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" et.in> cc: 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" To: "Puja Puri" Cc: 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 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" > > To: > > 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 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: In-Reply-To: References: Date: Wed, 17 Oct 2001 16:53:21 -0400 To: Raghunath Tilak From: Stephen Kent Subject: Re: Question regarding sensitivity check in RFC 2401 Cc: "'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 Subject: Re: DataStructure for Storing SPD,SA Entries To: Puja Puri , ranjeet barve 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" To: "'Smith Geo'" 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 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 Reply-To: sleepy-cat@263.net To: "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" To: , "Puja Puri" Cc: , "ranjeet barve" 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 , dst 1701. However, many people have argued that they want an IPSec SA established for TCP src , dst , 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 , 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" et.in> cc: 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" To: "Puja Puri" Cc: 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 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" > > To: > > 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" 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 CC: "Steve.Robinson" , Puja Puri , ipsec , ranjeet barve 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 , dst 1701. > > However, many people have argued that they want an IPSec SA established > for TCP src , dst , 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 > , 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" > > > et.in> cc: > > 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" > To: "Puja Puri" > Cc: > 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 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" > > > To: > > > 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" To: "'Wei-Jen Yeh'" , William Dixon Cc: "Steve.Robinson" , Puja Puri , ipsec , ranjeet barve 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" Cc: ipsec , Puja Puri , ranjeet barve , William Dixon , "'Wei-Jen Yeh'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: 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" , William Dixon AI.com> cc: "Steve.Robinson" , Puja Puri 10/19/01 09:32 , ipsec , ranjeet AM barve 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" Subject: Re: question about Nonce References: <200110190120.JAA05933@csnet1> From: Derek Atkins 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: 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 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" To: , "Mason, David" Cc: "ipsec" , "Puja Puri" , "ranjeet barve" , "William Dixon" , "'Wei-Jen Yeh'" 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: 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" > > , William Dixon > AI.com> > > cc: "Steve.Robinson" > , Puja Puri > 10/19/01 09:32 > , ipsec , ranjeet > AM barve > > 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 From: Barbara Fraser Subject: RE: Status of ID: IPsec Flow Monitoring MIB Cc: "'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 > 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: 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" From: Stephen Kent Subject: RE: DataStructure for Storing SPD,SA Entries Cc: , "Puja Puri" , , "ranjeet barve" 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 , 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 , dst , 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 >, 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" 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 CC: 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 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 > > 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 X-Mailer: The Bat! (v1.53bis) Educational Reply-To: Marco Ender 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 Reply-To: sleepy-cat@263.net To: Derek Atkins , "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 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 Reply-To: sleepy-cat@263.net To: "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" Subject: Re: Re: question about Nonce References: <200110210836.QAA09615@csnet1> From: Derek Atkins 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: 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 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 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" Subject: Re: what 's the use of ID payloads in Main mode of preshared key? References: <200110210839.QAA09619@csnet1> From: Derek Atkins 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: Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk dxh 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: Cc: , 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 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: 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" 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 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: From: "Andrew Krywaniuk" To: "'Derek Atkins'" , Cc: 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: 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 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" Subject: Re: preshared key in ipv6 References: <200110220138.JAA10352@csnet1> From: Derek Atkins 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: 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 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 Reply-To: sleepy-cat@263.net To: "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 To: Subject: Minimum implementation requirement of IPsec Message-ID: 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 Reply-To: sleepy-cat@263.net To: Derek Atkins , "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" To: "'Marco Ender'" , 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" To: "'andrew.krywaniuk@alcatel.com'" , "'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? 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 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" To: Paul Koning 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 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" Cc: Paul Koning , sleepy-cat@263.net, ipsec@lists.tislabs.com Subject: Re: preshared key in ipv6 References: <20011022181614.0BA597B55@berkshire.research.att.com> From: Derek Atkins 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: Lines: 23 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" 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" 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 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 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jun-ichiro" == Jun-ichiro itojun Hagino 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 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 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 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 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 Cc: Jun-ichiro itojun Hagino , 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/AuzN4mu!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 cc: Theodore Tso , Barbara Fraser , Barry Bruins , , Cheryl Madson , Narasimha , Subject: RE: Status of ID: IPsec Flow Monitoring MIB In-Reply-To: Message-ID: 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 cc: , , , , Subject: RE: Status of ID: IPsec Flow Monitoring MIB In-Reply-To: <522FDAAFD532D511A0AB0002A51390EB2F6FE0@cat01s2.catena.com> Message-ID: 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 . 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 > 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 > 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 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 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 Fri, 26 Oct 2001 14:23:03 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi - From: Theodore Tso 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 Reply-To: Radia Perlman - Boston Center for Networking 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" To: Radia Perlman - Boston Center for Networking 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" To: Radia Perlman - Boston Center for Networking 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" 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 Reply-To: Radia Perlman - Boston Center for Networking 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" 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 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: From: "Masafumi Tsuruta" To: 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 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 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: From: "Shriver, John" To: "'rks@cisco.com'" , 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 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 > 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 To: "'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 . > 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 > > > 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 > > 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" To: "Theodore Tso" , "Scott G. Kelly" Cc: "Barbara Fraser" , "Tim Jenkins" , , , , Subject: RE: Status of ID: IPsec Flow Monitoring MIB Date: Fri, 26 Oct 2001 16:50:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.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 To: "'rks@cisco.com'" , 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 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 To: "'rks@cisco.com'" , Theodore Tso Cc: 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 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 > 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" 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 , 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 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 > 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. > 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=?= To: 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 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" CC: "'rks@cisco.com'" , Theodore Tso , Tim Jenkins , bbruins@cisco.com, bret_harrison@tivoli.com, Barbara Fraser , cmadson@cisco.com, ipsec@lists.tislabs.com, pcn@cisco.com, leot@cisco.com Subject: Re: Status of ID: IPsec Flow Monitoring MIB References: 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 > > 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 To: "'Leo Temoshenko'" Cc: "'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 with the keyword "shriver": ... > > > > 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 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 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 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 . > > 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 > > > > > 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 > > > 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 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 CC: "'rks@cisco.com'" , Casey Carr , 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 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 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 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 Subject: Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression) To: John Border Cc: Radia Perlman - Boston Center for Networking , 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 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 CC: "'rks@cisco.com'" , Theodore Tso , bbruins@cisco.com, bret_harrison@tivoli.com, Barbara Fraser , 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 > > 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" To: 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
Hi Sirs.
Hardware implementation of = IPSEC is=20 our activity.
now we face with a problem about CBC mode. =
 
In software CBC makes no trouble for = implementation=20 but in hardware it is another story.
If CBC mode was not mandate, = acheiving=20 high speed cryptography was easy.
 
for example for 3des every block needs = 48 pulses to=20 be encrypted. ( 16 round )
 
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.
in another = word=20 feeding every block needs result of pervious block at first. =
 
so our pipeline faces with terrible = lack of=20 efficiency.
 
now how can we face with this problem.=20
 
can any body shows us some guide=20 lines?
 
sincerely yours=20
mahdavi
------=_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" To: "mahdavi" 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: From: "Shriver, John" To: "'Leo Temoshenko'" , "Shriver, John" Cc: "'rks@cisco.com'" , Theodore Tso , Tim Jenkins , bbruins@cisco.com, bret_harrison@tivoli.com, Barbara Fraser , 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 cc: , , , , Subject: RE: Status of ID: IPsec Flow Monitoring MIB In-Reply-To: <522FDAAFD532D511A0AB0002A51390EB2F7082@cat01s2.catena.com> Message-ID: 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 . > > 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 > > > > > 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 > > > 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 To: "'henry@campio.com'" Cc: "'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 cc: John Border , Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com, nordmark@Eng.Sun.COM, Avram Shacham Subject: Re: Does anyone care about IPcomp with IKE? (IPcomp=IP compression) In-Reply-To: Message from Joel Snyder 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 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 To: John Border Cc: Radia Perlman - Boston Center for Networking , 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: Date: Tue, 30 Oct 2001 14:05:05 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC 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 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 CC: "'henry@campio.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" To: "Khaja E. Ahmed" Cc: "mahdavi" , 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 , "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" cc: Theodore Tso , Tim Jenkins , , , Barbara Fraser , , , , Subject: Re: Status of ID: IPsec Flow Monitoring MIB In-Reply-To: <3BDDFE00.24788C0B@redcreek.com> Message-ID: 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 > > 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" cc: "'Leo Temoshenko'" , Theodore Tso , Tim Jenkins , , , Barbara Fraser , , , Subject: RE: Status of ID: IPsec Flow Monitoring MIB In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi - From: "Shriver, John" 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: Date: Tue, 30 Oct 2001 22:44:59 -0500 (EST) Message-ID: <200110310344.WAA09869@bual.research.att.com> To: , Cc: , 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" To: , , Cc: , 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: 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" From: Stephen Kent Subject: Re: CBC makes Implementations too Slow. Cc: "Khaja E. Ahmed" , "mahdavi" , 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 , >"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" To: "Steven M. Bellovin" , "mahdavi" Cc: Subject: RE: CBC makes Implementations too Slow. Date: Tue, 30 Oct 2001 16:44:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <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: Organization: SSH Communications Security From: Markus Stenberg Date: 31 Oct 2001 09:42:51 +0200 In-Reply-To: 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" To: "Steven M. Bellovin" Cc: "mahdavi" , Subject: RE: CBC makes Implementations too Slow. Date: Tue, 30 Oct 2001 22:39:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal 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 , > "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 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" CC: "'rks@cisco.com'" , Theodore Tso , Tim Jenkins , bbruins@cisco.com, bret_harrison@tivoli.com, Barbara Fraser , cmadson@cisco.com, ipsec@lists.tislabs.com, pcn@cisco.com Subject: Re: Status of ID: IPsec Flow Monitoring MIB References: 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 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: <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 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 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 To: "Khaja E. Ahmed" cc: "Steven M. Bellovin" , "mahdavi" , 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." 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" To: Joe Touch 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: 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 Subject: Re: CBC makes Implementations too Slow. Cc: "Khaja E. Ahmed" , "Steven M. Bellovin" , "mahdavi" , 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