From owner-ipsec@lists.tislabs.com Sun Jul 1 18:58:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f621wom06572; Sun, 1 Jul 2001 18:58:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA00812 Sun, 1 Jul 2001 20:54:45 -0400 (EDT) Message-Id: <200107020101.VAA25849@bcn.East.Sun.COM> Date: Sun, 1 Jul 2001 21:01:00 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: AH length field, and derivation of name "SKEYID" To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: aDka9pVwIy6E7v/UOcRJgw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Given that AH is an IPv6 extension header, why is its length specified in different units than other IPv6 extension headers? Unless I'm confused, AH's length field is in units of 32-bit chunks where IPv6 extension headers length field is in units of 64-bit chunks. I'd guess it's so that when AH is used with IPv4 you can use less padding, but it would be nice to verify that. Was it controversial to decide to use different units for length? The other question is a "just for curiosity". Why is SKEYID called that? It's not the ID of anything. I'd have called it perhaps something like SKEYSEED. Thanks, Radia From owner-ipsec@lists.tislabs.com Sun Jul 1 23:41:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f626fYm22569; Sun, 1 Jul 2001 23:41:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA01174 Mon, 2 Jul 2001 01:39:38 -0400 (EDT) Date: Mon, 2 Jul 2001 08:45:50 +0300 Message-Id: <200107020545.IAA01910@burp.tkv.asdf.org> From: Markku Savela To: Radia.Perlman@sun.com CC: ipsec@lists.tislabs.com In-reply-to: <200107020101.VAA25849@bcn.East.Sun.COM> (message from Radia Perlman - Boston Center for Networking on Sun, 1 Jul 2001 21:01:00 -0400 (EDT)) Subject: Re: AH length field, and derivation of name "SKEYID" References: <200107020101.VAA25849@bcn.East.Sun.COM> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Radia Perlman - Boston Center for Networking > Given that AH is an IPv6 extension header, why is its length > specified in different units than other IPv6 extension headers? > Unless I'm confused, AH's length field is in units of 32-bit chunks > where IPv6 extension headers length field is in units of 64-bit > chunks. I don't know the definitive answer, but I assume it is because AH/ESP are originally specified for IPv4, and *all* IP headers are technically for both IPv4 and IPv6. Some headers just make sense with one or the other, but some are used as in both (such as AH, ESP, TCP, UDP, etc.) From owner-ipsec@lists.tislabs.com Mon Jul 2 08:12:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62FCum20990; Mon, 2 Jul 2001 08:12:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02329 Mon, 2 Jul 2001 10:13:36 -0400 (EDT) To: Markku Savela Cc: Radia.Perlman@sun.com, ipsec@lists.tislabs.com In-reply-to: msa's message of Mon, 02 Jul 2001 08:45:50 +0300. <200107020545.IAA01910@burp.tkv.asdf.org> 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: AH length field, and derivation of name "SKEYID" From: Jun-ichiro itojun Hagino Date: Mon, 02 Jul 2001 19:00:05 +0900 Message-Id: <20010702100005.ADC5E7BC@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> Given that AH is an IPv6 extension header, why is its length >> specified in different units than other IPv6 extension headers? >> Unless I'm confused, AH's length field is in units of 32-bit chunks >> where IPv6 extension headers length field is in units of 64-bit >> chunks. yes, the above is correct. AH: length in bytes = (length field + 2) << 2 others: length in bytes = (length field + 1) << 3 the above interpretation fits all of the implementation we have interoperated with in the past. itojun From owner-ipsec@lists.tislabs.com Mon Jul 2 12:52:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62Jq0m10812; Mon, 2 Jul 2001 12:52:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02953 Mon, 2 Jul 2001 14:40:15 -0400 (EDT) Message-ID: <3677E033A5F3D211AC4000A0C96B53EB05C2EA42@FMSMSX94> From: "Herbert, Howard C" To: ipsec@lists.tislabs.com Subject: Is Anyone in the IPsec WG Writing a Draft RFC Using AES CBC MAC f or ESP Integrity? Date: Mon, 2 Jul 2001 11:46:16 -0700 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 If not, I would like to write it. I am a participant in the IP Storage WG and we would like to use this algorithm for our iSCSI RFCs. Howard Herbert Product Architect Intel Corporation LAN Access Division 480-554-3116 From owner-ipsec@lists.tislabs.com Mon Jul 2 13:54:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62Ksom16207; Mon, 2 Jul 2001 13:54:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03083 Mon, 2 Jul 2001 15:11:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200107020101.VAA25849@bcn.East.Sun.COM> References: <200107020101.VAA25849@bcn.East.Sun.COM> Date: Mon, 2 Jul 2001 15:12:01 -0400 To: Radia Perlman - Boston Center for Networking From: Stephen Kent Subject: Re: AH length field, and derivation of name "SKEYID" Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia, AH (and ESP) are defined for both IP v4 and v6. In the IPv4 context, AH was originally viewed as analogous to an IPv4 extension, hence the use of an IPv4 length encoding convention. Steve From owner-ipsec@lists.tislabs.com Mon Jul 2 13:55:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62Ktsm16300; Mon, 2 Jul 2001 13:55:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03218 Mon, 2 Jul 2001 16:13:04 -0400 (EDT) Message-ID: <3B40D3F9.12E708FC@pgp.com> Date: Mon, 02 Jul 2001 13:05:13 -0700 From: Will Price Reply-To: wprice@pgp.com X-Mailer: Mozilla 4.75 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Herbert, Howard C" CC: ipsec@lists.tislabs.com Subject: Re: Is Anyone in the IPsec WG Writing a Draft RFC Using AES CBC MAC for ESP Integrity? References: <3677E033A5F3D211AC4000A0C96B53EB05C2EA42@FMSMSX94> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Already written: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-01.txt "Herbert, Howard C" wrote: > > If not, I would like to write it. I am a participant in the IP Storage WG > and we would like to use this algorithm for our iSCSI RFCs. > > Howard Herbert > > Product Architect > Intel Corporation > LAN Access Division > 480-554-3116 -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Mon Jul 2 15:00:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62M07m20701; Mon, 2 Jul 2001 15:00:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA03433 Mon, 2 Jul 2001 17:18:12 -0400 (EDT) Message-ID: <3677E033A5F3D211AC4000A0C96B53EB05C2EA46@FMSMSX94> From: "Herbert, Howard C" To: "'wprice@pgp.com'" Cc: ipsec@lists.tislabs.com Subject: RE: Is Anyone in the IPsec WG Writing a Draft RFC Using AES CBC M AC for ESP Integrity? Date: Mon, 2 Jul 2001 14:24:16 -0700 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 This draft covers AES in CBC mode for ESP confidentiality. I need one on AES in CBC "MAC" mode for ESP integrity. MAC mode for DES is standardized in FIPS PUB 113. We need an AES version of this standard. Howard -----Original Message----- From: Will Price [mailto:wprice@pgp.com] Sent: Monday, July 02, 2001 1:05 PM To: Herbert, Howard C Cc: ipsec@lists.tislabs.com Subject: Re: Is Anyone in the IPsec WG Writing a Draft RFC Using AES CBC MAC for ESP Integrity? Already written: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-01.txt "Herbert, Howard C" wrote: > > If not, I would like to write it. I am a participant in the IP Storage WG > and we would like to use this algorithm for our iSCSI RFCs. > > Howard Herbert > > Product Architect > Intel Corporation > LAN Access Division > 480-554-3116 -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Mon Jul 2 15:53:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f62Mrhm21724; Mon, 2 Jul 2001 15:53:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA03641 Mon, 2 Jul 2001 18:17:50 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E07098D@corpmx14.us.dg.com> To: wprice@pgp.com Cc: ipsec@lists.tislabs.com Subject: RE: Is Anyone in the IPsec WG Writing a Draft RFC Using AES CBC M AC for ESP Integrity? Date: Mon, 2 Jul 2001 18:20:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That's the AES CBC cipher. What Howard wanted was the AES CBC **MAC** (i.e., with an ISAKMP SA Authentication Algorithm value). Is there a draft on that? --David (who put Howard up to this) --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Will Price [SMTP:wprice@pgp.com] > Sent: Monday, July 02, 2001 4:05 PM > To: Herbert, Howard C > Cc: ipsec@lists.tislabs.com > Subject: Re: Is Anyone in the IPsec WG Writing a Draft RFC Using AES > CBC MAC for ESP Integrity? > > Already written: > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-01.txt > > > > > "Herbert, Howard C" wrote: > > > > If not, I would like to write it. I am a participant in the IP Storage > WG > > and we would like to use this algorithm for our iSCSI RFCs. > > > > Howard Herbert > > > > Product Architect > > Intel Corporation > > LAN Access Division > > 480-554-3116 > > -- > > Will Price, Director of Engineering > PGP Security, Inc. > a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Tue Jul 3 07:00:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63E0Rm14163; Tue, 3 Jul 2001 07:00:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05213 Tue, 3 Jul 2001 08:56:35 -0400 (EDT) X-Authentication-Warning: morphine.tml.hut.fi: helger owned process doing -bs Date: Tue, 3 Jul 2001 01:01:18 +0300 (EET DST) From: Helger Lipmaa To: "Herbert, Howard C" cc: "'wprice@pgp.com'" , Subject: RE: Is Anyone in the IPsec WG Writing a Draft RFC Using AES CBC M AC for ESP Integrity? In-Reply-To: <3677E033A5F3D211AC4000A0C96B53EB05C2EA46@FMSMSX94> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 2 Jul 2001, Herbert, Howard C wrote: > > This draft covers AES in CBC mode for ESP confidentiality. > > I need one on AES in CBC "MAC" mode for ESP integrity. MAC mode for DES is > standardized in FIPS PUB 113. We need an AES version of this standard. I would recommend to hold your breath until the NIST has standardised this mode. The new NIST modes workshop is going to happen at the end of August (see http://www.nist.gov/modes). CBC MAC is currently not on the list, but there are a few alternative possibilities. Moreover, CBC MAC has recently been extended so that it would be secure for arbitrary message lengths... So that standardising effort might take more than just writing a draft. Helger From owner-ipsec@lists.tislabs.com Tue Jul 3 07:17:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63EHOm14589; Tue, 3 Jul 2001 07:17:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05290 Tue, 3 Jul 2001 09:36:19 -0400 (EDT) Message-ID: <3B41CBD5.A66149DA@certicom.com> Date: Tue, 03 Jul 2001 09:42:45 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Hilarie Orman CC: sandy@storm.ca, ipsec@lists.tislabs.com Subject: Re: [Fwd: Re: P1363: prudent fields] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The security risk justified by performance should never be taken, especially given the fact that there is no significant difference in performance while comparing 155-bit and 163-bit curves. Thanks, Yuri Hilarie Orman wrote: > > Composite exponents permit implementation using field > towers and lead to performance advantages. > > Hilarie > > >>> Sandy Harris 06/26/01 11:48AM >>> > Hilarie Orman wrote: > > > > Given that the groups have no demonstrated mathematical > > weaknesses > > However, enough problems with composite exponents have shown up > that we just got this advice from a wel--known crytographer: > > | More generally, we recommend that elliptic curves over GF(2^n) > | where be n is composite be avoided, including elliptic curves > | over GF(2^185). > > > and that they have significant computational performance advantages, > > If performance depends only on the size of exponent, then those > groups -- 2^155 and 2^185 -- have about the same performance as > the group using 2^163. > > > there appears to be no reason to drop them. > > I'd say there's enough doubt that the cautious course would be to > drop them. From owner-ipsec@lists.tislabs.com Tue Jul 3 07:40:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63Eetm15039; Tue, 3 Jul 2001 07:40:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05349 Tue, 3 Jul 2001 09:55:38 -0400 (EDT) X-Authentication-Warning: morphine.tml.hut.fi: helger owned process doing -bs Date: Tue, 3 Jul 2001 01:07:36 +0300 (EET DST) From: Helger Lipmaa To: "Herbert, Howard C" cc: "'wprice@pgp.com'" , Subject: RE: Is Anyone in the IPsec WG Writing a Draft RFC Using AES CBC M AC for ESP Integrity? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 3 Jul 2001, Helger Lipmaa wrote: > I would recommend to hold your breath until the NIST has standardised this > mode. The new NIST modes workshop is going to happen at the end of August > (see http://www.nist.gov/modes). CBC MAC is currently not on the list, but > there are a few alternative possibilities. > > Moreover, CBC MAC has recently been extended so that it would be secure > for arbitrary message lengths... So that standardising effort might take > more than just writing a draft. Still, a correction: The XCBC (MAC) mode by Black and Rogaway is equal to the 'extended CBC MAC' mode. Helger From owner-ipsec@lists.tislabs.com Tue Jul 3 08:03:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63F3fm18945; Tue, 3 Jul 2001 08:03:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05570 Tue, 3 Jul 2001 10:20:55 -0400 (EDT) Message-ID: <4652644B98DFF34696801F8F3070D3FE1E18D0@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Ari.Huttunen@F-Secure.com'" , "'wdixon@microsoft.com'" , "'kivinen@ssh.fi'" Cc: ipsec@lists.tislabs.com Subject: Question on Section 3.8 of draft-ietf-ipsec-udp-encaps-00.txt Date: Tue, 3 Jul 2001 14:25:42 -0000 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 In the the picture of Section 3.8, the UDP hdr is protected by the AH authentication. It seems wrong to me since the UDP header is added after the AH is calculated. Please clarify. From owner-ipsec@lists.tislabs.com Tue Jul 3 08:11:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63FBDm19144; Tue, 3 Jul 2001 08:11:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05555 Tue, 3 Jul 2001 10:16:53 -0400 (EDT) Message-ID: <002301c103cc$d814d460$0e0a000a@dhcp.atrium.rennes.artful.net> From: "Guillaume Le Malet" To: Subject: IPSEC LINUX SERVER Date: Tue, 3 Jul 2001 16:31:27 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C103DD.9B6FB690" 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 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0020_01C103DD.9B6FB690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to know if freeS/wan is a client/server Ipsec system or = simply a client system. I'm also interested in other linux ipsec server solution. Thx Guillaume =20 ------=_NextPart_000_0020_01C103DD.9B6FB690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I would like to know if freeS/wan is a client/server Ipsec system or simply = a client system.
I'm also interested in other linux = ipsec server=20 solution.
 
Thx
 
Guillaume   =20
------=_NextPart_000_0020_01C103DD.9B6FB690-- From owner-ipsec@lists.tislabs.com Tue Jul 3 08:28:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63FS8m19549; Tue, 3 Jul 2001 08:28:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA05630 Tue, 3 Jul 2001 10:44:23 -0400 (EDT) To: "Guillaume Le Malet" Cc: Subject: Re: IPSEC LINUX SERVER References: <002301c103cc$d814d460$0e0a000a@dhcp.atrium.rennes.artful.net> From: Derek Atkins Date: 03 Jul 2001 10:50:29 -0400 In-Reply-To: "Guillaume Le Malet"'s message of "Tue, 3 Jul 2001 16:31:27 +0200" Message-ID: Lines: 22 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Guillaume Le Malet" writes: > Hi, > I would like to know if freeS/wan is a client/server Ipsec system or = > simply a client system. > I'm also interested in other linux ipsec server solution. > > Thx > > Guillaume =20 IPSec is, by definition, Peer-to-peer. There is no concept within IPSec of a 'client' or 'server'. There is 'initiator' and 'responder'. And yes, FreeS/WAN can both initiate and respond. -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 Tue Jul 3 10:11:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63HBDm23096; Tue, 3 Jul 2001 10:11:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05857 Tue, 3 Jul 2001 12:22:45 -0400 (EDT) Message-ID: <3B41F2C1.B3FE308@storm.ca> Date: Tue, 03 Jul 2001 12:28:49 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Guillaume Le Malet CC: ipsec@lists.tislabs.com Subject: Re: IPSEC LINUX SERVER References: <002301c103cc$d814d460$0e0a000a@dhcp.atrium.rennes.artful.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Guillaume Le Malet wrote: > > Hi, > I would like to know if freeS/wan is a client/server Ipsec system or simply a > client system. The terms do not fit IPSEC which is peer-to-peer. See www.freeswan.org > I'm also interested in other linux ipsec server solution. There are (possibly incomplete) lists in FreeS/WAN docs: http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/web.html#implement From owner-ipsec@lists.tislabs.com Tue Jul 3 12:22:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f63JMfm26718; Tue, 3 Jul 2001 12:22:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06043 Tue, 3 Jul 2001 14:23:29 -0400 (EDT) Message-ID: <3B420F23.BE8AAEDC@certicom.com> Date: Tue, 03 Jul 2001 14:29:55 -0400 From: Yuri Poeluev Organization: Certicom Corp. X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Sandy Harris CC: Guillaume Le Malet , ipsec@lists.tislabs.com Subject: Re: IPSEC LINUX SERVER References: <788D6C2BCAA8518D85256A7E005C814F.005CB9F585256A7E@certicom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, We also use "host" and "gateway" terminology, which might be considered as "client" and "server". But because IPSec allows gateway-to-gateway and host-to-host connections, then server-to-server and client-to-client connections don't really make sense. That's why we use peer-to-peer and initiator/responder terms. -Yuri Sandy Harris wrote: > > > Guillaume Le Malet wrote: > > > > Hi, > > I would like to know if freeS/wan is a client/server Ipsec system or > simply a > > client system. > > The terms do not fit IPSEC which is peer-to-peer. > > See www.freeswan.org > > > I'm also interested in other linux ipsec server solution. > > There are (possibly incomplete) lists in FreeS/WAN docs: > > http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/web.html#implement From owner-ipsec@lists.tislabs.com Tue Jul 3 22:26:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f645QKm11231; Tue, 3 Jul 2001 22:26:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07189 Wed, 4 Jul 2001 00:34:19 -0400 (EDT) Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.104 (Entity 4.117) From: "Amey Gokhale" Subject: Re: IPSEC LINUX SERVER To: ipsec@lists.tislabs.com Date: Wed, 04 Jul 2001 05:40:36 +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: Wed Jul 4 05:40:36 2001; Local host: pmweb5.uk1.bibliotech.net; Remote host: 202.54.40.40; Referer site: www.postmaster.co.uk X-Complaints-To: Administrator@postmaster.co.uk Message-Id: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk i agree with yuri tht we use "host" and "gateway" terminology. But i would like to go little bit deeper. Can anybody point out the IPSec implementation differences for "host" and "gateway". There must be some difference in host IPSec implementation and gateway IPSec implementation. So anybody can throw some light on...wht r those differences?? Thanks in advance Regards Amey. From owner-ipsec@lists.tislabs.com Wed Jul 4 06:35:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f64DZQm26608; Wed, 4 Jul 2001 06:35:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08747 Wed, 4 Jul 2001 08:42:32 -0400 (EDT) Message-ID: <3B4310AB.E8EFB8C6@F-Secure.com> Date: Wed, 04 Jul 2001 15:48:43 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Amey Gokhale CC: ipsec@lists.tislabs.com, glemalet@rennes.artful.net Subject: Re: IPSEC LINUX SERVER References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Amey Gokhale wrote: > > i agree with yuri tht we use "host" and "gateway" > terminology. But i would like to go little bit deeper. > > Can anybody point out the IPSec implementation differences > for "host" and "gateway". There must be some difference in > host IPSec implementation and gateway IPSec implementation. > So anybody can throw some light on...wht r those differences?? > > Thanks in advance > Regards > Amey. It's possible to create a client implementation with very little intelligence in it. Just push a button to connect/disconnect. Some hardware gateway vendors ship those for free (for Windows, probably). Gateway implementations need to take much more into account, like having multiple physical interfaces, many concurrent connections, connections to RADIUS servers, remote configuration, whatever. Gateways usually cost money, unless they spell freeswan. If you need a full implementation for Linux kernel versions 2.2.19 or 2.4.2 (other versions may work), you can contact F-Secure (not me). We also support Solaris 2.6 , 7 , 8. And sorry for misuse of this mailing list.. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Wed Jul 4 06:57:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f64Dvam27049; Wed, 4 Jul 2001 06:57:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08783 Wed, 4 Jul 2001 09:17:18 -0400 (EDT) Message-ID: <3B4318CC.CC2690C4@F-Secure.com> Date: Wed, 04 Jul 2001 16:23:24 +0300 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wang, Cliff" CC: "'wdixon@microsoft.com'" , "'kivinen@ssh.fi'" , ipsec@lists.tislabs.com Subject: Re: Question on Section 3.8 of draft-ietf-ipsec-udp-encaps-00.txt References: <4652644B98DFF34696801F8F3070D3FE1E18D0@D2CSPEXM001.smartpipes.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Wang, Cliff" wrote: > > In the the picture of Section 3.8, the UDP hdr is protected by the AH > authentication. > It seems wrong to me since the UDP header is added after the AH is > calculated. > Please clarify. Yes, it's a typo. The UDP header is not to be authenticated. Ari -- Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Wed Jul 4 07:40:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f64Eenm27851; Wed, 4 Jul 2001 07:40:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08909 Wed, 4 Jul 2001 10:00:33 -0400 (EDT) Message-ID: <001401c10493$bae70350$0e0a000a@dhcp.atrium.rennes.artful.net> From: "Guillaume Le Malet" To: Subject: IPSEC: Freeswan/Securemote Date: Wed, 4 Jul 2001 16:15:08 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C104A4.7E3BCB00" 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 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0011_01C104A4.7E3BCB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'd like to know if someone already experienced=20 Freeswan (linux) with securemote (windows). And if you know any documentation about it, I would be interested. Thanks Guillaume ------=_NextPart_000_0011_01C104A4.7E3BCB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I'd like to know if someone already = experienced=20
Freeswan (linux) with securemote=20 (windows).
And if you know any documentation about = it,
I would be interested.
 
Thanks
 
Guillaume
------=_NextPart_000_0011_01C104A4.7E3BCB00-- From owner-ipsec@lists.tislabs.com Wed Jul 4 08:20:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f64FKrm28458; Wed, 4 Jul 2001 08:20:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09005 Wed, 4 Jul 2001 10:48:13 -0400 (EDT) Date: Wed, 4 Jul 2001 10:54:27 -0400 From: Ramin Alidousti To: Guillaume Le Malet Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC: Freeswan/Securemote Message-ID: <20010704105426.A7060@uu.net> References: <001401c10493$bae70350$0e0a000a@dhcp.atrium.rennes.artful.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <001401c10493$bae70350$0e0a000a@dhcp.atrium.rennes.artful.net>; from glemalet@rennes.artful.net on Wed, Jul 04, 2001 at 04:15:08PM +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Jul 04, 2001 at 04:15:08PM +0200, Guillaume Le Malet wrote: > Hi, > I'd like to know if someone already experienced > Freeswan (linux) with securemote (windows). > And if you know any documentation about it, > I would be interested. Please post your FreeS/Wan questions to the FreeS/Wan mailing list: users@lists.freeswan.org Of course, after searching the archive and the online docs: http://lists.freeswan.org/pipermail/users/ http://www.freeswan.org/doc.html Ramin > > Thanks > > Guillaume From owner-ipsec@lists.tislabs.com Thu Jul 5 08:27:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f65FRAm12681; Thu, 5 Jul 2001 08:27:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11436 Thu, 5 Jul 2001 10:25:00 -0400 (EDT) Message-Id: <200107051423.KAA14187@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipsec@lists.tislabs.com From: The IESG Subject: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode to Proposed Standard Date: Thu, 05 Jul 2001 10:23:59 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has approved the Internet-Draft 'DHCPv4 Configuration of IPSEC Tunnel Mode' as a Proposed Standard. This document is the product of the IPSEC Remote Access (IPSRA) Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Technical Summary This protocol provides a mechanism for IPSEC tunnel configuration using the existing DHCP, IKE and IPSEC protocols. It defines a new HTYPE for IPSEC virtual interfaces, and describes the steps necessary to make DHCP work correctly and securely for IPSEC tunnel configuration. Working Group Summary The competitor to this protocol, IKECFG, has been largely dismissed by both the IPSEC and IPSRA working groups. There was no significant dissent during the LAST CALL period. The document outlines why it is a more appropriate solution than IKECFG. Protocol Quality This document was reviewed by Marcus Leech. At least two implementations are known to exist. From owner-ipsec@lists.tislabs.com Fri Jul 6 05:14:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66CEbm01284; Fri, 6 Jul 2001 05:14:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA14099 Fri, 6 Jul 2001 07:06:33 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com User-Agent: Microsoft-Entourage/9.0.1.3108 Date: Fri, 06 Jul 2001 12:12:23 +0100 Subject: FW: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode to Proposed Standard From: Dirk Rosler To: IPSec Message-ID: In-Reply-To: <200107051423.KAA14187@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, does someone know which are the two existing client implementations? Also, what amendments to IPSec gateway are necessary (if any)? Dirk ------ Forwarded Message From: The IESG Date: Thu, 05 Jul 2001 10:23:59 -0400 To: IETF-Announce: ; Cc: RFC Editor Subject: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode to Proposed Standard The IESG has approved the Internet-Draft 'DHCPv4 Configuration of IPSEC Tunnel Mode' as a Proposed Standard. This document is the product of the IPSEC Remote Access (IPSRA) Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. Technical Summary This protocol provides a mechanism for IPSEC tunnel configuration using the existing DHCP, IKE and IPSEC protocols. It defines a new HTYPE for IPSEC virtual interfaces, and describes the steps necessary to make DHCP work correctly and securely for IPSEC tunnel configuration. Working Group Summary The competitor to this protocol, IKECFG, has been largely dismissed by both the IPSEC and IPSRA working groups. There was no significant dissent during the LAST CALL period. The document outlines why it is a more appropriate solution than IKECFG. Protocol Quality This document was reviewed by Marcus Leech. At least two implementations are known to exist. ------ End of Forwarded Message From owner-ipsec@lists.tislabs.com Fri Jul 6 06:43:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66DhMm02675; Fri, 6 Jul 2001 06:43:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14268 Fri, 6 Jul 2001 08:56:37 -0400 (EDT) Message-ID: <1742200175614241770@EAGLE> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 Reply-To: res02mg1@gte.net X-MSMail-Priority: Normal From: "David C. Dickson" To: IPSEC@lists.tislabs.com Subject: Network and Info Systems Security Training Conference - Wash DC, 16 July 2001 Date: Thu, 5 Jul 2001 21:42:41 -0400 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id VAA12785 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To: IPSEC@LISTS.TISLABS.COM NEW SPEAKERS ADDED PLEASE FORWARD THIS TO YOUR MANAGER OF SYSTEMS SECURITY, TRENDS, AND SECURITY TECHNOLOGIES GROUP. Market*Access International is proud to present .... NETWORK AND INFORMATION SYSTEMS SECURITY - TRAINING CONFERENCE AGENCY INTRUSION DETECTION REQUIREMENTS and TECHNOLOGY SOLUTIONS Date: July 16, 2001 Ronald Reagan Building and International Trade Center 1300 Pennsylvania Avenue Washington D.C. Atrium Ballroom Time: 7:30 AM Registration and Continental Breakfast Program Starts: 8:30 AM Wrap-up: 4:15 PM About this Conference: As government becomes more dependent on e-business, databases, information storehouses, mission critical information storage and information sharing, new risks are posed. These risks may come from student hackers, foreign governments or foreign military, terrorist organizations or even internal users. With the new e-Government applications and communications, computer security has emerged as a top issue and challenge. This conference will highlight the risks, opportunities and innovative management and technical approaches to the detection and response to unauthorized intrusions into agency data. The conference will focus on business and military applications and agency plans and programs for securing these applications. A highlight of this conference will be a section on AGENCY REQUIREMENTS AND NEW TECHNOLOGIES and strategies of coping with unauthorized attempts to compromise agency and DoD systems and data. SPEAKERS WILL REPRESENT THE FOLLOWING AGENCIES/COMPANIES: Navy NMCI ­ Mark Lavoie ­ Communications Officer, CDR, USNR PEO IT (Program Executive Office of Information Technology). Department of Transportation - Bonnie Fisher ­ Director, TASC Millennium Solutions Center National Science Foundation - Dara Murry ­ Director, ADP Security FBI - James Burrell ­ Acting Unit Chief, Computer Investigation Unit DARPA - Jim Webster ­ Manager, Information Assurance Office GSA/FedCIRC - Larry Hale ­ Liaison Director, Federal Computer Incident Response Center DOJ ­ TBD DISA ­ TBD Gartner ­ Keynote ­ TBD Guardant ­ Robert Lee ­ Director, Senior Principal Consultant Global Integrity - Errol Weiss, Bill Morgan Verizon, Federal Network Systems - Char Sample ­ Raytheon ­ Barton Abbott ­ Director, Information Assurance, Navy /USMC Intranet, Information Strike Force Symantec - TBD For more information on speakers and the conference agenda, please visit our web site at www.marketaccess.org. Who should attend: * Agency IT Executives, Managers, and Staff * Agency Security Executives, Managers and Staff * Agency information systems program managers * Agency Telecommunications Executives, Managers and Staff * Tele-work and Telecomm Directors, Managers, and Staff * Functional area managers * Systems integrators that support federal agency security requirements * Hardware and software solutions providers What you will learn: * Agency plans, programs and priorities * Successes and Lessons learned * Innovative government intrusion detection security approaches and applications * New technologies and strategies - what is on the drawing boards * How the military approaches network security and intrusion detection * Security of remote database management * How to structure intrusion detection solutions * Risks, sources of attacks... the internal risk * Commercial and government best practices Corporate Sponsors: * Symantec * Verizon * Market*Access .... others to be announced Organizational Sponsors: * Department of Transportation * INPUT Government ....other sponsors to be announced. Please register early. The conference area has limited seating available and we anticipate a sell out. Points of Contact: * For technical support with this web site, please contact Mr. Parrish Knight, 703/807-2748 * For general information about this event, please contact Ms. Kristen Brooks, 703/807-2745 * For information on sponsorship opportunities & exhibitor arrangements, please contact Ms. Cara Lombardi at 703/807-2743 The registration fee for this important training conference is: * Government Credit Card or Check in Advance: $395 * Government Training Forms/Invoice: $445 * Industry and Federal Contractors, Payment in Advance: $595 * Industry and Federal Contractors/Invoice: $645 We accept government training forms and government and commercial credit cards (VISA, MC, American Express). Options: [1] Phone: 703-807-2745 and speak with Ms. Kristen Brooks. [2] Email: kbrooks@marketaccess.org [3] Register online: Use our online booking form to register and pay by credit card electronically. To register, go to www.marketaccess.org. [4] Fax: registration form to 301-652-0914. [5] Mail: registration form to: Market*Access International, Inc. 4301 Wilson Blvd. #1003 Arlington, VA 22203 Sponsorships Available! For sponsorship information, please contact: Cara Lombardi Market*Access International 4301 Wilson Blvd. #1003 Arlington, VA 22203 Phone (703) 807-2743 Fax (703) 807-2728 clombardi@marketaccess.org If you wish to be REMOVED from this list, please REPLY and place REMOVE in the SUBJECT line. Thank you From owner-ipsec@lists.tislabs.com Fri Jul 6 08:45:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66Fjjm09029; Fri, 6 Jul 2001 08:45:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14702 Fri, 6 Jul 2001 10:44:14 -0400 (EDT) From: Internet-Drafts@ietf.org X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 16:51:09 2001 Envelope-to: david@REPLICANTS.FREESERVE.CO.UK Delivery-date: Tue, 26 Jun 2001 16:51:09 +0100 Message-Id: <200106261101.HAA27044@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, ippcp@external.cisco.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shacham-ippcp-rfc2393bis-07.txt Date: Tue, 26 Jun 2001 07:01:20 -0400 X-OriginalArrivalTime: 06 Jul 2001 14:54:49.0155 (UTC) FILETIME=[9AAE2930:01C1062B] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Payload Compression Protocol (IPComp) Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas Filename : draft-shacham-ippcp-rfc2393bis-07.txt Pages : 11 Date : 25-Jun-01 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-07.txt 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-shacham-ippcp-rfc2393bis-07.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-shacham-ippcp-rfc2393bis-07.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: <20010625095435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-shacham-ippcp-rfc2393bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Con From owner-ipsec@lists.tislabs.com Fri Jul 6 09:03:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66G3lm09559; Fri, 6 Jul 2001 09:03:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14804 Fri, 6 Jul 2001 11:19:02 -0400 (EDT) Reply-To: From: "Sridhar J" To: "Ipsec" Subject: rsa configuration Date: Fri, 6 Jul 2001 20:00:45 +0530 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="----=_NextPart_000_0090_01C10656.584D4E60" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0090_01C10656.584D4E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi , rsa public key is represented as {modulus ,exponent} , my question is should I configure both modulus and exponent (no certificates in my implementation ) . I have seen in cisco router that it has option of configuring rsa public key as just a string not seperately as mod and exponent , I wonder how cisco router is splitting that key (into mod and exponent) any pointer would be of great help re sridhara .j senior software engineer future software ltd , India ------=_NextPart_000_0090_01C10656.584D4E60 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+Ii0OAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHBwAGABQAAAAAAAUA/gAB A5AGAMQFAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAEgAAAHJzYSBjb25maWd1cmF0aW9uAAAAAgFxAAEAAAAWAAAAAcEGKDKJiLWkd2ogEdWLzQDQ CW+ewAAAAgEdDAEAAAAhAAAAU01UUDpTUklESEFSSkBGVVRVUkUuRlVUU09GVC5DT00AAAAACwAB DgAAAABAAAYOACQTIygGwQECAQoOAQAAABgAAAAAAAAAq7euabFWvRGJhQAgNbHZkMKAAAALAB8O AQAAAAIBCRABAAAADwIAAAsCAADWAgAATFpGdSRjBDIDAAoAcmNwZzEyNQYyAPgLYG5nMzA4njEB 9wKkBPQCAGNoCsCgc2V0MCAIUG0N4DcGBAXgAoB9CoAIyCA7uwliDiA4CbsCgAqBdgiQpHdrC4Bk NAxgYwBQDQsDYwBBC7Q0IEhpXCAsCqIKgQGRIBEgYRggcHUCYBGxa2V55iAEABfAZXAJcBEwAjCp CYAgYQQhewRhdQpAYQQgLGV4cAIgGVFcpH0gFwAgbRigcQpQmHN0aQIgGLJzaAhgEmwZkEkgBaBu ZmmSZwhwZSAG4HRoFyQfGgYAcBmQGpYbMChub88c4ASQG+AdIGNhGXAEIO8LgBtiB3ALUGUHgAIw IFC9G/IpCuMKgBswInYuGzB7HNARAHYdcBEwCfAgkmP/BAAFoBfACGAZcAXAHbAgUG8YsAVAEQAE IG8FMBvyb3ZmHOcLgGcXJBfdGbFq3xpQBUAX8BvQJtIgH6AFQO0RMHAEkCBRbChDBGEerLsbUBzQ dwIgBIEjUG8H4P8kOhckHDILUCVQG+ApQSUD9RiCKAuAdB+wKp4h9heDfwBwGKAasC8hJNEr4ByS Yq8dcCYxCcElIWgqIHAXJdczeR1hFyRzBRBkEQEX8LwuajS1CfAb8AXAcyYw3HR3CsAdcAnwZwuA CeCdLUVmJLAdUjaXbHQZkF8roRVQBzAXJBJxADpQAAsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOF AAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAA RgAAAABShQAAP3EBAB4AJYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAADACaA CCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAL4AIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAA AAAAAwAwgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADADKACCAGAAAAAADAAAAAAAAARgAA AAAYhQAAAAAAAAsA7YAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwDxgAggBgAAAAAAwAAA AAAAAEYAAAAAgoUAAAEAAAACAfgPAQAAABAAAACrt65psVa9EYmFACA1sdmQAgH6DwEAAAAQAAAA q7euabFWvRGJhQAgNbHZkAIB+w8BAAAATQAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlgu RExMAAAAAAAAAABOSVRB+b+4AQCqADfZbgAAAEQ6XG1haWxcb3V0bG9vay5wc3QAAAAAAwD+DwUA AAADAA00/TcAAAIBfwABAAAAOwAAADxMTkJCSUpJRktMSkhKTE5JR0lNR09FT0xITkFCLnNyaWRo YXJqQGZ1dHVyZS5mdXRzb2Z0LmNvbT4AAAMABhB/LyVWAwAHEHsBAAADABAQAAAAAAMAERAAAAAA HgAIEAEAAABlAAAASEksUlNBUFVCTElDS0VZSVNSRVBSRVNFTlRFREFTTU9EVUxVUyxFWFBPTkVO VCxNWVFVRVNUSU9OSVNTSE9VTERJQ09ORklHVVJFQk9USE1PRFVMVVNBTkRFWFBPTkVOVChOTwAA AAALQw== ------=_NextPart_000_0090_01C10656.584D4E60-- From owner-ipsec@lists.tislabs.com Fri Jul 6 09:29:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66GTnm10041; Fri, 6 Jul 2001 09:29:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14884 Fri, 6 Jul 2001 11:43:47 -0400 (EDT) Message-ID: <49B96FCC784BC54F9675A6B558C3464E2856B2@MAIL.NetOctave.com> From: Sadiki Mwanyoha To: "'ipsec@lists.tislabs.com'" Subject: VPN Bakeoff Date: Fri, 6 Jul 2001 11:48:37 -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 I would like to know technical details regarding the VPN bakeoff in Finland. Can someone direct me to some information about what new participants can expect? The site http://bakeoff.ipsec.com is very basic and doesn't satisfy my curiosity? Sadiki Mwanyoha Software Engineer NetOctave, Inc. P.O. Box 14824 Research Triangle Park North Carolina 27709 919.463.9903 x306 919.463.9905 (fax) smwanyoha@netoctave.com From owner-ipsec@lists.tislabs.com Fri Jul 6 10:16:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66HGtm11040; Fri, 6 Jul 2001 10:16:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15018 Fri, 6 Jul 2001 12:40:15 -0400 (EDT) To: Cc: "Ipsec" Subject: Re: rsa configuration References: From: Derek Atkins Date: 06 Jul 2001 12:46:30 -0400 In-Reply-To: "Sridhar J"'s message of "Fri, 6 Jul 2001 20:00:45 +0530" Message-ID: Lines: 26 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Sridhar J" writes: > Hi , > rsa public key is represented as {modulus ,exponent} , my question > is should I configure both > modulus and exponent (no certificates in my implementation ) > . I have seen in cisco router that it has option of configuring > rsa public key as just a string not seperately as mod and exponent , I > wonder how cisco router > is splitting that key (into mod and exponent) > any pointer would be of great help > How you implement it is up to you. Different implementations store the information differently. For example, FreeS/WAN stores an RSA key as a single string of hex digits, first the exponent and then the modulus, with length encodings to split the two. How you store it locally is up to you. -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 Fri Jul 6 10:20:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66HKJm11101; Fri, 6 Jul 2001 10:20:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14992 Fri, 6 Jul 2001 12:36:20 -0400 (EDT) From: porcher@tril-inc.com To: Cc: "Ipsec" Subject: Re: rsa configuration MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: Date: Fri, 6 Jul 2001 12:48:00 -0400 X-MIMETrack: Serialize by Router on lntril01/Servers/Trilogy(Release 5.0.6a |January 17, 2001) at 07/06/2001 12:48:31 PM, Serialize complete at 07/06/2001 12:48:31 PM Content-Type: multipart/alternative; boundary="=_alternative 005BBC9485256A81_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 005BBC9485256A81_= Content-Type: text/plain; charset="us-ascii" > rsa public key is represented as {modulus ,exponent} , my question > is should I configure both > modulus and exponent (no certificates in my implementation ) > . I have seen in cisco router that it has option of configuring > rsa public key as just a string not seperately as mod and exponent , I > wonder how cisco router > is splitting that key (into mod and exponent) > any pointer would be of great help The Cisco router we have accepts/displays an RSA Public Key in the ASN.1 DER form of a SubjectPublicKeyInfo object. This object is defined in X.509, and also in PKCS#6 and RFC 2459, among other places. The SubjectPublicKeyInfo includes the algorithm & key; the key contains the modulus & exponent. ---- Tom Porcher | porcher@tril-inc.com voice: 978.371.3980 x108 Software Consultant | http://www.tril-inc.com fax: 978.371.3990 Trilogy, Inc. .: | Concord, Massachusetts, USA, Earth --=_alternative 005BBC9485256A81_= Content-Type: text/html; charset="us-ascii"
>                  rsa public key is represented as {modulus ,exponent}  , my question
> is should I configure both
> modulus and exponent  (no certificates in my implementation )
>           .  I have seen in cisco router that it has option of configuring
> rsa public key as just a string not seperately as mod and exponent , I
> wonder how cisco router
> is splitting that key (into mod and exponent)
>                 any pointer would be of great help
The Cisco router we have accepts/displays an RSA Public Key in the ASN.1 DER form
of a SubjectPublicKeyInfo object.  This object is defined in X.509, and also in
PKCS#6 and RFC 2459, among other places.  The SubjectPublicKeyInfo includes the
algorithm & key; the key contains the modulus & exponent.

----
Tom Porcher          |  porcher@tril-inc.com    voice: 978.371.3980 x108
Software Consultant  |  http://www.tril-inc.com   fax: 978.371.3990
Trilogy, Inc.  .:    |  Concord, Massachusetts, USA, Earth --=_alternative 005BBC9485256A81_=-- From owner-ipsec@lists.tislabs.com Fri Jul 6 11:25:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66IPHm12770; Fri, 6 Jul 2001 11:25:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15226 Fri, 6 Jul 2001 13:38:54 -0400 (EDT) From: "Scott G. Kelly" To: Dirk Rosler Cc: IPSec Message-ID: <3B45F93E.42B4A35F@redcreek.com> Date: Fri, 06 Jul 2001 10:45:34 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: FW: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dirk Rosler wrote: > > Hi, > > does someone know which are the two existing client implementations? RedCreek has a fielded implementation. > > Also, what amendments to IPSec gateway are necessary (if any)? The required modifications are documented in the draft. Scott From owner-ipsec@lists.tislabs.com Fri Jul 6 11:50:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66Iodm13246; Fri, 6 Jul 2001 11:50:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15333 Fri, 6 Jul 2001 14:03:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3B45F93E.42B4A35F@redcreek.com> References: <3B45F93E.42B4A35F@redcreek.com> Date: Fri, 6 Jul 2001 14:04:55 -0400 To: "Scott G. Kelly" From: Stephen Kent Subject: Re: FW: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard Cc: IPSec Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, Are you saying that this newly approved protocol is inconsistent with 2401? if so, such differences should have been reconciled with the IPsec WG prior to publication. Steve From owner-ipsec@lists.tislabs.com Fri Jul 6 13:13:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66KDwm15135; Fri, 6 Jul 2001 13:13:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15566 Fri, 6 Jul 2001 15:06:16 -0400 (EDT) Reply-To: From: "Saqib Jang" To: Cc: "Saqib Jang" Subject: IPsec gateway vs. host Date: Fri, 6 Jul 2001 11:23:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is there a scenario where IPsec implemented in a NIC or a HBA can be considered a "gateway" IPsec implementation. I'm trying to reconcile the proposal for iSCSI devices to only support tunnel-mode IPsec with the requirement in RFC 2401 that only IPsec "gateways" can support only tunnel-mode IPsec, whereas "hosts' are required to support both tunnel and transport mode IPsec. Saqib Jang Margalla Communications, Inc. 3301 El Camino Real, Suite 220 Atherton, CA 94027 Ph: 650 298 8462 Fax: 650 851 1613 www.margallacomm.com From owner-ipsec@lists.tislabs.com Fri Jul 6 13:37:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66Kbfm15596; Fri, 6 Jul 2001 13:37:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA15779 Fri, 6 Jul 2001 15:53:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 6 Jul 2001 15:57:01 -0400 To: From: Stephen Kent Subject: Re: IPsec gateway vs. host Cc: , "Saqib Jang" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:23 AM -0700 7/6/01, Saqib Jang wrote: >Is there a scenario where IPsec implemented in a NIC >or a HBA can be considered a "gateway" IPsec implementation. >I'm trying to reconcile the proposal for iSCSI devices to only >support tunnel-mode IPsec with the requirement in RFC 2401 >that only IPsec "gateways" can support only tunnel-mode IPsec, >whereas "hosts' are required to support both tunnel and transport >mode IPsec. depending on where the NIC is used, it might appropriately support SG vs. host Ipsec modes. but, it just sounds like the iSCSCI folks are calling for a subset of IPsec functionality for their environment. a compliant IPsec host implementation could be used in this more restrictive fashion. Steve From owner-ipsec@lists.tislabs.com Fri Jul 6 14:37:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66LbPm16697; Fri, 6 Jul 2001 14:37:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15965 Fri, 6 Jul 2001 16:53:33 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0709C0@corpmx14.us.dg.com> To: kent@bbn.com, ipsec@lists.tislabs.com Subject: RE: IPsec gateway vs. host Date: Fri, 6 Jul 2001 16:55:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > it just sounds like the iSCSI folks are > calling for a subset of IPsec functionality for their environment. That's correct, with the caveat that iSCSI security is very much still a work in progress. From an IPsec architectural perspective, an iSCSI implementation is clearly a "host", not a "gateway". --David (IP Storage WG co-chair) --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Stephen Kent [SMTP:kent@bbn.com] > Sent: Friday, July 06, 2001 3:57 PM > To: saqibj@margallacomm.com > Cc: ipsec@lists.tislabs.com; Saqib Jang > Subject: Re: IPsec gateway vs. host > > At 11:23 AM -0700 7/6/01, Saqib Jang wrote: > >Is there a scenario where IPsec implemented in a NIC > >or a HBA can be considered a "gateway" IPsec implementation. > >I'm trying to reconcile the proposal for iSCSI devices to only > >support tunnel-mode IPsec with the requirement in RFC 2401 > >that only IPsec "gateways" can support only tunnel-mode IPsec, > >whereas "hosts' are required to support both tunnel and transport > >mode IPsec. > > depending on where the NIC is used, it might appropriately support SG > vs. host Ipsec modes. but, it just sounds like the iSCSCI folks are > calling for a subset of IPsec functionality for their environment. a > compliant IPsec host implementation could be used in this more > restrictive fashion. > > Steve From owner-ipsec@lists.tislabs.com Fri Jul 6 15:02:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66M23m17130; Fri, 6 Jul 2001 15:02:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16019 Fri, 6 Jul 2001 17:22:01 -0400 (EDT) From: "Scott G. Kelly" To: Stephen Kent Cc: IPSec Message-ID: <3B462D8F.62351B20@redcreek.com> Date: Fri, 06 Jul 2001 14:28:47 -0700 Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: FW: Protocol Action: DHCPv4 Configuration of IPSEC TunnelMode toProposed Standard References: <3B45F93E.42B4A35F@redcreek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Stephen Kent wrote: > > Scott, > > Are you saying that this newly approved protocol is inconsistent with > 2401? if so, such differences should have been reconciled with the > IPsec WG prior to publication. > > Steve No, I didn't mean to imply any inconsistency with 2401. The "modifications" to the gateway entail enabling DHCP relay, which is entirely independent of the IPsec implementation underneath. Scott From owner-ipsec@lists.tislabs.com Fri Jul 6 15:19:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f66MJwm17423; Fri, 6 Jul 2001 15:19:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16210 Fri, 6 Jul 2001 17:41:03 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard Date: Fri, 6 Jul 2001 14:47:50 -0700 Message-ID: <4EBB5C35607E7F48B4AE162D956666EF339081@guam.corp.axcelerant.com> Thread-Topic: FW: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard Thread-Index: AcEGWxliTJfJsQCQRM2YVm6siM3gpAAChrTA From: "Christopher Gripp" To: "Scott G. Kelly" , "Dirk Rosler" Cc: "IPSec" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA16207 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Isn't Netscreen doing this in their latest code release also? Chris -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Friday, July 06, 2001 10:46 AM To: Dirk Rosler Cc: IPSec Subject: Re: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard Dirk Rosler wrote: > > Hi, > > does someone know which are the two existing client implementations? RedCreek has a fielded implementation. > > Also, what amendments to IPSec gateway are necessary (if any)? The required modifications are documented in the draft. Scott From owner-ipsec@lists.tislabs.com Fri Jul 6 18:50:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f671oTm26949; Fri, 6 Jul 2001 18:50:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA16453 Fri, 6 Jul 2001 20:52:53 -0400 (EDT) Message-ID: <9D048F4A422CD411A56500B0D0209C5B01028C5C@NS-CA> From: Michael Choung Shieh To: "'Christopher Gripp'" , "Scott G. Kelly" , Dirk Rosler Cc: IPSec Subject: RE: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode to Proposed Standard Date: Fri, 6 Jul 2001 17:54:53 -0700 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 Yes, we do support DHCP relay through ipsec tunnel in 2.60 release. -------------------------------------------- Michael Shieh NetScreen Technologies, Inc 350 Oakmead Parkway Sunnyvale, CA 94085 TEL: (408)730-6060 FAX: (408)730-6050 Email: mshieh@netscreen.com -------------------------------------------- -----Original Message----- From: Christopher Gripp [mailto:cgripp@axcelerant.com] Sent: Friday, July 06, 2001 2:48 PM To: Scott G. Kelly; Dirk Rosler Cc: IPSec Subject: RE: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard Isn't Netscreen doing this in their latest code release also? Chris -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Friday, July 06, 2001 10:46 AM To: Dirk Rosler Cc: IPSec Subject: Re: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode toProposed Standard Dirk Rosler wrote: > > Hi, > > does someone know which are the two existing client implementations? RedCreek has a fielded implementation. > > Also, what amendments to IPSec gateway are necessary (if any)? The required modifications are documented in the draft. Scott From owner-ipsec@lists.tislabs.com Mon Jul 9 02:58:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f699wkm10585; Mon, 9 Jul 2001 02:58:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA20312 Mon, 9 Jul 2001 04:49:46 -0400 (EDT) X-Envelope-To: mshieh@netscreen.com User-Agent: Microsoft-Entourage/9.0.1.3108 Date: Mon, 09 Jul 2001 09:55:34 +0100 Subject: Re: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode to Proposed Standard From: Dirk Rosler To: Michael Choung Shieh , "Scott G. Kelly" CC: IPSec Message-ID: In-Reply-To: <9D048F4A422CD411A56500B0D0209C5B01028C5C@NS-CA> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thank you. I'd be very interested in obtaining evaluation versions from those two companies and other vendors. Please contact me privately on this address or under dirk.rosler@bt.com Our main requirements or multi-platform (mainly Win & Mac) and certificate (Baltimore & VeriSign) support. Looking forward to hearing from you. Regards Dirk > > Yes, we do support DHCP relay through ipsec tunnel in 2.60 release. > > -------------------------------------------- > Michael Shieh > NetScreen Technologies, Inc > 350 Oakmead Parkway > Sunnyvale, CA 94085 > TEL: (408)730-6060 > FAX: (408)730-6050 > Email: mshieh@netscreen.com > -------------------------------------------- > > -----Original Message----- > From: Christopher Gripp [mailto:cgripp@axcelerant.com] > Sent: Friday, July 06, 2001 2:48 PM > To: Scott G. Kelly; Dirk Rosler > Cc: IPSec > Subject: RE: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode > toProposed Standard > > > Isn't Netscreen doing this in their latest code release also? > > Chris > > > -----Original Message----- > From: Scott G. Kelly [mailto:skelly@redcreek.com] > Sent: Friday, July 06, 2001 10:46 AM > To: Dirk Rosler > Cc: IPSec > Subject: Re: Protocol Action: DHCPv4 Configuration of IPSEC Tunnel Mode > toProposed Standard > > > Dirk Rosler wrote: >> >> Hi, >> >> does someone know which are the two existing client implementations? > > RedCreek has a fielded implementation. > >> >> Also, what amendments to IPSec gateway are necessary (if any)? > > The required modifications are documented in the draft. > > Scott > From owner-ipsec@lists.tislabs.com Mon Jul 9 04:54:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69Bs4m13011; Mon, 9 Jul 2001 04:54:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA20540 Mon, 9 Jul 2001 07:00:54 -0400 (EDT) Message-Id: <200107091106.HAA08980@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-dpd-00.txt Date: Mon, 09 Jul 2001 07:06:30 -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 : A Traffic-Based Method of Detecting Dead IKE Peers Author(s) : G. Huang, S. Beaulieu, D. Rochefort Filename : draft-ietf-ipsec-dpd-00.txt Pages : 10 Date : 06-Jul-01 This draft describes a method of detecting a dead IKE peer. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to limit the number of IKE messages sent. DPD, like other keepalive mechanisms, is often necessary to perform IKE peer failover, or to reclaim lost resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dpd-00.txt 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-dpd-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-ietf-ipsec-dpd-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: <20010706135045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dpd-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dpd-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010706135045.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jul 9 04:54:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69BsYm13027; Mon, 9 Jul 2001 04:54:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA20568 Mon, 9 Jul 2001 07:09:18 -0400 (EDT) Message-Id: <200107071649.f67GnCL22968@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: per-host keying Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 07 Jul 2001 12:49:12 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- 2401 clearly supports keying of node-to-node tunnels, both for end-systems and gateways. At most bakeoffs that I've been to, there has been another variation on this, which was called per-host (vs per-node) keying. I tell my gateway that I want security between: 1.2.3.0/24 and 4.5.6.0/24 but that I want each combination of hosts that communicate to be seperately keyed. I had assumed that this concept made it into a document somewhere, but I can not find it. Am I blind, or did this concept never get written down anywhere? ] 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: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO0c9hIqHRg3pndX9AQENdQP/dTSK+X/6JMvc4VWoxKLn7LdWmE0BN8/q FCwnMt3sgUymVWzY+BwHGrufE4dSYj3tZo6wsMqwYMriVFuitWgoQKOswgfwZpn5 GRuoR0RWgJdPdxPh9gcRZRdcFtpgwsZLF5xyp80Vgj2jdQOd3vqtTEUy+Kq98bpL UsFbQUpHEgk= =TmW6 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Jul 9 09:49:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69GnKm23102; Mon, 9 Jul 2001 09:49:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21215 Mon, 9 Jul 2001 11:33:57 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281AC@md-exchange1.nai.com> From: "Mason, David" To: "'Michael Richardson'" , ipsec@lists.tislabs.com Subject: RE: per-host keying Date: Mon, 9 Jul 2001 08:38:31 -0700 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 This is handled by specifying in the SPD entry that source and destination values for the SAD are derived by using the value in the packet itself - option a) in section 4.4.1 of RFC 2401. -dave -----Original Message----- From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] Sent: Saturday, July 07, 2001 12:49 PM To: ipsec@lists.tislabs.com Subject: per-host keying -----BEGIN PGP SIGNED MESSAGE----- 2401 clearly supports keying of node-to-node tunnels, both for end-systems and gateways. At most bakeoffs that I've been to, there has been another variation on this, which was called per-host (vs per-node) keying. I tell my gateway that I want security between: 1.2.3.0/24 and 4.5.6.0/24 but that I want each combination of hosts that communicate to be seperately keyed. I had assumed that this concept made it into a document somewhere, but I can not find it. Am I blind, or did this concept never get written down anywhere? ] 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: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO0c9hIqHRg3pndX9AQENdQP/dTSK+X/6JMvc4VWoxKLn7LdWmE0BN8/q FCwnMt3sgUymVWzY+BwHGrufE4dSYj3tZo6wsMqwYMriVFuitWgoQKOswgfwZpn5 GRuoR0RWgJdPdxPh9gcRZRdcFtpgwsZLF5xyp80Vgj2jdQOd3vqtTEUy+Kq98bpL UsFbQUpHEgk= =TmW6 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Jul 9 09:53:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69GrZm23185; Mon, 9 Jul 2001 09:53:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA21302 Mon, 9 Jul 2001 12:08:31 -0400 (EDT) Message-Id: <4.3.2.7.1.20010709095356.00b5eab0@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Jul 2001 10:02:44 -0700 To: Michael Richardson , ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: Re: per-host keying In-Reply-To: <200107071649.f67GnCL22968@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, > 2401 clearly supports keying of node-to-node tunnels, both for >end-systems and gateways. > > At most bakeoffs that I've been to, there has been another variation >on this, which was called per-host (vs per-node) keying. I tell my gateway >that I want security between: > 1.2.3.0/24 and 4.5.6.0/24 > > but that I want each combination of hosts that communicate to be >seperately keyed. *** PLease refer to section 4.4.4 of RFC2401 > I had assumed that this concept made it into a document somewhere, >but I can not find it. Am I blind, or did this concept never get written >down anywhere? -ramana From owner-ipsec@lists.tislabs.com Mon Jul 9 11:50:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69Io3m25512; Mon, 9 Jul 2001 11:50:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21605 Mon, 9 Jul 2001 13:35:47 -0400 (EDT) From: porcher@tril-inc.com To: ipsec@lists.tislabs.com Subject: Multiple certs in an IKE Certificate Payload MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: Date: Mon, 9 Jul 2001 13:47:35 -0400 X-MIMETrack: Serialize by Router on lntril01/Servers/Trilogy(Release 5.0.6a |January 17, 2001) at 07/09/2001 01:48:06 PM, Serialize complete at 07/09/2001 01:48:06 PM Content-Type: multipart/alternative; boundary="=_alternative 006130CF85256A84_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 006130CF85256A84_= Content-Type: text/plain; charset="us-ascii" I'm looking for information on how to deal with the multiple X.509 certificates in the PKCS#7-wrapped Certificate Payload in IKE (RFC 2408). If the PKCS#7 data contains a single X.509 certificate, it is clear that this is the peer's certificate. But if there are more than one, it is not clear which of them is the peer's certificate and which have been included for the certificate path. There is no explicit ordering to the list of certs sent by the peer. Is there a standard mechanism for selecting the peer's certificate? It is possible that the peer's identity is only known by IP address at the time I get a Certificate Payload. The only way to match a certificate with an IP address is with the X.509v3 Extended Attribute of SubjectAltName, with an IPAddress or DNSname component of the GeneralNames. Should such a SubjectAltName be required in this case? If there are any RFC/draft/memo references to which anyone could direct me that would be most helpful. Thanks!! ---- Tom Porcher | porcher@tril-inc.com voice: 978.371.3980 x108 Software Consultant | http://www.tril-inc.com fax: 978.371.3990 Trilogy, Inc. .: | Concord, Massachusetts, USA, Earth --=_alternative 006130CF85256A84_= Content-Type: text/html; charset="us-ascii"
I'm looking for information on how to deal with the multiple X.509 certificates in the PKCS#7-wrapped Certificate Payload in IKE (RFC 2408).

If the PKCS#7 data contains a single X.509 certificate, it is clear that this is the peer's certificate.  But if there are more than one, it is not clear which of them is the peer's certificate and which have been included for the certificate path.

There is no explicit ordering to the list of certs sent by the peer.  Is there a standard mechanism for selecting the peer's certificate?

It is possible that the peer's identity is only known by IP address at the time I get a Certificate Payload.  The only way to match a certificate with an IP address is with the X.509v3 Extended Attribute of SubjectAltName, with an IPAddress or DNSname component of the GeneralNames.  Should such a SubjectAltName be required in this case?
If there are any RFC/draft/memo references to which anyone could direct me that would be most helpful.

Thanks!!
----
Tom Porcher          |  porcher@tril-inc.com    voice: 978.371.3980 x108
Software Consultant  |  http://www.tril-inc.com   fax: 978.371.3990
Trilogy, Inc.  .:    |  Concord, Massachusetts, USA, Earth --=_alternative 006130CF85256A84_=-- From owner-ipsec@lists.tislabs.com Mon Jul 9 12:07:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69J72m25959; Mon, 9 Jul 2001 12:07:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21655 Mon, 9 Jul 2001 14:09:23 -0400 (EDT) Message-ID: <019b01c108a2$bedaa990$872745ab@cisco.com> From: "Scott Fanning" To: , References: Subject: Re: Multiple certs in an IKE Certificate Payload Date: Mon, 9 Jul 2001 11:12:38 -0700 Organization: Cisco Systems MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0196_01C10868.105E96E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0196_01C10868.105E96E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tom It might be better if your local policy on the initiator selects which = identity to present to the peer, coupled with a CERT-REQ payload to = indicate what issuer you will be interested in. You could send all of = them and the CERT-REQ, but then the responder has alot of work to do to = choose the right one (based on the issuer in the CERT-REQUEST payload. Multiple root support makes a CERT-REQUEST payload that is populated = with the issuer a MUST in my opinion. I am not aware of any drafts = discussing this.=20 Scott ----- Original Message -----=20 From: porcher@tril-inc.com=20 To: ipsec@lists.tislabs.com=20 Sent: Monday, July 09, 2001 10:47 AM Subject: Multiple certs in an IKE Certificate Payload I'm looking for information on how to deal with the multiple X.509 = certificates in the PKCS#7-wrapped Certificate Payload in IKE (RFC = 2408).=20 If the PKCS#7 data contains a single X.509 certificate, it is clear = that this is the peer's certificate. But if there are more than one, it = is not clear which of them is the peer's certificate and which have been = included for the certificate path.=20 There is no explicit ordering to the list of certs sent by the peer. = Is there a standard mechanism for selecting the peer's certificate?=20 It is possible that the peer's identity is only known by IP address at = the time I get a Certificate Payload. The only way to match a = certificate with an IP address is with the X.509v3 Extended Attribute of = SubjectAltName, with an IPAddress or DNSname component of the = GeneralNames. Should such a SubjectAltName be required in this case? If there are any RFC/draft/memo references to which anyone could = direct me that would be most helpful.=20 Thanks!!=20 ----=20 Tom Porcher | porcher@tril-inc.com voice: 978.371.3980 = x108=20 Software Consultant | http://www.tril-inc.com fax: 978.371.3990=20 Trilogy, Inc. .: | Concord, Massachusetts, USA, Earth=20 ------=_NextPart_000_0196_01C10868.105E96E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Tom
 
It might be better if your local policy = on the=20 initiator selects which identity to present to the peer, coupled with a = CERT-REQ=20 payload to indicate what issuer you will be interested in. You could = send all of=20 them and the CERT-REQ, but then the responder has alot of work to do to = choose=20 the right one (based on the issuer in the CERT-REQUEST = payload.
 
Multiple root support makes a = CERT-REQUEST payload=20 that is populated with the issuer a MUST in my opinion. I am not aware = of any=20 drafts discussing this.
 
Scott
----- Original Message -----
From:=20 porcher@tril-inc.com
To: ipsec@lists.tislabs.com
Sent: Monday, July 09, 2001 = 10:47=20 AM
Subject: Multiple certs in an = IKE=20 Certificate Payload


I'm looking for = information on=20 how to deal with the multiple X.509 certificates in the PKCS#7-wrapped = Certificate Payload in IKE (RFC 2408).

If the PKCS#7 data contains a single X.509 certificate, it is = clear=20 that this is the peer's certificate.  But if there are more than = one, it=20 is not clear which of them is the peer's certificate and which have = been=20 included for the certificate path.

There is no explicit ordering to the list of certs sent by = the peer.=20  Is there a standard mechanism for selecting the peer's=20 certificate?

It is = possible that=20 the peer's identity is only known by IP address at the time I get a=20 Certificate Payload.  The only way to match a certificate with an = IP=20 address is with the X.509v3 Extended Attribute of SubjectAltName, with = an=20 IPAddress or DNSname component of the GeneralNames.  Should such = a=20 SubjectAltName be required in this case?

If there are any RFC/draft/memo references to which anyone = could direct=20 me that would be most helpful.

Thanks!!
---- =
Tom=20 Porcher          |  porcher@tril-inc.com =  =20  voice: 978.371.3980 x108
Software Consultant  | =  http://www.tril-inc.com   fax: 978.371.3990
Trilogy, Inc.  .:   =  |=20  Concord, Massachusetts, USA, Earth = ------=_NextPart_000_0196_01C10868.105E96E0-- From owner-ipsec@lists.tislabs.com Mon Jul 9 13:09:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f69K9lm27481; Mon, 9 Jul 2001 13:09:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21789 Mon, 9 Jul 2001 15:17:09 -0400 (EDT) Message-Id: <4.3.2.7.1.20010709100604.00be7bb0@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Jul 2001 10:10:44 -0700 To: Michael Richardson , ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: Re: per-host keying In-Reply-To: <200107071649.f67GnCL22968@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Sorry, there was a typing mistake in previous mail It is not section 4.4.4 ( there is no section with that number) . please refer to section 4.4.1 and 4.4.2 if you configure the gateway to extract the selectors from packet you will acheive what you are looking for In this case though the policy is generic, . > 2401 clearly supports keying of node-to-node tunnels, both for >end-systems and gateways. > > At most bakeoffs that I've been to, there has been another variation >on this, which was called per-host (vs per-node) keying. I tell my gateway >that I want security between: > 1.2.3.0/24 and 4.5.6.0/24 > > but that I want each combination of hosts that communicate to be >seperately keyed. > > I had assumed that this concept made it into a document somewhere, >but I can not find it. Am I blind, or did this concept never get written >down anywhere? From owner-ipsec@lists.tislabs.com Mon Jul 9 17:02:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6A02vm03801; Mon, 9 Jul 2001 17:02:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22269 Mon, 9 Jul 2001 19:08:26 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Mon, 09 Jul 2001 16:55:09 -0600 From: "Hilarie Orman" To: Cc: Subject: Re: [Fwd: Re: P1363: prudent fields] 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 SAA22237 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are significant performance differences between using field towers for 155-bit curves that are not available for 163-bit curves. Hilarie >>> Yuri Poeluev 07/03/01 07:42AM >>> The security risk justified by performance should never be taken, especially given the fact that there is no significant difference in performance while comparing 155-bit and 163-bit curves. Thanks, Yuri Hilarie Orman wrote: > > Composite exponents permit implementation using field > towers and lead to performance advantages. > > Hilarie > > >>> Sandy Harris 06/26/01 11:48AM >>> > Hilarie Orman wrote: > > > > Given that the groups have no demonstrated mathematical > > weaknesses > > However, enough problems with composite exponents have shown up > that we just got this advice from a wel--known crytographer: > > | More generally, we recommend that elliptic curves over GF(2^n) > | where be n is composite be avoided, including elliptic curves > | over GF(2^185). > > > and that they have significant computational performance advantages, > > If performance depends only on the size of exponent, then those > groups -- 2^155 and 2^185 -- have about the same performance as > the group using 2^163. > > > there appears to be no reason to drop them. > > I'd say there's enough doubt that the cautious course would be to > drop them. From owner-ipsec@lists.tislabs.com Mon Jul 9 17:02:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6A02vm03802; Mon, 9 Jul 2001 17:02:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22268 Mon, 9 Jul 2001 19:08:26 -0400 (EDT) From: =?iso-8859-1?Q?Torbj=F6rn_Friberg?= To: Subject: SCEP limitations Date: Mon, 9 Jul 2001 21:36:52 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When using SCEP why is it not possible to have a certificate hierarchi. If I would like to have ex. a policy CA and a number of sub-CA's who would isssue certificates to the subcribers, then it will not work?! And when will SCEP support renewal function? Tobbe From owner-ipsec@lists.tislabs.com Mon Jul 9 17:29:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6A0TZm04436; Mon, 9 Jul 2001 17:29:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22348 Mon, 9 Jul 2001 19:49:15 -0400 (EDT) From: "Michael Reilly" To: =?iso-8859-1?Q?Torbj=F6rn_Friberg?= , Subject: RE: SCEP limitations Date: Mon, 9 Jul 2001 16:55:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>When using SCEP why is it not possible to have a certificate hierarchi. >>If I would like to have ex. a policy CA and a number of >>sub-CA's who would isssue certificates to the subcribers, >>then it will not work?! It works fine. We do it as a routine part of our testing. What problems are you having? >>And when will SCEP support renewal function? It probably won't ever have renewal - too much politics. michael From owner-ipsec@lists.tislabs.com Tue Jul 10 08:38:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AFcKm20440; Tue, 10 Jul 2001 08:38:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23816 Tue, 10 Jul 2001 10:17:40 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281B6@ROC-76-204.nai.com> From: "Mason, David" To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Tue, 10 Jul 2001 07:22:16 -0700 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 What is the purpose/motivation behind the AH Envelope? It seems like needless overhead to me. What is the purpose/motivation of the long period (default 5 minutes) keepalive mentioned in the second paragraph of section 4? Why bother providing even a MAY for support of AH? Only support for IPv4 AH is specified, in which case ESPNULL provides practically the same protection (yes AH protects 3 historic security options, the router alert option which is noted to be incompatible with IPsec, and the multi-destination delivery option but how often are these options actually used?). In the past people have been jumping up and down about IKE/IPsec already being too complex. I think this is a case where added complexity provides very little benefit. Just for the fun of causing trouble and stoking fires: I noticed that the NAT-traversal drafts were published under the auspices of the WG instead of as individual submissions. I thought there was an edict that the WG would not support changes to IKE/IPsec. Has the edict been dropped, or is it a wish-washy edict, or are IDs with lots of authors from powerful companies exempt? -dave From owner-ipsec@lists.tislabs.com Tue Jul 10 08:42:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AFgDm21300; Tue, 10 Jul 2001 08:42:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA23901 Tue, 10 Jul 2001 10:48:31 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281B7@ROC-76-204.nai.com> From: "Mason, David" To: "'ipsec@lists.tislabs.com'" Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Tue, 10 Jul 2001 07:53:12 -0700 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 Reiterating my point that support for AH adds (unnecessary) complexity: The steps outlined for AH Decapsulation in sections 3.7 and 3.9 will fail the ICV verification check for every single packet. There needs to be a step inserted that changes the source and/or destination address in the outer IP header to match the source/destination addresses that were used during the encapsulation process. And then for the transport case, after step 5) change the address(es) back. In section 3.1.2, for step c) it is the destination address that has changed for inbound packets to the side that's behind the NATing device. And for the uncommon case where both ends are behind NATing devices, both the source and destination addresses will have changed. -dave From owner-ipsec@lists.tislabs.com Tue Jul 10 09:39:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AGdmm25457; Tue, 10 Jul 2001 09:39:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA24008 Tue, 10 Jul 2001 11:48:46 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281B9@ROC-76-204.nai.com> From: "Mason, David" To: "'ipsec@lists.tislabs.com'" Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Tue, 10 Jul 2001 08:53:16 -0700 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 the burden of fixing the TCP/UDP header checksums (and any contained protocols that have been broken by NAT - section 3.1.2) would be better placed if the side that is behind the NAT device is in charge of fixing it (for their address). This means that this function would sometimes be performed as part of encapsulation (pre-fixing) as well as decapsulation (post-fixing). The reason that I suggest this is that the common case is that the side behind the NAT device (usually a VPN client) generally will have only one (or a very small number) of active IPsec links, whereas the other end (usually a gateway/server) will have perhaps thousands of active IPsec links. The impact on the client of having to always do the transport mode checksum fixing will be minimal, whereas the benefit to the server/gateway could be significant. -dave From owner-ipsec@lists.tislabs.com Tue Jul 10 09:47:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AGlem25761; Tue, 10 Jul 2001 09:47:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24043 Tue, 10 Jul 2001 12:01:35 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Tue, 10 Jul 2001 09:06:28 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1A4E8AA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Thread-Index: AcEJUX0Nf2zYvShHSrS+RjzoAGXA5AAB+GPw From: "Brian Swander" To: "Mason, David" , X-OriginalArrivalTime: 10 Jul 2001 16:06:29.0324 (UTC) FILETIME=[476EE0C0:01C1095A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA24040 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I can field a couple of the below: The 5 minute interval of keep-alives (keep-alives still sent every 20 (or X) seconds) after all SAs are down is to allow for the case for the peer external to the NAT to potentially decide that it needs to rekey the MM, and still have the NAT hole poked so that the IKE traffic could traverse the NAT and reach the internal machine. This is a tradeoff between maintaining lots of state and sending keep-alives vs. potentially breaking upper layer connections. As for the AH specification, we put it in for completeness because we didn't want to open the draft up to the criticism of ignoring AH. I cannot speak for the rest of the authors, but I'd be surprised if anyone is very interested in supporting AH. Also, I don't think there would be much resistance to removing the specification of AH, if we reach that consensus. bs -----Original Message----- From: Mason, David [mailto:David_Mason@nai.com] Sent: Tuesday, July 10, 2001 7:22 AM To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt What is the purpose/motivation behind the AH Envelope? It seems like needless overhead to me. What is the purpose/motivation of the long period (default 5 minutes) keepalive mentioned in the second paragraph of section 4? Why bother providing even a MAY for support of AH? Only support for IPv4 AH is specified, in which case ESPNULL provides practically the same protection (yes AH protects 3 historic security options, the router alert option which is noted to be incompatible with IPsec, and the multi-destination delivery option but how often are these options actually used?). In the past people have been jumping up and down about IKE/IPsec already being too complex. I think this is a case where added complexity provides very little benefit. Just for the fun of causing trouble and stoking fires: I noticed that the NAT-traversal drafts were published under the auspices of the WG instead of as individual submissions. I thought there was an edict that the WG would not support changes to IKE/IPsec. Has the edict been dropped, or is it a wish-washy edict, or are IDs with lots of authors from powerful companies exempt? -dave From owner-ipsec@lists.tislabs.com Tue Jul 10 11:22:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AIMvm28947; Tue, 10 Jul 2001 11:22:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA24296 Tue, 10 Jul 2001 13:31:21 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281BA@ROC-76-204.nai.com> From: "Mason, David" To: "'Brian Swander'" , ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Tue, 10 Jul 2001 10:34:49 -0700 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 > The 5 minute interval of keep-alives (keep-alives still sent > every 20 (or X) seconds) after all SAs are down is to allow > for the case for the peer external to the NAT to potentially > decide that it needs to rekey the MM, and still have the NAT > hole poked so that the IKE traffic could traverse the NAT and > reach the internal machine. This is a tradeoff between > maintaining lots of state and sending keep-alives vs. > potentially breaking upper layer connections. The paragraph as worded implies that a single keepalive packet might be sent after an elapsed period of up to N (5) minutes. I would suggest moving the paragraph to after the paragraph below it and re-wording it to something like: "A peer MAY continue to send NAT-keepalive packets every M seconds for up to N minutes after the last Phase I and Phase II SA between the peers has been deleted. This will keep the NAT mappings alive and allow the peer external to the NAT to initiate a rekey if it decides it needs to. N is a locally ..." Also I would think that the 5 minute default is too long. If VPN wasn't involved the "server" wouldn't normally be able to connect back to the "client" after 5 minutes so I'm not sure why this capability should be provided for VPN. One or two keepalive packets after the last SA has been deleted should be more than sufficient as the default. Is the long 5 minute default have something to do with the fact that the keepalive mechanism happens at the IP layer and for some implementations it might be problematic for it to know when the last Phase 1 SA has been deleted? I guess this is a problem of dangling Phase 1 SAs :-) To really be reliable the IPsec system behind the NAT device will need to keep TCP connection state and generate keepalives while there are open TCP connections (no need to keep the IPsec/IKE SAs active though). The NAT device use to keep the TCP state for them but since TCP is now encapsulated in ESP/UDP the NAT mappings no longer have state and just have the UDP timeout. The IPsec system must now assume that burden if it wants to provide the same functionality that would exist without using VPN. There is probably a better solution to this than sending a packet every 20 seconds for TCP connections that are idle for a very long time. But I don't think just doing it for five minutes is a solution either. -dave From owner-ipsec@lists.tislabs.com Tue Jul 10 13:18:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AKIOm04263; Tue, 10 Jul 2001 13:18:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24363 Tue, 10 Jul 2001 14:11:21 -0400 (EDT) Message-Id: <200107101817.f6AIHCx28764@thunk.east.sun.com> From: Bill Sommerfeld To: "Mason, David" cc: "'Brian Swander'" , ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt In-reply-to: Your message of "Tue, 10 Jul 2001 10:34:49 PDT." <8894CA1F87A5D411BD24009027EE78381281BA@ROC-76-204.nai.com> Reply-to: sommerfeld@East.Sun.COM Date: Tue, 10 Jul 2001 14:17:12 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Also I would think that the 5 minute default is too long. If VPN > wasn't involved the "server" wouldn't normally be able to connect > back to the "client" after 5 minutes so I'm not sure why this > capability should be provided for VPN. One or two keepalive > packets after the last SA has been deleted should be more than > sufficient as the default. 5 minutes seems like a reasonable default to me; it's comparable in length to the (as specified) TCP TIME_WAIT interval. I think you want to attempt to keep things alive across a brief loss in connectivity (between the NAT and the outside-the-nat peer); 30 second outages while BGP does its thing are not uncommon.. > There is probably a better solution to this than sending a packet > every 20 seconds for TCP connections that are idle for a very long > time. Yes there is: get rid of the NAT :-) For what it's worth, it seems like the impact on the network of the NAT-keepalives could be reduced by sending them with a reduced IP TTL (so that they die just beyond the last NAT being traversed). Unfortunately there doesn't seem to be an easy way to figure out what that TTL should be.. - Bill From owner-ipsec@lists.tislabs.com Tue Jul 10 14:21:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ALLSm06001; Tue, 10 Jul 2001 14:21:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24600 Tue, 10 Jul 2001 16:30:36 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Organization: SSH Communications Security From: Markus Stenberg Date: 10 Jul 2001 21:40:34 +0300 Message-ID: <87u20k1vbx.fsf@porsas.hel.fi.ssh.com> Lines: 109 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 David_Mason@nai.com ("Mason, David") writes: > > The 5 minute interval of keep-alives (keep-alives still sent > > every 20 (or X) seconds) after all SAs are down is to allow > > for the case for the peer external to the NAT to potentially > > decide that it needs to rekey the MM, and still have the NAT > > hole poked so that the IKE traffic could traverse the NAT and > > reach the internal machine. This is a tradeoff between > > maintaining lots of state and sending keep-alives vs. > > potentially breaking upper layer connections. > The paragraph as worded implies that a single keepalive packet > might be sent after an elapsed period of up to N (5) minutes. > I would suggest moving the paragraph to after the paragraph > below it and re-wording it to something like: > > "A peer MAY continue to send NAT-keepalive packets every M seconds > for up to N minutes after the last Phase I and Phase II SA between > the peers has been deleted. This will keep the NAT mappings alive > and allow the peer external to the NAT to initiate a rekey if it > decides it needs to. N is a locally ..." > > Also I would think that the 5 minute default is too long. If VPN > wasn't involved the "server" wouldn't normally be able to connect > back to the "client" after 5 minutes so I'm not sure why this > capability should be provided for VPN. One or two keepalive > packets after the last SA has been deleted should be more than > sufficient as the default. Is the long 5 minute default have > something to do with the fact that the keepalive mechanism > happens at the IP layer and for some implementations it might > be problematic for it to know when the last Phase 1 SA has been > deleted? I guess this is a problem of dangling Phase 1 SAs :-) I did not write (this) draft, but I assume it's mainly usability oriented (=P1/P2 rekey delays). _If_ IPsec SAs and P1 SAs are not tied together, there may be P1 SA down yet still IPsec SAs going on. Let's do hypothetical scenario.. - IPsec SA expires, we're dumb and have only hard limit so the SA is really zapped _when_ we start rekey - P1 SA was down - oops. - negotiate P1 SA, do P2 Example: We are using lossy GPRS backbone (I have enjoyed one for remote access), we can except say, ~1k/s bandwidth, 1s roundtrip and ~30% UDP packet loss. Assuming either [a] jumbo-content (I've seen IKE PhaseI+II that took about hundred kb), or [b] bad luck with packet loss (with relaxed retry timers, and some form of reasonable 10-20s start for retry interval with exponential interval between retries, it takes only few resends to push resend to minute(s) range) a) shows user/admin with attitude problem, but b) I think is fairly common occurrence. Admittedly, I think that for _most_ applications say, 10s would be enough but I am not sure if that's good design criteria for general-purpose protocol.. Too bad the IPsec isn't more connection-oriented so we could just say "I'm done with you, sod off.". I don't even go into using this to fight NASA's NAT for probe that's going around Sun, because I assume it's bit out of context and delay's too small ;-) Summary: _If_ you assume network isn't lossy, supporting 66s roundtrip is stupid, but packet losses with reasonable IKE retry behavior can make 300s quite short time. > To really be reliable the IPsec system behind the NAT device will > need to keep TCP connection state and generate keepalives while > there are open TCP connections (no need to keep the IPsec/IKE SAs > active though). The NAT device use to keep the TCP state for > them but since TCP is now encapsulated in ESP/UDP the NAT mappings > no longer have state and just have the UDP timeout. The IPsec > system must now assume that burden if it wants to provide the > same functionality that would exist without using VPN. There is > probably a better solution to this than sending a packet every > 20 seconds for TCP connections that are idle for a very long time. > But I don't think just doing it for five minutes is a solution either. Doing keepalive _only_ when TCP sessions are open is bad idea; when the NAT mapping dies along with the TCP sessions, the new sessions become problematic; - send (some) messages along, with keepalives - no reply at all? (I guess you'd need DPD for this) => zap P1/P2s - new P1 SA - new P2 SA Which would mean quite major delay as far as QoS is concerned. Second choice, which is to simply make P2 SAs last as long as there is TCP activity (=just do P1 with INITIAL CONTACT flag set once we desire to re-start traffic), works somewhat better, although it breaks (at least spirit of) RFCs _and_ causes major CPU hogging due to unnecessary P1/P2s. > -dave -Markus -- Markus Stenberg of SSH Communications Security (www.ssh.com) From owner-ipsec@lists.tislabs.com Tue Jul 10 15:50:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6AMoNm08028; Tue, 10 Jul 2001 15:50:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA24599 Tue, 10 Jul 2001 16:30:36 -0400 (EDT) Message-ID: <001001c10973$2c8a1360$5fb12304@ffb5b> From: "jshukla" To: "Mason, David" , References: <8894CA1F87A5D411BD24009027EE78381281B7@ROC-76-204.nai.com> Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Tue, 10 Jul 2001 12:04:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Mason, David" To: Sent: Tuesday, July 10, 2001 7:53 AM Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt > > Reiterating my point that support for AH adds (unnecessary) complexity: The > steps outlined for AH Decapsulation in sections 3.7 and 3.9 will fail the > ICV verification check for every single packet. There needs to be a step > inserted that changes the source and/or destination address in the outer IP > header to match the source/destination addresses that were used during the > encapsulation process. And then for the transport case, after step 5) change > the address(es) back. It is nice to see that someone else also noticed that a very obvious step was missing! Did you guys also notice that the basic ESPUDP proposal itself has changed?! I am surprised that nobody has yet commented on this fact?! Allow me to explain...... In the section 4 of draft-ietf-ipsec-nat-t-ike-00.txt, there is mention of sending original source IP address. The reason it is done is so that IP header can be corrected in the transport mode. They explain this in Section 3.1.2 of draft-ietf-ipsec-udp-encaps-00.txt. This is in a very _big_ departure from the earlier proposals. Earlier proposals used built-in NATs and _completely_ discarded the ESPUDP transport mode. I quote from draft-huttunen-ipsec-esp-in-udp-00.txt, Section 7.2 "For this reason, ESPUDP in transport mode is not recommended when NAT traversal is required. The recommended choice is to use tunnel mode ESP over UDP in this situation. Similarly to the Client<->GW case, the contained protocols like FTP continue to work." Sections 7.3 (similar to 7.2) and 7.4 (IP address assigned by the remote gateway to the host) also present approaches that are nothing like what we see in the current draft. Similarly the other draft "draft-stenberg-ipsec-nat-traversal-01.txt" talks about built-in NATs and nothing about reverting to the original IP address once the packet arrives at the destination. Guess what? Built-in NATs are completely gone from the current proposal. Now the question is how come they have suddenly switched to a very different approach and now ESPUDP in transport mode works across NATs? I'd like to hear an explanation from the authors about what seems to be outright conflicting statements in their drafts and a big departure from their original proposal. Although I must agree that reversing the effect of NATs is a brilliant idea. I think it was presented at the San Diego meeting by someone! :-) regards, Jayant From owner-ipsec@lists.tislabs.com Tue Jul 10 22:44:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6B5i2m15965; Tue, 10 Jul 2001 22:44:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA25313 Wed, 11 Jul 2001 00:39:31 -0400 (EDT) X-Apparently-From: Message-ID: <001401c109c3$f31fba20$780d1ec8@myputopc> From: =?iso-8859-1?Q?Gerardo_Ar=E9valo_Tamayo?= To: "IPsec List" Subject: IPsec Expert Date: Tue, 10 Jul 2001 23:24:19 -0500 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPsec Expert is an application intended for anyone who is related with designing, developing, or managing a secure network over IP. As this application is an Expert System over IPsec, it is able to diagnose a design, as well as suggest how to configure it in order to avoid interoperability problems. Your comments and suggestions will help me to improve this application. Thanks! http://go.to/ipsec or http://www.pymenet.com.co/ipsec Gerardo Arévalo Tamayo Email: gerardo_arevalo@softhome.net Email2: ipsec@pymenet.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ipsec@lists.tislabs.com Wed Jul 11 03:11:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BABmm13297; Wed, 11 Jul 2001 03:11:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA26094 Wed, 11 Jul 2001 05:01:43 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: revised hash X-Mailer: Cue version 0.6 (010413-1707/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20010711181116U.sakane@kame.net> Date: Wed, 11 Jul 2001 18:11:16 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 29 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk i'm not sure the question was discussed in the past. please, does anyone clarify me. i have a question about draft-ietf-ipsec-ike-hash-revised-02.txt although i know the draft has expired. the section 3 of this draft says: The packet_1 is the first packet initiator sends to the network (starting from the beginning of the generic header and continuing to the length specified in the ISAKMP header). i'm confusing about this description. "the beginning of the generic header" means the next octet to the ISAKMP header because the generic header isn't ISAKMP header. but "the length in the ISAKMP header" is total length of the packet. it is length mismatch. the description would be "starting from the beginning of the ISAKMP header...", right ? RFC2408 defines and uses just two expressions. "Generic Payload Header" is the header of each ISAKMP payload. "ISAKMP Header" is the ISAKMP packet header. the draft used almost four expressions about "header". generic ISAKMP header ISAKMP generic headers ISAKMP payload headers ISAKMP header IMHO, those expressions should not be used. only two expressions should be used. regards, From owner-ipsec@lists.tislabs.com Wed Jul 11 05:04:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BC4km16076; Wed, 11 Jul 2001 05:04:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA26404 Wed, 11 Jul 2001 07:00:56 -0400 (EDT) Date: Tue, 10 Jul 2001 16:55:58 -0400 From: Ramin Ali Dousti To: Bill Sommerfeld Cc: "Mason, David" , "'Brian Swander'" , ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Message-ID: <20010710165558.A643@uu.net> References: <8894CA1F87A5D411BD24009027EE78381281BA@ROC-76-204.nai.com> <200107101817.f6AIHCx28764@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200107101817.f6AIHCx28764@thunk.east.sun.com>; from sommerfeld@East.Sun.COM on Tue, Jul 10, 2001 at 02:17:12PM -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Jul 10, 2001 at 02:17:12PM -0400, Bill Sommerfeld wrote: > > Also I would think that the 5 minute default is too long. If VPN > > wasn't involved the "server" wouldn't normally be able to connect > > back to the "client" after 5 minutes so I'm not sure why this > > capability should be provided for VPN. One or two keepalive > > packets after the last SA has been deleted should be more than > > sufficient as the default. > > 5 minutes seems like a reasonable default to me; it's comparable in > length to the (as specified) TCP TIME_WAIT interval. > > I think you want to attempt to keep things alive across a brief loss > in connectivity (between the NAT and the outside-the-nat peer); 30 > second outages while BGP does its thing are not uncommon.. > > > There is probably a better solution to this than sending a packet > > every 20 seconds for TCP connections that are idle for a very long > > time. > > Yes there is: get rid of the NAT :-) > > For what it's worth, it seems like the impact on the network of the > NAT-keepalives could be reduced by sending them with a reduced IP TTL > (so that they die just beyond the last NAT being traversed). > Unfortunately there doesn't seem to be an easy way to figure out what > that TTL should be.. Doesn't it, then, mean that the router (where the TTL hits zero) would react and send back an ICMP? What are we trying to solve with reducing the TTL? Ramin > > - Bill From owner-ipsec@lists.tislabs.com Wed Jul 11 09:36:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BGaOm28234; Wed, 11 Jul 2001 09:36:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27070 Wed, 11 Jul 2001 11:21:28 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281C0@ROC-76-204.nai.com> From: "Mason, David" To: "'Markus Stenberg'" , ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Wed, 11 Jul 2001 08:25:49 -0700 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 Thanks for the great analysis (it'd make a great beginning to an appendix for the document). But I don't think the suggested default should be based on use over a lossy GPRS backbone. Was there any other motivation for the N minute keepalive linger other than for slow rekeys? A short sentence or two stating clearly and precisely what problem is solved by using the extended N minutes of keepalive packets would be helpful. It might help implementors decide on if they want to support it and/or allow the feature to be configurable. I'd prefer to see the sending of unnecessary keepalives kept at a minimum if at all possible. -dave -----Original Message----- From: Markus Stenberg [mailto:mstenber@ssh.com] Sent: Tuesday, July 10, 2001 2:41 PM To: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt David_Mason@nai.com ("Mason, David") writes: > > The 5 minute interval of keep-alives (keep-alives still sent > > every 20 (or X) seconds) after all SAs are down is to allow > > for the case for the peer external to the NAT to potentially > > decide that it needs to rekey the MM, and still have the NAT > > hole poked so that the IKE traffic could traverse the NAT and > > reach the internal machine. This is a tradeoff between > > maintaining lots of state and sending keep-alives vs. > > potentially breaking upper layer connections. > The paragraph as worded implies that a single keepalive packet > might be sent after an elapsed period of up to N (5) minutes. > I would suggest moving the paragraph to after the paragraph > below it and re-wording it to something like: > > "A peer MAY continue to send NAT-keepalive packets every M seconds > for up to N minutes after the last Phase I and Phase II SA between > the peers has been deleted. This will keep the NAT mappings alive > and allow the peer external to the NAT to initiate a rekey if it > decides it needs to. N is a locally ..." > > Also I would think that the 5 minute default is too long. If VPN > wasn't involved the "server" wouldn't normally be able to connect > back to the "client" after 5 minutes so I'm not sure why this > capability should be provided for VPN. One or two keepalive > packets after the last SA has been deleted should be more than > sufficient as the default. Is the long 5 minute default have > something to do with the fact that the keepalive mechanism > happens at the IP layer and for some implementations it might > be problematic for it to know when the last Phase 1 SA has been > deleted? I guess this is a problem of dangling Phase 1 SAs :-) I did not write (this) draft, but I assume it's mainly usability oriented (=P1/P2 rekey delays). _If_ IPsec SAs and P1 SAs are not tied together, there may be P1 SA down yet still IPsec SAs going on. Let's do hypothetical scenario.. - IPsec SA expires, we're dumb and have only hard limit so the SA is really zapped _when_ we start rekey - P1 SA was down - oops. - negotiate P1 SA, do P2 Example: We are using lossy GPRS backbone (I have enjoyed one for remote access), we can except say, ~1k/s bandwidth, 1s roundtrip and ~30% UDP packet loss. Assuming either [a] jumbo-content (I've seen IKE PhaseI+II that took about hundred kb), or [b] bad luck with packet loss (with relaxed retry timers, and some form of reasonable 10-20s start for retry interval with exponential interval between retries, it takes only few resends to push resend to minute(s) range) a) shows user/admin with attitude problem, but b) I think is fairly common occurrence. Admittedly, I think that for _most_ applications say, 10s would be enough but I am not sure if that's good design criteria for general-purpose protocol.. Too bad the IPsec isn't more connection-oriented so we could just say "I'm done with you, sod off.". I don't even go into using this to fight NASA's NAT for probe that's going around Sun, because I assume it's bit out of context and delay's too small ;-) Summary: _If_ you assume network isn't lossy, supporting 66s roundtrip is stupid, but packet losses with reasonable IKE retry behavior can make 300s quite short time. > To really be reliable the IPsec system behind the NAT device will > need to keep TCP connection state and generate keepalives while > there are open TCP connections (no need to keep the IPsec/IKE SAs > active though). The NAT device use to keep the TCP state for > them but since TCP is now encapsulated in ESP/UDP the NAT mappings > no longer have state and just have the UDP timeout. The IPsec > system must now assume that burden if it wants to provide the > same functionality that would exist without using VPN. There is > probably a better solution to this than sending a packet every > 20 seconds for TCP connections that are idle for a very long time. > But I don't think just doing it for five minutes is a solution either. Doing keepalive _only_ when TCP sessions are open is bad idea; when the NAT mapping dies along with the TCP sessions, the new sessions become problematic; - send (some) messages along, with keepalives - no reply at all? (I guess you'd need DPD for this) => zap P1/P2s - new P1 SA - new P2 SA Which would mean quite major delay as far as QoS is concerned. Second choice, which is to simply make P2 SAs last as long as there is TCP activity (=just do P1 with INITIAL CONTACT flag set once we desire to re-start traffic), works somewhat better, although it breaks (at least spirit of) RFCs _and_ causes major CPU hogging due to unnecessary P1/P2s. > -dave -Markus -- Markus Stenberg of SSH Communications Security (www.ssh.com) From owner-ipsec@lists.tislabs.com Wed Jul 11 11:45:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BIjpm02779; Wed, 11 Jul 2001 11:45:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27507 Wed, 11 Jul 2001 13:41:02 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281C5@ROC-76-204.nai.com> From: "Mason, David" To: "'Brian Swander'" , ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Wed, 11 Jul 2001 10:45:41 -0700 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 that if the ID states that a peer MAY send keepalives for N minutes with a default of 5 minutes that many implementers will always send keepalives for 5 minutes. I don't think this is such a good idea. Asking/requiring clients to keep track of TCP connection state isn't such a good idea either (it should be recommended though - gateways will usually already have this capacity). As a tradeoff recommendation how about something like: A peer SHOULD send a NAT-keepalive packet while there is an IKE or IPsec SA in place if a need to send such packets is detected according to [Kiv00] and if no other packet to the peer has been sent in M seconds. M is a locally configurable parameter with a default value of 20 seconds. A peer MAY continue to send NAT-keepalive packets every M seconds while there exists open TCP connections between the systems. As an alternative to maintaining state for TCP connections for this purpose a peer MAY continue to send NAT-keepalive packets every M seconds for up to N minutes after the last active IPsec traffic was processed even when the last IKE and IPsec SA between the peers has been deleted. This means that if a VPN session has been idle for more than N minutes when the last SA between the systems is deleted then no more keepalives are sent. N is a locally configurable parameter with a default value of 5 minutes. With this wording implementers are less likely to continue sending keepalive packets for 5 minutes after each and every VPN session is torn down. I'm assuming here that the N minutes linger period was a tradeoff between maintaining lots of state vs. potentially breaking upper layer connections. -dave -----Original Message----- From: Brian Swander [mailto:briansw@windows.microsoft.com] Sent: Tuesday, July 10, 2001 12:06 PM To: Mason, David; ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt I can field a couple of the below: The 5 minute interval of keep-alives (keep-alives still sent every 20 (or X) seconds) after all SAs are down is to allow for the case for the peer external to the NAT to potentially decide that it needs to rekey the MM, and still have the NAT hole poked so that the IKE traffic could traverse the NAT and reach the internal machine. This is a tradeoff between maintaining lots of state and sending keep-alives vs. potentially breaking upper layer connections. As for the AH specification, we put it in for completeness because we didn't want to open the draft up to the criticism of ignoring AH. I cannot speak for the rest of the authors, but I'd be surprised if anyone is very interested in supporting AH. Also, I don't think there would be much resistance to removing the specification of AH, if we reach that consensus. bs -----Original Message----- From: Mason, David [mailto:David_Mason@nai.com] Sent: Tuesday, July 10, 2001 7:22 AM To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt What is the purpose/motivation behind the AH Envelope? It seems like needless overhead to me. What is the purpose/motivation of the long period (default 5 minutes) keepalive mentioned in the second paragraph of section 4? Why bother providing even a MAY for support of AH? Only support for IPv4 AH is specified, in which case ESPNULL provides practically the same protection (yes AH protects 3 historic security options, the router alert option which is noted to be incompatible with IPsec, and the multi-destination delivery option but how often are these options actually used?). In the past people have been jumping up and down about IKE/IPsec already being too complex. I think this is a case where added complexity provides very little benefit. Just for the fun of causing trouble and stoking fires: I noticed that the NAT-traversal drafts were published under the auspices of the WG instead of as individual submissions. I thought there was an edict that the WG would not support changes to IKE/IPsec. Has the edict been dropped, or is it a wish-washy edict, or are IDs with lots of authors from powerful companies exempt? -dave From owner-ipsec@lists.tislabs.com Wed Jul 11 12:29:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BJTtm04551; Wed, 11 Jul 2001 12:29:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27746 Wed, 11 Jul 2001 14:47:39 -0400 (EDT) Message-Id: <200107111853.f6BIr2x11884@thunk.east.sun.com> From: Bill Sommerfeld To: Ramin Ali Dousti cc: Bill Sommerfeld , "Mason, David" , "'Brian Swander'" , ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt In-reply-to: Your message of "Tue, 10 Jul 2001 16:55:58 EDT." <20010710165558.A643@uu.net> Reply-to: sommerfeld@East.Sun.COM Date: Wed, 11 Jul 2001 14:53:02 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Yes there is: get rid of the NAT :-) > > > > For what it's worth, it seems like the impact on the network of the > > NAT-keepalives could be reduced by sending them with a reduced IP TTL > > (so that they die just beyond the last NAT being traversed). > > Unfortunately there doesn't seem to be an easy way to figure out what > > that TTL should be.. > > Doesn't it, then, mean that the router (where the TTL hits zero) > would react and send back an ICMP? What are we trying to solve > with reducing the TTL? We're trying to send the NAT-keepalives only as far as the NAT, so they don't consume bandwidth beyond the NAT, reducing the impact on the network outside the NAT. - Bill From owner-ipsec@lists.tislabs.com Wed Jul 11 12:29:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BJTvm04561; Wed, 11 Jul 2001 12:29:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27730 Wed, 11 Jul 2001 14:42:45 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281CA@ROC-76-204.nai.com> From: "Mason, David" To: "'Brian Swander'" , "'ipsec@lists.tislabs.com'" Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Wed, 11 Jul 2001 11:47:25 -0700 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 On further thought, it seems that sending keepalives while there are TCP connections open or for an N minute linger period really only helps the transport case (so that the decapsulated packet is guaranteed to have the same source address after a rekey). Keeping the NAT mapping alive so that the "outside" peer can rekey doesn't work unless that peer maintains information about SAs that no longer exist (this would have to be done in both the kernel and in the IKE daemon). If a rekey is required when an SA expires it will generally have been performed already so as to provide lossless rekey. The inside peer can rekey at any time - it will just cause a new NAT mapping to be created. In the tunnel case this shouldn't cause any problems. Did I miss something here? -dave -----Original Message----- From: Mason, David Sent: Wednesday, July 11, 2001 1:46 PM To: 'Brian Swander'; ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt I think that if the ID states that a peer MAY send keepalives for N minutes with a default of 5 minutes that many implementers will always send keepalives for 5 minutes. I don't think this is such a good idea. Asking/requiring clients to keep track of TCP connection state isn't such a good idea either (it should be recommended though - gateways will usually already have this capacity). As a tradeoff recommendation how about something like: A peer SHOULD send a NAT-keepalive packet while there is an IKE or IPsec SA in place if a need to send such packets is detected according to [Kiv00] and if no other packet to the peer has been sent in M seconds. M is a locally configurable parameter with a default value of 20 seconds. A peer MAY continue to send NAT-keepalive packets every M seconds while there exists open TCP connections between the systems. As an alternative to maintaining state for TCP connections for this purpose a peer MAY continue to send NAT-keepalive packets every M seconds for up to N minutes after the last active IPsec traffic was processed even when the last IKE and IPsec SA between the peers has been deleted. This means that if a VPN session has been idle for more than N minutes when the last SA between the systems is deleted then no more keepalives are sent. N is a locally configurable parameter with a default value of 5 minutes. With this wording implementers are less likely to continue sending keepalive packets for 5 minutes after each and every VPN session is torn down. I'm assuming here that the N minutes linger period was a tradeoff between maintaining lots of state vs. potentially breaking upper layer connections. -dave -----Original Message----- From: Brian Swander [mailto:briansw@windows.microsoft.com] Sent: Tuesday, July 10, 2001 12:06 PM To: Mason, David; ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt I can field a couple of the below: The 5 minute interval of keep-alives (keep-alives still sent every 20 (or X) seconds) after all SAs are down is to allow for the case for the peer external to the NAT to potentially decide that it needs to rekey the MM, and still have the NAT hole poked so that the IKE traffic could traverse the NAT and reach the internal machine. This is a tradeoff between maintaining lots of state and sending keep-alives vs. potentially breaking upper layer connections. As for the AH specification, we put it in for completeness because we didn't want to open the draft up to the criticism of ignoring AH. I cannot speak for the rest of the authors, but I'd be surprised if anyone is very interested in supporting AH. Also, I don't think there would be much resistance to removing the specification of AH, if we reach that consensus. bs -----Original Message----- From: Mason, David [mailto:David_Mason@nai.com] Sent: Tuesday, July 10, 2001 7:22 AM To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt What is the purpose/motivation behind the AH Envelope? It seems like needless overhead to me. What is the purpose/motivation of the long period (default 5 minutes) keepalive mentioned in the second paragraph of section 4? Why bother providing even a MAY for support of AH? Only support for IPv4 AH is specified, in which case ESPNULL provides practically the same protection (yes AH protects 3 historic security options, the router alert option which is noted to be incompatible with IPsec, and the multi-destination delivery option but how often are these options actually used?). In the past people have been jumping up and down about IKE/IPsec already being too complex. I think this is a case where added complexity provides very little benefit. Just for the fun of causing trouble and stoking fires: I noticed that the NAT-traversal drafts were published under the auspices of the WG instead of as individual submissions. I thought there was an edict that the WG would not support changes to IKE/IPsec. Has the edict been dropped, or is it a wish-washy edict, or are IDs with lots of authors from powerful companies exempt? -dave From owner-ipsec@lists.tislabs.com Wed Jul 11 12:40:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BJeXm04808; Wed, 11 Jul 2001 12:40:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27781 Wed, 11 Jul 2001 14:57:40 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Wed, 11 Jul 2001 12:02:36 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1A4E8AD@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Thread-Index: AcEKOf78XyEBKjI6S7+XtXVVb4md9wAAQTxg From: "Brian Swander" To: "Mason, David" , X-OriginalArrivalTime: 11 Jul 2001 19:02:36.0554 (UTC) FILETIME=[0C67F6A0:01C10A3C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA27776 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There may be extra state on the peer outside the nat, especially in transport mode in order to allow the outside peer to rekey MM. Also, we cannot make assumptions about when rekeying occurs. Some implementations use the continuous channel, and some only bring up SAs when the traffic is flowing. Thus, you may have scenarios when the peer outside the NAT needs to do the rekey. These could occur in tunnel mode as well, for exactly the same reasons. In this case, the peer outside the nat would need to remember which UDP encap ports to use in order to initiate the MM rekey. Yes, the inside peer can reinitiate the MM in the tunnel case at any time without problems, but in order to make sure connectivity is up, the outside peer may need to do it. bs -----Original Message----- From: Mason, David [mailto:David_Mason@NAI.com] Sent: Wednesday, July 11, 2001 11:47 AM To: Brian Swander; 'ipsec@lists.tislabs.com' Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt On further thought, it seems that sending keepalives while there are TCP connections open or for an N minute linger period really only helps the transport case (so that the decapsulated packet is guaranteed to have the same source address after a rekey). Keeping the NAT mapping alive so that the "outside" peer can rekey doesn't work unless that peer maintains information about SAs that no longer exist (this would have to be done in both the kernel and in the IKE daemon). If a rekey is required when an SA expires it will generally have been performed already so as to provide lossless rekey. The inside peer can rekey at any time - it will just cause a new NAT mapping to be created. In the tunnel case this shouldn't cause any problems. Did I miss something here? -dave -----Original Message----- From: Mason, David Sent: Wednesday, July 11, 2001 1:46 PM To: 'Brian Swander'; ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt I think that if the ID states that a peer MAY send keepalives for N minutes with a default of 5 minutes that many implementers will always send keepalives for 5 minutes. I don't think this is such a good idea. Asking/requiring clients to keep track of TCP connection state isn't such a good idea either (it should be recommended though - gateways will usually already have this capacity). As a tradeoff recommendation how about something like: A peer SHOULD send a NAT-keepalive packet while there is an IKE or IPsec SA in place if a need to send such packets is detected according to [Kiv00] and if no other packet to the peer has been sent in M seconds. M is a locally configurable parameter with a default value of 20 seconds. A peer MAY continue to send NAT-keepalive packets every M seconds while there exists open TCP connections between the systems. As an alternative to maintaining state for TCP connections for this purpose a peer MAY continue to send NAT-keepalive packets every M seconds for up to N minutes after the last active IPsec traffic was processed even when the last IKE and IPsec SA between the peers has been deleted. This means that if a VPN session has been idle for more than N minutes when the last SA between the systems is deleted then no more keepalives are sent. N is a locally configurable parameter with a default value of 5 minutes. With this wording implementers are less likely to continue sending keepalive packets for 5 minutes after each and every VPN session is torn down. I'm assuming here that the N minutes linger period was a tradeoff between maintaining lots of state vs. potentially breaking upper layer connections. -dave -----Original Message----- From: Brian Swander [mailto:briansw@windows.microsoft.com] Sent: Tuesday, July 10, 2001 12:06 PM To: Mason, David; ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt I can field a couple of the below: The 5 minute interval of keep-alives (keep-alives still sent every 20 (or X) seconds) after all SAs are down is to allow for the case for the peer external to the NAT to potentially decide that it needs to rekey the MM, and still have the NAT hole poked so that the IKE traffic could traverse the NAT and reach the internal machine. This is a tradeoff between maintaining lots of state and sending keep-alives vs. potentially breaking upper layer connections. As for the AH specification, we put it in for completeness because we didn't want to open the draft up to the criticism of ignoring AH. I cannot speak for the rest of the authors, but I'd be surprised if anyone is very interested in supporting AH. Also, I don't think there would be much resistance to removing the specification of AH, if we reach that consensus. bs -----Original Message----- From: Mason, David [mailto:David_Mason@nai.com] Sent: Tuesday, July 10, 2001 7:22 AM To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt What is the purpose/motivation behind the AH Envelope? It seems like needless overhead to me. What is the purpose/motivation of the long period (default 5 minutes) keepalive mentioned in the second paragraph of section 4? Why bother providing even a MAY for support of AH? Only support for IPv4 AH is specified, in which case ESPNULL provides practically the same protection (yes AH protects 3 historic security options, the router alert option which is noted to be incompatible with IPsec, and the multi-destination delivery option but how often are these options actually used?). In the past people have been jumping up and down about IKE/IPsec already being too complex. I think this is a case where added complexity provides very little benefit. Just for the fun of causing trouble and stoking fires: I noticed that the NAT-traversal drafts were published under the auspices of the WG instead of as individual submissions. I thought there was an edict that the WG would not support changes to IKE/IPsec. Has the edict been dropped, or is it a wish-washy edict, or are IDs with lots of authors from powerful companies exempt? -dave From owner-ipsec@lists.tislabs.com Wed Jul 11 13:38:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6BKcgm06771; Wed, 11 Jul 2001 13:38:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27936 Wed, 11 Jul 2001 15:55:01 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281CB@ROC-76-204.nai.com> From: "Mason, David" To: "'Brian Swander'" , "Mason, David" , ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Wed, 11 Jul 2001 12:57:40 -0700 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 So the following might be a useful addition to the ID: The peer outside the NAT MAY want to maintain the outbound SPD and enough information to facilitate a rekey after the IKE and IPsec SAs have been deleted for a period of X minutes or while the peer inside the NAT continues to send NAT-keepalives, whichever is shorter (perhaps accounting for the possibility of lost keepalives). X is a locally configurable parameter with a default value of 5 minutes. Ideally N and X would be the same - should perhaps this information be exchanged as part of [Kiv00]? For the tunnel case, if the outside system isn't going to maintain state for N minutes then the inside system needn't send the linger keepalives. To tell you the truth, without specific goals in mind, with a clear and precise explanation of how to achieve those goals, the whole N minute linger thing seems like a kludge to me (except perhaps in the transport case). -dave -----Original Message----- From: Brian Swander [mailto:briansw@windows.microsoft.com] Sent: Wednesday, July 11, 2001 3:03 PM To: Mason, David; ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt There may be extra state on the peer outside the nat, especially in transport mode in order to allow the outside peer to rekey MM. Also, we cannot make assumptions about when rekeying occurs. Some implementations use the continuous channel, and some only bring up SAs when the traffic is flowing. Thus, you may have scenarios when the peer outside the NAT needs to do the rekey. These could occur in tunnel mode as well, for exactly the same reasons. In this case, the peer outside the nat would need to remember which UDP encap ports to use in order to initiate the MM rekey. Yes, the inside peer can reinitiate the MM in the tunnel case at any time without problems, but in order to make sure connectivity is up, the outside peer may need to do it. bs From owner-ipsec@lists.tislabs.com Thu Jul 12 08:54:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CFslm28994; Thu, 12 Jul 2001 08:54:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00395 Thu, 12 Jul 2001 10:44:07 -0400 (EDT) From: "Kiran" To: Subject: ICSA Certification criteria Date: Thu, 12 Jul 2001 20:31:16 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello all, Under ICSA labs program for IPSec product certification the below given criteria are listed to be met.I have a set of questions on these criteria. under IKE SUPPORT(Phase1, Main Mode) section: 1)give private eXponent length, define user control. 2)Mismatched lifetimes tested. 3)Fragmentation Handling(MTU=576). 4)Strong Random Number Generation --Does criteria 2 mean that we have to check if our configure lifetime matches that of the peer.What is the expected behavior if the life times doesn't match. (accept the minimum of the two or reject). --On what basis 'Random Number Generator' is declared strong. I am not able to understand what the above criteria mean. Can any one throw light on the above mentioned criteria. regards, kiran kumar From owner-ipsec@lists.tislabs.com Thu Jul 12 09:18:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CGIYm01395; Thu, 12 Jul 2001 09:18:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00669 Thu, 12 Jul 2001 11:28:24 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281D3@ROC-76-204.nai.com> From: "Mason, David" To: "Mason, David" , "'Brian Swander'" , "'ipsec@lists.tislabs.com'" Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Thu, 12 Jul 2001 08:33:07 -0700 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 Sorry for continuing to harp on the NAT-keepalives, but does the WG really want to come out with a proposal that has the potential of generating lots of unnecessary traffic? With the dramatic increase of always connected systems behind NAPT devices (e.g., cable modems), it is very probable that these systems will maintain long lived VPN links that will be idle for very long periods of time (thereby generating lots of NAT-keepalives under the ID as it stands now). The sole purpose of the NAT-keepalives is to keep the UDP NAT mappings alive. Perhaps this isn't necessary (at least not for long periods of inactivity). The system inside the NAT can cause a new UDP NAT mapping to be created at any time. All that needs to be done is to find a way that will enable the outside system to do this as well. Obviously the only way for this to happen is for the outside system to ask the inside system to do it. What about a dual-channel communication pathway for the IKE daemons? The regular UDP method, but also a back-up TCP connection. The justification ID didn't really cover this possibility. It addressed TCP as an either-or option compared to UDP. I haven't really thought about all of the ramifications. Here are a few questions to begin with: How does the system outside the NAT determine it needs to ask for a NAT mapping activation? One way would be if the UDP channel hadn't been used recently. Obviously this only happens when it needs to send something to the peer. How does it request a NAT mapping activation? Using the TCP channel, perhaps using an acknowledged notify exchange. What if the TCP channel goes down (faked reset packet)? This is the big problem area which needs a lot more thought than these starting comments. If the inside system detects a connection close it reestablishes the TCP connection. The system outside the NAT could perhaps ignore (intercept and delete) RST and FIN packets while an SA still exists between the peers. How does one verify and correlate a new NAT mapping with the old mapping (change in port and/or address)? I'm sure the WG could figure this one out. Does anyone else feel that the sending of NAT-keepalives is an issue that deserves further analysis? -dave From owner-ipsec@lists.tislabs.com Thu Jul 12 09:56:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CGuEm02053; Thu, 12 Jul 2001 09:56:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00729 Thu, 12 Jul 2001 11:53:57 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281D4@ROC-76-204.nai.com> From: "Mason, David" To: "'ipsec@lists.tislabs.com'" Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Thu, 12 Jul 2001 08:58:38 -0700 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 (More whining). If a link is idle for more than 30 seconds, all it takes is for one NAT-keepalive packet to get dropped (or corrupted) between the system inside the NAT and the NAT device for problems to arise. There currently isn't any recovery mechanism for this situation. The next NAT-keepalive sent by the system is likely to create a new NAT mapping using a different port (and/or address). -dave From owner-ipsec@lists.tislabs.com Thu Jul 12 10:03:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CH38m02221; Thu, 12 Jul 2001 10:03:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00843 Thu, 12 Jul 2001 12:22:03 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Organization: SSH Communications Security From: Markus Stenberg Date: 12 Jul 2001 15:33:07 +0300 Message-ID: <871ynm1g58.fsf@porsas.hel.fi.ssh.com> Lines: 37 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 David_Mason@nai.com ("Mason, David") writes: > On further thought, it seems that sending keepalives while there are TCP > connections open or for an N minute linger period really only helps the > transport case (so that the decapsulated packet is guaranteed to have the > same source address after a rekey). > > Keeping the NAT mapping alive so that the "outside" peer can rekey doesn't > work unless that peer maintains information about SAs that no longer exist > (this would have to be done in both the kernel and in the IKE daemon). If a > rekey is required when an SA expires it will generally have been performed ^^^^^^^^^ > already so as to provide lossless rekey. > > The inside peer can rekey at any time - it will just cause a new NAT mapping > to be created. In the tunnel case this shouldn't cause any problems. Did I > miss something here? Possibly - but if you do that, you have to do (computationally considerably more expensive) Phase I every time too, because the IKE mapping _may_ have reset then also (_even_ if your Phase I lifetime hasn't expired.. I think that running IKE over NATs is bad idea to start with :>). It's debatable if 5 minutes is the right way to do it, but _some_ way of making sure that (even potentially somewhat delayed) Phase II is 'enough' to handle the rekey cases. Admittedly, I think this is mostly rare case because typically you'd have rekey occur _way_ before the old SA dies as you pointed it out. Some implementations seem to assume that soft ==~ hard limit, though, making too optimistic guesstimates about when to rekey. > -dave -Markus -- Markus Stenberg of SSH Communications Security (www.ssh.com) From owner-ipsec@lists.tislabs.com Thu Jul 12 10:05:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CH5tm02280; Thu, 12 Jul 2001 10:05:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00810 Thu, 12 Jul 2001 12:14:00 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Thu, 12 Jul 2001 09:19:00 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1A4E8B2@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Thread-Index: AcEK6Ae+XrwZ3hQFQQ+8vp/PFeqV6wABKDeg From: "Brian Swander" To: "Mason, David" , X-OriginalArrivalTime: 12 Jul 2001 16:19:01.0038 (UTC) FILETIME=[5C50D4E0:01C10AEE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA00807 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't think the below analysis is quite correct. In my opinion, the UDP NAT mapping is a property of the SA. The outside peer needs to demultiplex the SA based on the floated source port, i.e. this is part of the SA state lookup (peer ip, local ip, cookies, src port, (dst port always == 500). This is the way he uniquely picks out the inside peer. So, if we let the NAT mapping expire, then basically we've let the MM SAs expire too. Say we didn't expire the MM SAs on the NAT mapping change. Now, we want to send some notify either in IKE or via the extra TCP channel to the peer to tell him about the new mappings for the old SA. If we send it as an IKE message, then the message will arrive with a new floated source port, and we'll need to cook up some funky mechanism to read the original port out of the notify before validating the authenticity of the notify, and then do our lookup of the original SA, and then validate that the notify is ok. When you add into the mix all the state needed to make transport mode work and modifying all that state on each of these NAT mapping changes, the complexity of this approach is overwhelming. A TCP channel seems even more complicated. For TCP to work, we'd need to have and IKE channel and an IPSec SA both up. But in the case where the NAT mappings have changed, it is impossible to keep both of them up for the reasons above, so I don't see how we could get a TCP message to the peer, either. Or were you advocating TCP in the clear? In that case, there is no way to keep the channel up from active attack. If we are mainly concerned with VPN, then our VPN clients can be made smarter to also solve the keepalive "problem". The VPN could detect what connections are active, and if no connections are alive, stop sending the keepalives and just renegotiate the MM if new traffic starts up again. Or this could work as an optimization in the ipsec layer to stop the keepalives when no upper layer connections exists. However, this will increase the load on the VPN gateways because many more MMs will need to be negotiated since the change in NAT mapping invalidates the MM. bs -----Original Message----- From: Mason, David [mailto:David_Mason@NAI.com] Sent: Thursday, July 12, 2001 8:33 AM To: Mason, David; Brian Swander; 'ipsec@lists.tislabs.com' Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Sorry for continuing to harp on the NAT-keepalives, but does the WG really want to come out with a proposal that has the potential of generating lots of unnecessary traffic? With the dramatic increase of always connected systems behind NAPT devices (e.g., cable modems), it is very probable that these systems will maintain long lived VPN links that will be idle for very long periods of time (thereby generating lots of NAT-keepalives under the ID as it stands now). The sole purpose of the NAT-keepalives is to keep the UDP NAT mappings alive. Perhaps this isn't necessary (at least not for long periods of inactivity). The system inside the NAT can cause a new UDP NAT mapping to be created at any time. All that needs to be done is to find a way that will enable the outside system to do this as well. Obviously the only way for this to happen is for the outside system to ask the inside system to do it. What about a dual-channel communication pathway for the IKE daemons? The regular UDP method, but also a back-up TCP connection. The justification ID didn't really cover this possibility. It addressed TCP as an either-or option compared to UDP. I haven't really thought about all of the ramifications. Here are a few questions to begin with: How does the system outside the NAT determine it needs to ask for a NAT mapping activation? One way would be if the UDP channel hadn't been used recently. Obviously this only happens when it needs to send something to the peer. How does it request a NAT mapping activation? Using the TCP channel, perhaps using an acknowledged notify exchange. What if the TCP channel goes down (faked reset packet)? This is the big problem area which needs a lot more thought than these starting comments. If the inside system detects a connection close it reestablishes the TCP connection. The system outside the NAT could perhaps ignore (intercept and delete) RST and FIN packets while an SA still exists between the peers. How does one verify and correlate a new NAT mapping with the old mapping (change in port and/or address)? I'm sure the WG could figure this one out. Does anyone else feel that the sending of NAT-keepalives is an issue that deserves further analysis? -dave From owner-ipsec@lists.tislabs.com Thu Jul 12 10:30:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CHUUm02897; Thu, 12 Jul 2001 10:30:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01077 Thu, 12 Jul 2001 12:52:16 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281D5@ROC-76-204.nai.com> From: "Mason, David" To: "'Markus Stenberg'" , ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Thu, 12 Jul 2001 09:56:58 -0700 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 > > The inside peer can rekey at any time - it will just cause a new NAT mapping > > to be created. In the tunnel case this shouldn't cause any problems. > > Possibly - but if you do that, you have to do (computationally considerably > more expensive) Phase I every time too, because the IKE mapping _may_ have > reset then also (_even_ if your Phase I lifetime hasn't expired.. I think > that running IKE over NATs is bad idea to start with :>). I don't understand why you would have to do a Phase 1 every time. > It's debatable if 5 minutes is the right way to do it, but _some_ way of > making sure that (even potentially somewhat delayed) Phase II is 'enough' > to handle the rekey cases. The retransmission timer used for IKE NAT SAs should never be increased above M (20 seconds). Perhaps allowing for a larger retransmission counter. -dave From owner-ipsec@lists.tislabs.com Thu Jul 12 10:44:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CHiwm03274; Thu, 12 Jul 2001 10:44:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01127 Thu, 12 Jul 2001 13:06:56 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281D6@ROC-76-204.nai.com> From: "Mason, David" To: "'Brian Swander'" , ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Thu, 12 Jul 2001 10:11:40 -0700 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 don't think the below analysis is quite correct. In my opinion, the > UDP NAT mapping is a property of the SA. The outside peer needs to > demultiplex the SA based on the floated source port, i.e. this is part > of the SA state lookup (peer ip, local ip, cookies, src port, (dst port > always == 500). This is the way he uniquely picks out the inside peer. > So, if we let the NAT mapping expire, then basically we've let the MM > SAs expire too. You don't necessarily need to use the src port as part of the lookup. Just use the cookies. > Say we didn't expire the MM SAs on the NAT mapping change. Now, we want > to send some notify either in IKE or via the extra TCP channel to the > peer to tell him about the new mappings for the old SA. If we send it > as an IKE message, then the message will arrive with a new floated > source port, and we'll need to cook up some funky mechanism to read the > original port out of the notify before validating the authenticity of > the notify, and then do our lookup of the original SA, and then validate > that the notify is ok. When you add into the mix all the state needed > to make transport mode work and modifying all that state on each of > these NAT mapping changes, the complexity of this approach is > overwhelming. Just use the cookies for the lookup. > A TCP channel seems even more complicated. For TCP to work, we'd need > to have and IKE channel and an IPSec SA both up. But in the case where > the NAT mappings have changed, it is impossible to keep both of them up > for the reasons above, so I don't see how we could get a TCP message to > the peer, either. Or were you advocating TCP in the clear? In that > case, there is no way to keep the channel up from active attack. TCP NAT mappings don't require a keepalive. They're generally based upon the state of the connection (which can also create problems) and not a flat timeout as is used for UDP. I'm not saying that I know what the solution is, I'm just saying that we need to take a serious look at possible alternatives. Do not send the TCP message in the clear (use the cookies for lookup - and yes there are problems here in determining message boundaries). > If we are mainly concerned with VPN, then our VPN clients can be made > smarter to also solve the keepalive "problem". The VPN could detect > what connections are active, and if no connections are alive, stop > sending the keepalives and just renegotiate the MM if new traffic starts > up again. Or this could work as an optimization in the ipsec layer to > stop the keepalives when no upper layer connections exists. However, > this will increase the load on the VPN gateways because many more MMs > will need to be negotiated since the change in NAT mapping invalidates > the MM. I was under the impression that the N minutes linger was so that the clients don't need to keep track of active connections. I'm also concerned with keepalives for long periods even when there are idle active connections. A change in NAT mappings doesn't necessarily mean the invalidation of the IKE SA. -dave From owner-ipsec@lists.tislabs.com Thu Jul 12 10:49:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CHn2m03342; Thu, 12 Jul 2001 10:49:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01144 Thu, 12 Jul 2001 13:10:24 -0400 (EDT) Message-Id: <200107121716.f6CHGGx24882@thunk.east.sun.com> From: Bill Sommerfeld To: "Mason, David" cc: "'Brian Swander'" , "'ipsec@lists.tislabs.com'" Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt In-reply-to: Your message of "Thu, 12 Jul 2001 08:33:07 PDT." <8894CA1F87A5D411BD24009027EE78381281D3@ROC-76-204.nai.com> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 12 Jul 2001 13:16:16 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk NAT keepalives are (regrettably) necessary. IPsec is a peer-to-peer protocol; IPsec SA's are ephemeral state. an idle TCP connection sends no packets; if it sits idle for a while, any SA's created to carry its traffic will expire. At this point, the application on either end of the TCP connection could decide it has something to send; at that point, *that* end of the IPsec-protected part of the path needs to reestablish the IPsec state. NAT-keepalives are necessary to ensure that a site on the "outside" of the NAT can initiate an SA back to the system stuck behind the NAT. - Bill From owner-ipsec@lists.tislabs.com Thu Jul 12 11:01:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CI1vm03561; Thu, 12 Jul 2001 11:01:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01162 Thu, 12 Jul 2001 13:14:26 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281D8@ROC-76-204.nai.com> From: "Mason, David" To: "'sommerfeld@east.sun.com'" Cc: "'Brian Swander'" , "'ipsec@lists.tislabs.com'" Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Thu, 12 Jul 2001 10:19:09 -0700 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 > NAT-keepalives are necessary to ensure that a site > on the "outside" of the NAT can initiate an SA back > to the system stuck behind the NAT. Only UDP NAT mappings require keepalives. TCP NAT mappings don't. -dave From owner-ipsec@lists.tislabs.com Thu Jul 12 11:51:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CIp6m04342; Thu, 12 Jul 2001 11:51:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01322 Thu, 12 Jul 2001 14:11:27 -0400 (EDT) Message-Id: <200107121817.f6CIHKx25528@thunk.east.sun.com> From: Bill Sommerfeld To: "Mason, David" cc: "'sommerfeld@east.sun.com'" , "'Brian Swander'" , "'ipsec@lists.tislabs.com'" Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt In-reply-to: Your message of "Thu, 12 Jul 2001 10:19:09 PDT." <8894CA1F87A5D411BD24009027EE78381281D8@ROC-76-204.nai.com> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 12 Jul 2001 14:17:20 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Only UDP NAT mappings require keepalives. We're discussing a protocol for tunnelling IPsec through UDP. > TCP NAT mappings don't. I have two data points which say otherwise: - A former employer which I won't malign by name deployed a NAT which I also won't malign by name in the middle of its network which dropped state for TCP connections which had been idle for a small number of minutes. - A popular freeware NAT implementation I've looked at tosses connection state after a (configurable) idle timeout -- the default appears to be 5 days, but it also has a configuration option (called "LARGE_NAT") which drops the idle timeout to 10 minutes. - Bill From owner-ipsec@lists.tislabs.com Thu Jul 12 11:51:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CIpGm04356; Thu, 12 Jul 2001 11:51:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01305 Thu, 12 Jul 2001 14:05:55 -0400 (EDT) To: "Mason, David" Cc: "'sommerfeld@east.sun.com'" , "'Brian Swander'" , "'ipsec@lists.tislabs.com'" Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt References: <8894CA1F87A5D411BD24009027EE78381281D8@ROC-76-204.nai.com> From: Derek Atkins Date: 12 Jul 2001 14:12:21 -0400 In-Reply-To: "Mason, David"'s message of "Thu, 12 Jul 2001 10:19:09 -0700" Message-ID: Lines: 30 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Mason, David" writes: > > NAT-keepalives are necessary to ensure that a site > > on the "outside" of the NAT can initiate an SA back > > to the system stuck behind the NAT. > > Only UDP NAT mappings require keepalives. > TCP NAT mappings don't. Yes, they do. TCP NAT mappings (which means you're using a TCP protocol through the NAT -- which doesn't apply to an ESP-protected TCP session in any case) DO expire. Go telnet in the clear to some host through a NAT and let it sit for a while. I bet you a dollar to a dime that in most cases the NAT box will unmap you and you'll lose your connection. I also think you are confused about how NAT works, and how IPsec protects transport-layer information for protected communications, and how _that_ interacts with NAT, too. However I have no insentive or time to actually correct your brain at the moment. > -dave -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 Thu Jul 12 12:00:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CJ0Am04481; Thu, 12 Jul 2001 12:00:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01288 Thu, 12 Jul 2001 14:02:09 -0400 (EDT) To: "Mason, David" Cc: "'Brian Swander'" , ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt References: <8894CA1F87A5D411BD24009027EE78381281D6@ROC-76-204.nai.com> From: Derek Atkins Date: 12 Jul 2001 14:08:32 -0400 In-Reply-To: "Mason, David"'s message of "Thu, 12 Jul 2001 10:11:40 -0700" Message-ID: Lines: 55 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Mason, David" writes: > TCP NAT mappings don't require a keepalive. They're generally > based upon the state of the connection (which can also create > problems) and not a flat timeout as is used for UDP. I'm not > saying that I know what the solution is, I'm just saying that we > need to take a serious look at possible alternatives. Do not > send the TCP message in the clear (use the cookies for lookup - > and yes there are problems here in determining message boundaries). That's not true. Most NAT boxes will expire a TCP mapping if they are idle for some period of time (generally on the order of 10 minutes, but it certainly varries from box to box). So, you _still_ need a keepalive on a TCP session, too. > I was under the impression that the N minutes linger was > so that the clients don't need to keep track of active > connections. I'm also concerned with keepalives for > long periods even when there are idle active connections. > A change in NAT mappings doesn't necessarily mean the > invalidation of the IKE SA. If your connection is idle for that long a period of time, send an IKE DELETE notification and tear down the session. The reason you need the keepalive there is that if the IKE SAs are still in place, there is no way to know _which side_ will want to send the 'next' packet. If it's the 'server' (e.g. the non-natted host' then there is no way for that server to contact the client (the natted host) because all state information has been lost. And there is no way to notify the client that there is any data to transmit, either, for the same reason. The ONLY way to keep communication alive is to keep the mapping alive for as long as the SA is valid. This MUST be done, otherwise there is no way for packets to get back in through the NAT. If you want to tear it down, then do so. If the connection has no data on it, fine, it will just send keepalives to keep NAT happy. If you want the connection to die when it's idle, then tear it down. That's the joy of living with NAT. If you don't like it, get rid of you d**m NAT box! > -dave -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 Thu Jul 12 12:22:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CJMOm05040; Thu, 12 Jul 2001 12:22:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01456 Thu, 12 Jul 2001 14:39:19 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281D9@ROC-76-204.nai.com> From: "Mason, David" To: "'Derek Atkins'" Cc: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Thu, 12 Jul 2001 11:44:02 -0700 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 > That's not true. Most NAT boxes will expire a TCP > mapping if they are idle for some period of time > (generally on the order of 10 minutes, but it certainly > varries from box to box). So, you _still_ need a > keepalive on a TCP session, too. Well that would be at least an order of magnitude less keepalives. > If your connection is idle for that long a period of > time, send an IKE DELETE notification and tear down > the session. Do you think that this recommendation should go into the ID (and would you suggest a default - if the inside system would lose connections after 10 minutes without using VPN then perhaps a 10 minute default would be appropriate). > The reason you need the keepalive there is that if the > IKE SAs are still in place, there is no way to know > _which side_ will want to send the 'next' packet. If it's > the 'server' (e.g. the non-natted host' then there is no way > for that server to contact the client (the natted host) > because all state information has been lost. And there is no > way to notify the client that there is any data to transmit, > either,for the same reason. If there are IKE SAs still in place then all state information has not been lost so I'm assuming you mean the NAT mappings are gone. That's why I proposed using a TCP second channel. So the server could contact the client via the TCP NAT mapping and request that the client reactivate the UDP NAT mapping. -dave From owner-ipsec@lists.tislabs.com Thu Jul 12 12:43:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CJhBm05356; Thu, 12 Jul 2001 12:43:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA01578 Thu, 12 Jul 2001 14:59:48 -0400 (EDT) To: "Mason, David" Cc: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt References: <8894CA1F87A5D411BD24009027EE78381281D9@ROC-76-204.nai.com> From: Derek Atkins Date: 12 Jul 2001 15:06:11 -0400 In-Reply-To: "Mason, David"'s message of "Thu, 12 Jul 2001 11:44:02 -0700" Message-ID: Lines: 80 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Mason, David" writes: > Well that would be at least an order of magnitude less > keepalives. Um, not necessarily. And then you add the complication of how an IKE daemon knows to contact its peer via the TCP connection. You also are now doubling the connection state in each IKE daemon (requiring a fully connected TCP stream) and also more NAT firewall state to keep the TCP session alive. What are you saving, here? You're adding complexity and state because you're worried about traffic during 'idle' connections? You don't need to use the keepalives as long as there is traffic. Where there isn't traffic, sure, you need a keepalive packet every 30-60 seconds or so, on average. Honestly, I don't consider a single UDP packet this often to be overly heinous. > > If your connection is idle for that long a period of > > time, send an IKE DELETE notification and tear down > > the session. > > Do you think that this recommendation should go into the > ID (and would you suggest a default - if the inside system > would lose connections after 10 minutes without using VPN > then perhaps a 10 minute default would be appropriate). Whoa, nellie. There is a disconnect here. I think you're making an assumption that a box that is idle necessarily _wants_ to tear down the session. That is not always a valid assumption. Sometimes an idle session is just an idle session. Keep in mind Bill's scenario. I user (behind a NAT) has a connected TCP session from their client to some other machine, protected by IPSec. IPSec absolutely _MUST_ keep the UDP mapping alive because _either host_ can send a packet on this connection. Note that the NAT box only sees ESP packets going back and forth -- it has no idea that those ESP packets are encoding TCP session state. They could just as easily be carrying RTP, UDP, or DecNet packets (ok, maybe not DecNet :) Basically, so long as that TCP connection is alive, you MUST keep the UDP mapping alive so that IPSec packets can pass back and forth. > > The reason you need the keepalive there is that if the > > IKE SAs are still in place, there is no way to know > > _which side_ will want to send the 'next' packet. If it's > > the 'server' (e.g. the non-natted host' then there is no way > > for that server to contact the client (the natted host) > > because all state information has been lost. And there is no > > way to notify the client that there is any data to transmit, > > either,for the same reason. > > If there are IKE SAs still in place then all state information > has not been lost so I'm assuming you mean the NAT mappings > are gone. That's why I proposed using a TCP second channel. > So the server could contact the client via the TCP NAT mapping > and request that the client reactivate the UDP NAT mapping. You need keepalives as long as the IKE SA and IPSEC SAs are active. The point of keepalives beyond the length of the IKE SA is that the non-natted host may want to rekey, and may delay re-keying until the SA has expired. In that case, you want to keep the NAT mapping alive _JUST LONG ENOUGH_ to let that happen. If the SAs expire and DONT get rekeyed, then the keepalives stop. Regardless, as long as the SAs _are_ active, you MUST keep the session alive (as far as NAT is concerned). There is no option, you have to do it. > -dave -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 Thu Jul 12 13:21:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CKL4m06053; Thu, 12 Jul 2001 13:21:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01749 Thu, 12 Jul 2001 15:31:22 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281DB@ROC-76-204.nai.com> From: "Mason, David" To: ipsec@lists.tislabs.com Subject: IKE NAT ID Date: Thu, 12 Jul 2001 12:36:06 -0700 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 Section 4.2 Sending the original source address suggests that both sides send NAT-OA for transport mode. If the first NAT-D received matches a local NAT-D sent out, then there should be no need to send a NAT-OA. Is having the SHOULD for both sides always sending a NAT-OA for simplicity sake? -dave From owner-ipsec@lists.tislabs.com Thu Jul 12 13:30:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CKU9m06221; Thu, 12 Jul 2001 13:30:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01867 Thu, 12 Jul 2001 15:48:11 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281DE@ROC-76-204.nai.com> From: "Mason, David" To: "'Derek Atkins'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Thu, 12 Jul 2001 12:52:54 -0700 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 also think you are confused about how NAT works, and how IPsec > protects transport-layer information for protected communications, and > how _that_ interacts with NAT, too. However I have no insentive or > time to actually correct your brain at the moment. As many people can probably tell you, there is no way to correct my brain so don't bother trying. Since no else appears to be concerned about the use of the keepalives I'll shut up (for a short period of time) and quit consuming bandwidth with unnecessary packets (which is what I was concerned about in the first place). -dave From owner-ipsec@lists.tislabs.com Thu Jul 12 13:31:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CKVwm06275; Thu, 12 Jul 2001 13:31:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01855 Thu, 12 Jul 2001 15:47:36 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281DD@ROC-76-204.nai.com> From: "Mason, David" To: ipsec@lists.tislabs.com Subject: RE: IKE NAT ID Date: Thu, 12 Jul 2001 12:52:19 -0700 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 Never mind. -dave -----Original Message----- From: Mason, David [mailto:David_Mason@nai.com] Sent: Thursday, July 12, 2001 3:36 PM To: ipsec@lists.tislabs.com Subject: IKE NAT ID Section 4.2 Sending the original source address suggests that both sides send NAT-OA for transport mode. If the first NAT-D received matches a local NAT-D sent out, then there should be no need to send a NAT-OA. Is having the SHOULD for both sides always sending a NAT-OA for simplicity sake? -dave From owner-ipsec@lists.tislabs.com Thu Jul 12 15:04:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CM4om07935; Thu, 12 Jul 2001 15:04:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02132 Thu, 12 Jul 2001 17:11:04 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE78381281E0@ROC-76-204.nai.com> From: "Mason, David" To: "'Michael Thomas'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Thu, 12 Jul 2001 14:15:46 -0700 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 To a very small degree, but since in theory 64 thousand systems could share the same address (each system gets a different source port - more accurately each connection) this is not the reason why I dislike keepalives. -dave -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Thursday, July 12, 2001 2:33 PM To: sommerfeld@East.Sun.COM Cc: Mason, David; 'Brian Swander'; 'ipsec@lists.tislabs.com' Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt I have a really dumb question. Assuming this isn't a personal NAT (ie, it's say a corporate NAT/firewall) and part of the reason it's there is to conserve public IP addresses, doesn't having keepalives sort of defeat all that? Mike Bill Sommerfeld writes: > NAT keepalives are (regrettably) necessary. > > IPsec is a peer-to-peer protocol; IPsec SA's are ephemeral state. > > an idle TCP connection sends no packets; if it sits idle for a while, > any SA's created to carry its traffic will expire. > > At this point, the application on either end of the TCP connection > could decide it has something to send; at that point, *that* end of > the IPsec-protected part of the path needs to reestablish the IPsec > state. > > NAT-keepalives are necessary to ensure that a site on the "outside" of > the NAT can initiate an SA back to the system stuck behind the NAT. > > - Bill From owner-ipsec@lists.tislabs.com Thu Jul 12 15:55:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6CMttm08566; Thu, 12 Jul 2001 15:55:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA02474 Thu, 12 Jul 2001 18:18:02 -0400 (EDT) Message-Id: <200107122223.f6CMNTx27646@thunk.east.sun.com> From: Bill Sommerfeld To: "jshukla" cc: "Mason, David" , "Derek Atkins" , "'sommerfeld@east.sun.com'" , "'Brian Swander'" , ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt In-reply-to: Your message of "Thu, 12 Jul 2001 15:19:04 PDT." <000c01c10b20$aa3d7d20$03b02304@ffb5b> Reply-to: sommerfeld@East.Sun.COM Date: Thu, 12 Jul 2001 18:23:28 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Most TCP implementations have a built-in keep > alive. Default is supposed to be 2 hrs, but it is > not uncommon to see messages sent every > 10-15min. RFC1122 (Host Requirements, part 1) specifies that TCP keep-alives MUST default to OFF and the default idle timeout MUST be greater than 2 hours. Individual applications may turn on keepalives, but it would be incorrect for any other part of the system to assume that they're always (or even usually) on. - Bill From owner-ipsec@lists.tislabs.com Fri Jul 13 09:55:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6DGsxq28734; Fri, 13 Jul 2001 09:54:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04257 Fri, 13 Jul 2001 11:47:17 -0400 (EDT) Message-ID: <000c01c10b20$aa3d7d20$03b02304@ffb5b> From: "jshukla" To: "Mason, David" , "Derek Atkins" Cc: "'sommerfeld@east.sun.com'" , "'Brian Swander'" , References: <8894CA1F87A5D411BD24009027EE78381281D8@ROC-76-204.nai.com> Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt Date: Thu, 12 Jul 2001 15:19:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: "Derek Atkins" To: "Mason, David" Cc: "'sommerfeld@east.sun.com'" ; "'Brian Swander'" ; Sent: Thursday, July 12, 2001 11:12 AM Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt > > "Mason, David" writes: > > > > NAT-keepalives are necessary to ensure that a site > > > on the "outside" of the NAT can initiate an SA back > > > to the system stuck behind the NAT. > > > > Only UDP NAT mappings require keepalives. > > TCP NAT mappings don't. > > Yes, they do. TCP NAT mappings (which means you're using a TCP > protocol through the NAT -- which doesn't apply to an ESP-protected > TCP session in any case) DO expire. Go telnet in the clear to some > host through a NAT and let it sit for a while. I bet you a dollar to > a dime that in most cases the NAT box will unmap you and you'll lose > your connection. > Don't bet so quickly, you may lose your shirt! Most NATs have a TCP Ageout/timeout that is generally set to 2.5 hrs (I think it is set to 24hrs in CISCO IOS NAT). Again, it can vary and depends on the vendor. Most TCP implementations have a built-in keep alive. Default is supposed to be 2 hrs, but it is not uncommon to see messages sent every 10-15min. Now, if the built-in TCP keep-alive is sent more frequently than the NAT Ageout/timeout, you will never lose a TCP connection. So depending on your TCP implementation and the NAT box setting, you may or may not need to send keep-alive messages. From the defaults it seems that in _most_ cases you will _not_ lose the TCP connections because of NATs. regards, Jayant p.s.: the reason TCP keep-alive are sent is for detecting if the connection is alive and _not_ for keeping NAT mappings alive. From owner-ipsec@lists.tislabs.com Fri Jul 13 16:04:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6DN4vq06203; Fri, 13 Jul 2001 16:04:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04935 Fri, 13 Jul 2001 18:04:34 -0400 (EDT) X-Delivered-For: X-mProtect: Fri, 13 Jul 2001 15:10:35 -0700 Nokia Silicon Valley Messaging Protection Message-ID: <3B4F71D9.F806951C@iprg.nokia.com> Date: Fri, 13 Jul 2001 15:10:33 -0700 From: Marc Solsona-Palomar X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Prefered minimum Phase2 lifetime References: <8894CA1F87A5D411BD24009027EE78381281DB@ROC-76-204.nai.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi everybody, I have a general question to ask and I beleive this is the right group. During the configuration of several IPsec boxes a question poped up: What would be the minimum lifetime to be allowed in a box.?I know applications out there that they don't let configure anything under the hour range and others that you can specify seconds. thanks, marc. From owner-ipsec@lists.tislabs.com Sat Jul 14 00:30:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6E7Uhq10426; Sat, 14 Jul 2001 00:30:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA05514 Sat, 14 Jul 2001 02:38:11 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15181.60754.995414.62593@thomasm-u1.cisco.com> Date: Thu, 12 Jul 2001 11:32:50 -0700 (PDT) To: sommerfeld@East.Sun.COM Cc: "Mason, David" , "'Brian Swander'" , "'ipsec@lists.tislabs.com'" Subject: Re: I-D ACTION:draft-ietf-ipsec-udp-encaps-00.txt In-Reply-To: <200107121716.f6CHGGx24882@thunk.east.sun.com> References: <8894CA1F87A5D411BD24009027EE78381281D3@ROC-76-204.nai.com> <200107121716.f6CHGGx24882@thunk.east.sun.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 I have a really dumb question. Assuming this isn't a personal NAT (ie, it's say a corporate NAT/firewall) and part of the reason it's there is to conserve public IP addresses, doesn't having keepalives sort of defeat all that? Mike Bill Sommerfeld writes: > NAT keepalives are (regrettably) necessary. > > IPsec is a peer-to-peer protocol; IPsec SA's are ephemeral state. > > an idle TCP connection sends no packets; if it sits idle for a while, > any SA's created to carry its traffic will expire. > > At this point, the application on either end of the TCP connection > could decide it has something to send; at that point, *that* end of > the IPsec-protected part of the path needs to reestablish the IPsec > state. > > NAT-keepalives are necessary to ensure that a site on the "outside" of > the NAT can initiate an SA back to the system stuck behind the NAT. > > - Bill From owner-ipsec@lists.tislabs.com Mon Jul 16 04:55:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GBt8q10489; Mon, 16 Jul 2001 04:55:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA09138 Mon, 16 Jul 2001 06:55:59 -0400 (EDT) Message-Id: <200107150037.f6F0bqo08947@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: per-host keying In-reply-to: Your message of "Sat, 07 Jul 2001 12:49:12 EDT." <200107071649.f67GnCL22968@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 14 Jul 2001 20:37:52 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for the responses. I figured that I was blind. Should 2401 be revised at some point, I suggest the words "per-host keying" be added to 4.4.1 section (a). ] 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"); [ From owner-ipsec@lists.tislabs.com Mon Jul 16 04:55:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GBtCq10501; Mon, 16 Jul 2001 04:55:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA09137 Mon, 16 Jul 2001 06:55:54 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15186.9189.491784.660674@ryijy.hel.fi.ssh.com> Date: Mon, 16 Jul 2001 02:14:45 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: sakane@kame.net (Shoichi Sakane) Subject: Re: revised hash X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy References: <20010711181116U.sakane@kame.net> X-Edit-Time: 7 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sakane@kame.net (Shoichi Sakane) writes: > i'm not sure the question was discussed in the past. > please, does anyone clarify me. i have a question about > draft-ietf-ipsec-ike-hash-revised-02.txt although > i know the draft has expired. > > the section 3 of this draft says: > > The packet_1 is the first packet initiator sends to the network > (starting from the beginning of the generic header and continuing > to the length specified in the ISAKMP header). > > i'm confusing about this description. "the beginning of the generic > header" means the next octet to the ISAKMP header because the generic > header isn't ISAKMP header. but "the length in the ISAKMP header" > is total length of the packet. it is length mismatch. > the description would be "starting from the beginning of the ISAKMP > header...", right ? It is supposed to say that everything starting from the beginning of the ISAKMP packet (i.e at the start of the ISAKMP generic packet header, starting with the cookies) and going up to the length specified in the ISAKMP generic packet header. We are talking about the ISAKMP packets here, not the payloads, thus the ISAKMP payload header does not matter here. > RFC2408 defines and uses just two expressions. "Generic Payload Header" > is the header of each ISAKMP payload. "ISAKMP Header" is the ISAKMP packet > header. the draft used almost four expressions about "header". > generic ISAKMP header > ISAKMP generic headers > ISAKMP payload headers > ISAKMP header > IMHO, those expressions should not be used. only two expressions > should be used. True. I try to fix this before resubmitting the draft. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jul 16 04:55:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GBtLq10514; Mon, 16 Jul 2001 04:55:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA09126 Mon, 16 Jul 2001 06:52:48 -0400 (EDT) Message-Id: <200107161058.GAA09709@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-kaufman-ipsec-improveike-00.txt Date: Mon, 16 Jul 2001 06:58:25 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Code-preserving Simplifications and Improvements to IKE Author(s) : C. Kaufman et al. Filename : draft-kaufman-ipsec-improveike-00.txt Pages : 8 Date : 13-Jul-01 This internet draft recommends modifications to Phase 1 IKE that will minimize code changes. We recommend simplification by removing some of the options, and minimal changes, when they provide a large increase in functionality, in the remaining portions of IKE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaufman-ipsec-improveike-00.txt 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-kaufman-ipsec-improveike-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-kaufman-ipsec-improveike-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: <20010713123846.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kaufman-ipsec-improveike-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kaufman-ipsec-improveike-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713123846.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jul 16 08:14:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GFEdq14561; Mon, 16 Jul 2001 08:14:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09744 Mon, 16 Jul 2001 10:19:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200107150037.f6F0bqo08947@marajade.sandelman.ottawa.on.ca> References: <200107150037.f6F0bqo08947@marajade.sandelman.ottawa.on.ca> Date: Mon, 16 Jul 2001 10:21:59 -0400 To: Michael Richardson From: Stephen Kent Subject: Re: per-host keying Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:37 PM -0400 7/14/01, Michael Richardson wrote: > Thanks for the responses. I figured that I was blind. > > Should 2401 be revised at some point, I suggest the words "per-host keying" >be added to 4.4.1 section (a). In revising 2401 I plan to reword the selector discussion extensively, to clarify this detail that, as you noted, is easily missed. However, I would not call it "per host keying" because it can be used to achieve finer granularity keying. Still, we can put in the phrase (to make it easy to search for) as part of the discussion. Steve From owner-ipsec@lists.tislabs.com Mon Jul 16 09:51:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GGptq20733; Mon, 16 Jul 2001 09:51:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10009 Mon, 16 Jul 2001 12:04:42 -0400 (EDT) From: kballou@quarrytech.com Message-ID: <496A8683261CD211BF6C0008C733261A012A86F6@email.quarrytech.com> To: ipsec@lists.tislabs.com Subject: Man in the middle attack (draft-kaufman-ipsec-improveike-00.txt)? Date: Mon, 16 Jul 2001 11:50:12 -0400 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'm sure I've missed something. In section 7 (main mode with pre-shared keys), isn't Alice's identity susceptible to a man-in-the-middle attack? Could Mallory impersonate Bob for the first two pairs of messages, use the Diffie-Hellman key to learn Alice's identity, and then not finish the protocol? (Of course, since Mallory doesn't know the pre-shared secret, he can't fix up the third message to relay it to Bob even with knowledge of Alice's identity.) - Ken From owner-ipsec@lists.tislabs.com Mon Jul 16 10:35:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GHZ1q22026; Mon, 16 Jul 2001 10:35:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA10154 Mon, 16 Jul 2001 12:41:53 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-kaufman-ipsec-improveike-00.txt In-Reply-To: Your message of "Mon, 16 Jul 2001 06:58:25 -0400" <200107161058.GAA09709@ietf.org> References: <200107161058.GAA09709@ietf.org> X-Mailer: Cue version 0.6 (010413-1707/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20010717014753V.sakane@kame.net> Date: Tue, 17 Jul 2001 01:47:53 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 64 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Title : Code-preserving Simplifications and Improvements to > IKE > Author(s) : C. Kaufman et al. > Filename : draft-kaufman-ipsec-improveike-00.txt > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaufman-ipsec-improveike-00.txt i'm not sure i have understood exactly. anyway i have some comments. First, to make sure about Bob and Alice. Bob is the responder, and Alice is the initiator in this draft, right ? i prefer to use the name of the side, e.g. the responder, rather than Bob and Alice. because the side is important in IKE. i like the approach of section 6. it would be helpful for a operator to decrease the trouble when he configures proposal, also negotiation problem. and there is no guideline of using these parameters. i know it is policy matter. but the guideline could help to a administrator. about the section 7, > The solution is to change the key used to encrypt Alice's identity to > be only a function of the Diffie-Hellman key. The protocol already > assures that Alice proves knowledge of the preshared key because she > transmits something to Bob that is a hash of information including > that key. This minimal change (changing the encryption key used for > encrypting messages 5 and 6 to not be a function of the shared key) here is the flow of using pre-shared key. Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_R "the protocol already assures that.." sounds strange. because Bob can prove that Alice has the shared secret only after he has decrypted the 5th message, and has verified the HASH. of course, in the main mode, Bob would be damaged by Alice until decrypting 5th message even if the new approach wasn't adopted. > allows use of arbitrary identifiers and makes this mode work for the > road warrior case. but in the case of the road warrior, the responder cannot decide the SA parameter to be used from the initiator's proposal. because the responder cannot compare with the one's policy database. in section 8, > We argue that it is preferable to hide Alice's identity rather than > Bob's. The protocol could be modified to hide Alice's identity > instead of Bob's from an active attacker. This would be done by > moving the information from msg 6 into msg 4. This even completes the > protocol in one fewer message. why is it preferable for you to hide Alice(i'm assuming the responder)'s identity ? i think there are too many case when the attacker is a initiator. or is my assamption incorrect ? From owner-ipsec@lists.tislabs.com Mon Jul 16 11:14:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GIEYq22957; Mon, 16 Jul 2001 11:14:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10316 Mon, 16 Jul 2001 13:35:55 -0400 (EDT) Message-Id: <200107161742.NAA03854@bcn.East.Sun.COM> Date: Mon, 16 Jul 2001 13:42:26 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: Man in the middle attack (draft-kaufman-ipsec-improveike-00.txt)? To: ipsec@lists.tislabs.com, kballou@quarrytech.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5UcqAVhujnYL8gG4iiSvjA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes. A man-in-the-middle can discover Alice's identity. He can't finish the protocol, as you pointed out, so the only thing he can do is discover Alice's identity. There's no way around this with just using a pre-shared secret between Alice and Bob. Our suggested revised protocol is stronger than the current one. In the current one, Alice's identity is exposed even to a passive attacker...in the main mode, her identity has to be her IP address, which is in the IP header. In aggressive mode, it's sent unencrypted. In the suggested revised protocol, Alice's identity is hidden from passive attackers, but an active attacker will be able to find her identity, but will not be able to do anything more that just discover who is attempt to connect to Bob. If you really want to hide Alice's identity from an active attacker and use a pre-shared Alice-Bob key, I can think of two complication-inducing methods (and I don't like complication-inducing things). 1) have an additional secret key that Bob shares with all legitimate Bob-clients. This was similar to what we had at Digital where there was a single building-wide secret that we needed in order to dial into the terminal server, and then a personal password after that. Each month all employees were told the new building-wide secret. Applying this technique to IKE, messages 5 and 6 could be encrypted in a function of the group secret, so only an active attacker that knew the group secret could discover Alice's identity. 2) Bob could have a public key, and Alice could send her identity encrypted with his public key. But I'd recommend just living with the fact that an active attacker will be able to discover Alice's identity. Radia From: kballou@quarrytech.com To: ipsec@lists.tislabs.com Subject: Man in the middle attack (draft-kaufman-ipsec-improveike-00.txt)? MIME-Version: 1.0 I'm sure I've missed something. In section 7 (main mode with pre-shared keys), isn't Alice's identity susceptible to a man-in-the-middle attack? Could Mallory impersonate Bob for the first two pairs of messages, use the Diffie-Hellman key to learn Alice's identity, and then not finish the protocol? (Of course, since Mallory doesn't know the pre-shared secret, he can't fix up the third message to relay it to Bob even with knowledge of Alice's identity.) - Ken From owner-ipsec@lists.tislabs.com Mon Jul 16 13:06:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GK66q25612; Mon, 16 Jul 2001 13:06:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10634 Mon, 16 Jul 2001 15:30:58 -0400 (EDT) Message-Id: <200107161937.PAA04684@bcn.East.Sun.COM> Date: Mon, 16 Jul 2001 15:37:28 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: I-D ACTION:draft-kaufman-ipsec-improveike-00.txt To: ipsec@lists.tislabs.com, sakane@kame.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Oj1pN9ljjgGYrsHI1K/a7A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> From: Shoichi Sakane >> First, to make sure about Bob and Alice. Bob is the responder, >> and Alice is the initiator in this draft, right ? Correct. I guess I like to write informally. Alice is the initiator, Bob is the responder. Fewer syllables. Yes, the side is important, and when we say "Alice" we mean "initiator". >> about the section 7, >> "the protocol already assures that.." sounds strange. >> because Bob can prove that Alice has the shared secret only after >> he has decrypted the 5th message, and has verified the HASH. >> of course, in the main mode, Bob would be damaged by Alice until >> decrypting 5th message even if the new approach wasn't adopted. Sorry, I don't understand your comment. Perhaps you're saying that Bob has to do expensive computation before knowing that it's Alice? But as you said, whatever issue you're discussing is also true in the old approach. >> > allows use of arbitrary identifiers and makes this mode work for the >> > road warrior case. >> but in the case of the road warrior, the responder cannot decide >> the SA parameter to be used from the initiator's proposal. because >> the responder cannot compare with the one's policy database. If the responder knows the initiator by her name, and not her IP address, then the policy database would have an entry for her name. Or, even if the initiator is known by a name, there might be other policy in addition to policy according to her name, invoked according to the IP address from which she's initiating contact. >> in section 8, >> why is it preferable for you to hide Alice(i'm assuming the responder)'s >> identity ? i think there are too many case when the attacker is a >> initiator. or is my assamption incorrect ? We meant it's preferable to hide the INITIATOR's identity rather than the responder. The responder is more likely at a fixed address. One could imagine a web-site that was politically frowned upon by the initiator's government. The government could impersonate that web site and see who is attempting to connect. But it seems less likely that the responder's IP address would be well-known, and someone would attempt to connect for the sole purpose of discovering who is sitting at that address. One of the parties has to first divulge their identity. So it seems like there are 2 choices: a) protect initiator's identity from active attackers b) protect responder's identity from active attackers Which seems like the more important thing to protect? I certainly don't feel as strongly about this as about getting rid of 3/4 of the variants by removing public key encryption variants and aggressive mode, and fixing shared key to allow arbitrary identities. Radia From owner-ipsec@lists.tislabs.com Mon Jul 16 13:06:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GK69q25628; Mon, 16 Jul 2001 13:06:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10623 Mon, 16 Jul 2001 15:27:34 -0400 (EDT) Message-Id: <3.0.5.32.20010716144744.007bcb80@10.1.1.249> X-Sender: mduffy@10.1.1.249 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 16 Jul 2001 14:47:44 -0400 To: ipsec@lists.tislabs.com From: Mark Duffy Subject: application of security policy to fragments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, RFC 2401 has a table in sect. 4.4.2 (p. 20) covering how Selectors should be applied to packets that are IP fragments. I am trying to understand the rationale behind this. I believe that the 3rd row of the table (augmented by the note immediately following the table) implies that a fragment of a tcp (or udp) datagram should be discarded by a SG if all these points are true: 1. there is an SPD rule specifying protocol tcp (or udp) 2. that rule has source/dest address Selectors compatible with the packet 3. there is no higher-precedence rule in the SPD that matches the packet Agreed so far? I surmise that the rationale for this might be to drop all tcp/udp packets for which, due to the unavaliablity of port numbers in the packet, there is ambiguity over which if any SPD rule the packet should match. Is that the point? If that is the point, it would seem that an SPD rule specifying protocol=tcp, source_port=ANY, dest_port=ANY should not cause fragmented tcp packets to be summarily dropped, since the absence of port numbers in the fragments does not create any ambiguity with respect to that rule. However, I think the 3rd row of the table in 2410 p. 20 does call for packets to be dropped in this case. Is this an oversight? Or just done to simplify things? Other reason?? More generally, and assuming for the sake of discussion that the source/dest address selectors are all set to ANY, the result seems to be that if the SPD contains *any* rule(s) specifying protocol=tcp, then *no* tcp fragments at all could pass, unless matched by a higher prcedence rule that specifies protocol=ANY. This seems a bit harsh. Is this really the intended effect? Thanks, Mark From owner-ipsec@lists.tislabs.com Mon Jul 16 13:49:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GKndq26320; Mon, 16 Jul 2001 13:49:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10729 Mon, 16 Jul 2001 16:12:25 -0400 (EDT) To: Radia.Perlman@sun.com Cc: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-kaufman-ipsec-improveike-00.txt In-Reply-To: Your message of "Mon, 16 Jul 2001 15:37:28 -0400 (EDT)" <200107161937.PAA04684@bcn.East.Sun.COM> References: <200107161937.PAA04684@bcn.East.Sun.COM> X-Mailer: Cue version 0.6 (010413-1707/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20010717051836D.sakane@kame.net> Date: Tue, 17 Jul 2001 05:18:36 +0900 From: Shoichi Sakane X-Dispatcher: imput version 20000228(IM140) Lines: 59 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >> about the section 7, > >> "the protocol already assures that.." sounds strange. > >> because Bob can prove that Alice has the shared secret only after > >> he has decrypted the 5th message, and has verified the HASH. > >> of course, in the main mode, Bob would be damaged by Alice until > >> decrypting 5th message even if the new approach wasn't adopted. > > Sorry, I don't understand your comment. Perhaps you're saying that > Bob has to do expensive computation before knowing that it's Alice? Yes, I am. > But as you said, whatever issue you're discussing is also true in > the old approach. True. so I just say not "already", but "the protocol assures that" > >> > allows use of arbitrary identifiers and makes this mode work for the > >> > road warrior case. > >> but in the case of the road warrior, the responder cannot decide > >> the SA parameter to be used from the initiator's proposal. because > >> the responder cannot compare with the one's policy database. > If the responder knows the initiator by her name, and not her IP address, > then the policy database would have an entry for her name. Or, even > if the initiator is known by a name, there might be other policy in > addition to policy according to her name, invoked > according to the IP address from which she's initiating contact. it must be correct in phase 2. but her name is in identify payload, isn't it ? so Bob cannot decide the parameter of phase1 SA because her identity hasn't been passed to Bob when he consults his database. > >> in section 8, > >> why is it preferable for you to hide Alice(i'm assuming the responder)'s i was mistaken, i meant Alice was the initiator. > >> identity ? i think there are too many case when the attacker is a > >> initiator. or is my assamption incorrect ? > We meant it's preferable to hide the INITIATOR's identity rather than > the responder. The responder is more likely at a fixed address. One could > imagine a web-site that was politically frowned upon by the initiator's > government. The government could impersonate that web site and see who > is attempting to connect. But it seems less likely that the responder's > IP address would be well-known, and someone would attempt to connect > for the sole purpose of discovering who is sitting at that address. agreed. to make sure, i though you meant msg6 into msg4 WITHOUT any encryption because msg4 in RFC2409 is not encrypted. i must be wrong. > I certainly don't feel as strongly about this as about getting > rid of 3/4 of the variants by removing public key encryption variants > and aggressive mode, and fixing shared key to allow arbitrary identities. agreed. thank you. From owner-ipsec@lists.tislabs.com Mon Jul 16 16:49:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6GNnvq29696; Mon, 16 Jul 2001 16:49:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11028 Mon, 16 Jul 2001 19:06:40 -0400 (EDT) Message-ID: <3B5374BA.DDF34137@tellme.com> Date: Mon, 16 Jul 2001 16:11:54 -0700 From: Angus Davis Organization: Tellme Networks X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: where to find interoperability how-to's? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiVirus: scanned for viruses by AMaViS perl-5 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Where should I look for technical how-to's on IPSec interoperability? For example, we are tearing our hair out trying to get our Ravlin to co-exist nicely with a Checkpoint VPN-1. I know this is not the place to ask for such support, but the "Interoperability" page at http://www.vpnc.org/interop.html is fairly useless. Any / all suggestions on where to find this most needed information would be appreciated. Thanks, -angus From owner-ipsec@lists.tislabs.com Mon Jul 16 20:35:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6H3ZKq03642; Mon, 16 Jul 2001 20:35:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11316 Mon, 16 Jul 2001 22:17:27 -0400 (EDT) Message-ID: <3B53A1BB.91BDCC8@storm.ca> Date: Mon, 16 Jul 2001 22:23:55 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: where to find interoperability how-to's? References: <3B5374BA.DDF34137@tellme.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Angus Davis wrote: > > Folks, > Where should I look for technical how-to's on IPSec > interoperability? The docs for the FreeS/WAN Linux implementation of IPSEC are all online. Interop between FreeS/WAN and various other things: http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/interop.html Links to other interop info: http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/web.html#interop > I know this is not the place to ask for such support, but ... If you find good sources that the FreeS/WAN docs do not link to, please either mail me off-list or summarise on the list. I'm the author of the FreeS/WAN stuff and I'd happily add to it. From owner-ipsec@lists.tislabs.com Tue Jul 17 04:38:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HBcQq06350; Tue, 17 Jul 2001 04:38:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12236 Tue, 17 Jul 2001 06:43:45 -0400 (EDT) Message-Id: <200107171049.GAA09379@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-richardson-ipsec-opportunistic-00.txt Date: Tue, 17 Jul 2001 06:49:26 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A method for doing opportunistic encryption with IKE Author(s) : M. Richardson et al. Filename : draft-richardson-ipsec-opportunistic-00.txt Pages : 21 Date : 16-Jul-01 This document discusses a method used by the Linux FreeS/WAN project to opportunistically encrypt traffic between coorperating peers and networks. It describes the infrastructure necessary for this configuration. The security benefits of doing this are outlined as well, as are the risks. This document is offered up as an Informational RFC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-00.txt 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-richardson-ipsec-opportunistic-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-richardson-ipsec-opportunistic-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: <20010716153126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-richardson-ipsec-opportunistic-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-richardson-ipsec-opportunistic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010716153126.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jul 17 07:12:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HECpq09007; Tue, 17 Jul 2001 07:12:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12558 Tue, 17 Jul 2001 09:20:28 -0400 (EDT) From: "Jia-Chi Jau" To: Cc: "ipsec" Subject: ARP request Date: Mon, 16 Jul 2001 17:03:40 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, there: Our gateway does not have ARP now, so I just setup static ARP entry for the gateway IP. It works fine before I apply the evaluation kit(IPSec). After I execute "sshipm", the window2000 sends ARP request for gateway IP and it does not use the static ARP entry in its table? How can I get away from it? Thanks. Jia-Chi From owner-ipsec@lists.tislabs.com Tue Jul 17 11:30:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6HIUAq10709; Tue, 17 Jul 2001 11:30:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13370 Tue, 17 Jul 2001 13:40:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rsent-To: eos@ops.ietf.org From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Message-Id: Date: Tue, 17 Jul 2001 13:25:25 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From owner-ipsec@lists.tislabs.com Wed Jul 18 04:46:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IBkJq28384; Wed, 18 Jul 2001 04:46:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15031 Wed, 18 Jul 2001 06:56:31 -0400 (EDT) Message-Id: <200107181102.HAA27195@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-improveike-00.txt Date: Wed, 18 Jul 2001 07:02: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 : Code-preserving Simplifications and Improvements to IKE Author(s) : C. Kaufman et al. Filename : draft-ietf-ipsec-improveike-00.txt Pages : 8 Date : 17-Jul-01 This internet draft recommends modifications to Phase 1 IKE that will minimize code changes. We recommend simplification by removing some of the options, and minimal changes, when they provide a large increase in functionality, in the remaining portions of IKE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-improveike-00.txt 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-improveike-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-ietf-ipsec-improveike-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: <20010717144205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-improveike-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-improveike-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717144205.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jul 18 04:46:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IBkQq28397; Wed, 18 Jul 2001 04:46:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15043 Wed, 18 Jul 2001 06:56:42 -0400 (EDT) Message-Id: <200107181102.HAA27273@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-antireplay-00.txt Date: Wed, 18 Jul 2001 07:02:23 -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 : Using Isakmp Message Ids for Replay Protection Author(s) : A. Krywaniuk Filename : draft-ietf-ipsec-antireplay-00.txt Pages : 8 Date : 17-Jul-01 This document describes a method for adding explicit replay protection to IKE messages by altering the use of the message id in the ISAKMP header. We suggest that this change could be applied as part of the next revision of IKE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-antireplay-00.txt 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-antireplay-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-ietf-ipsec-antireplay-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: <20010717144236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-antireplay-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-antireplay-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717144236.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jul 18 04:46:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IBkSq28408; Wed, 18 Jul 2001 04:46:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15037 Wed, 18 Jul 2001 06:56:36 -0400 (EDT) Message-Id: <200107181102.HAA27232@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-properties-00.txt Date: Wed, 18 Jul 2001 07:02:18 -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 : Security Properties of the IPsec Protocol Suite Author(s) : A. Krywaniuk Filename : draft-ietf-ipsec-properties-00.txt Pages : 17 Date : 17-Jul-01 This document describes the 'security properties' of the IPsec architecture and protocols, including ESP, AH, and IKE. By documenting these properties, we aim to provide a guide for users who wish to understand the abilities and limitations of the IPsec protocol suite. We also hope to provide motivation for future work in this area. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-properties-00.txt 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-properties-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-ietf-ipsec-properties-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: <20010717144225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-properties-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-properties-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717144225.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jul 18 06:26:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IDQwq14515; Wed, 18 Jul 2001 06:26:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15500 Wed, 18 Jul 2001 08:49:02 -0400 (EDT) Message-Id: <200107180205.f6I25vB17962@marajade.sandelman.ottawa.on.ca> To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: per-host keying In-reply-to: Your message of "Mon, 16 Jul 2001 10:21:59 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 17 Jul 2001 22:05:56 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> At 8:37 PM -0400 7/14/01, Michael Richardson wrote: >> Thanks for the responses. I figured that I was blind. >> >> Should 2401 be revised at some point, I suggest the words "per-host keying" >> be added to 4.4.1 section (a). Stephen> In revising 2401 I plan to reword the selector discussion Stephen> extensively, to clarify this detail that, as you noted, is easily Stephen> missed. However, I would not call it "per host keying" because it Stephen> can be used to achieve finer granularity keying. Still, we can put Stephen> in the phrase (to make it easy to search for) as part of the Stephen> discussion. I suggest just adding text like: "This mode can not only be used to create per-host or per-port keyed SAs, but also to create new SA based upon unique values of any set of selectors." Anyway... thanks for all the pointers. ] 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"); [ From owner-ipsec@lists.tislabs.com Wed Jul 18 11:20:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IIKBq10322; Wed, 18 Jul 2001 11:20:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16329 Wed, 18 Jul 2001 13:02:26 -0400 (EDT) Reply-To: From: "=?iso-8859-1?Q?Tuomas_A._Sir=E9n?=" To: Subject: [UPDATE] VPN Bakeoff, Finland, August 13 thru 18, http://bakeoff.ipsec.com/ Date: Wed, 18 Jul 2001 19:49:40 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk http://bakeoff.ipsec.com/ The next IPsec Interoperability workshop a.k.a Bakeoff will be held in Finland from August 13 thru 18 (Monday - Saturday). This is the week following the IETF meeting in London, so you may combine your travelling. The venue will be Dipoli (http://www.dipoli.hut.fi/english/) in Espoo (close to Helsinki) in the Helsinki University of Technology campus area. Flight destination will be Helsinki (Helsinki-Vantaa international airport - about 3 hour flight from London), the Bakeoff venue is under 30 minute (20 km) drive south-west from the airport, 10 km (6 miles) from downtown Helsinki. The event will start on Monday afternoon i.e. the participants may start installing their equipment then. The final day is Saturday, all equipment must be removed Saturday afternoon. There will be no storage space available before the bakeoff, therefore, you will have to schedule arrival of your equipment to Monday afternoon. The nearest hotel is Radisson SAS Espoo (http://www.hotelsfinland.com/espoo/rivoli_espoo/) only two minutes walk from Dipoli. We have reserved some 100 rooms for bakeoff attendees. If you book your hotel room at this hotel through your own channels already before registering, please, mention Bakeoff when making the reservation. Other hotels are available in Helsinki, next closest is probably Kalastajatorppa (http://www.scandic-hotels.com/br/50/hotel.asp?id=107) about 4 km (2.5 miles) from Dipoli. [UPDATE] Be sure to reserve by July 23, 2001 to insure that rooms will be available for you and your group. [UPDATE] -Tuomas A. Sirén tuomas.siren@ssh.com SSH Communications Security Corporation From owner-ipsec@lists.tislabs.com Wed Jul 18 15:04:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6IM4Mq17205; Wed, 18 Jul 2001 15:04:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16748 Wed, 18 Jul 2001 17:10:05 -0400 (EDT) Date: Wed, 18 Jul 2001 17:02:29 -0400 From: John Wells @eagle.ee.vt.edu@eagle.ee.vt.edu To: mobile-ip@sunroof.eng.sun.com Cc: ipsec@lists.tislabs.com Subject: Solution for using MIP6 for client location hiding Message-ID: <20010718170229.A8608@horus.imag.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --/04w6evG8XlLl3ft Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, I've just finished a report on using Mobile IPv6 to hide the true IP address of a mobile node from its correspondant, though the technique is general to all IPv6 and also IPv4 nodes.=20 The paper and associated presentation slides are available on this web site: http://www.ee.vt.edu/~wells. Here is the abstract: Cloaking is a technique whereby a source can hide its location from a receiver under IPv6. Relying on other standardized protocols, in particular IPsec, Mobile IP, and HMIPv6, to provide encryption and a large part of the implementation for the machines implicated, cloaking solves this problem in an extremely lightweight manner. Conceived for IPv6, it delicately avoids solving problems already solved in that domain. That is, it only hides its location and identity from the receiver; it makes no attempt to hide its identity from intermediate observers; several privacy extensions already provide this capability.=20 mercredi, le 18 juil 2001 =E0 10h45 -0400, Hongyi Li a =E9crit : > Hi, > I submitted a LMM framework draft to MIP group last week. As > I am not going to attend the London meeting, I would to like to > have some discussions / feedback about the draft on the mailing > list. >=20 > Here it the link to the draft: > http://www.ietf.org/internet-drafts/draft-li-mobileip-lmm-framework-00.txt >=20 > Regards >=20 > Hongyi >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > > Sent: Tuesday, July 17, 2001 2:35 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: [mobile-ip] proposed agenda > >=20 > >=20 > >=20 > > Hi folks, > >=20 > > here's a new version of the agenda. Although the history=20 > > of the working > > group has been > > to allow presentations of as many drafts as possible, this meeting > > represents a departure > > from tradition. Essentially we're going to use the time only=20 > > for discussing > > those things > > which seem to indicate a need for face-to-face discussion=20 > > time. We would > > prefer to discuss > > and resolve most of the working group issues on the mailing=20 > > list. If you > > believe there > > is an issue that needs to be discussed that is not covered by=20 > > the agenda, > > please post to > > the mailing list describing what it is and why. If you have=20 > > a draft with an > > interesting > > idea that the working group should consider for standardization or > > documentation, please > > attempt to generate a discussion on the mailing list. > >=20 > > Phil and Raj > >=20 > > Agenda Phil 5 minutes > > Update on WG docs Phil 10 minutes > >=20 > > This slot is for last minute updates. Here is the current=20 > > status of docs > > that are in last call or submitted to Abha. > >=20 > > draft-ietf-mobileip-mier-07.txt (submitted) > > draft-ietf-mobileip-gnaie-04.txt (submitted) > > draft-ietf-mobileip-3g wireless-ext-06.txt (being updated=20 > > based on IESG > > feedback) > > draft-ietf-mobileip-rfc2002-bis-06.txt (being updated based on IESG > > feedback) > > draft-ietf-mobileip-gen-key-00.txt (wg last call expires=20 > > Friday 7/20 > > hopefully submitted) > > draft-ietf-mobileip-aaa-key-07.txt (to be submitted Friday 7/20) > > draft-ietf-mobileip-qos-requirements-00.txt (wg last call=20 > > expires 7/25) > > draft-ietf-mobileip-reg-tunnel-04.txt (being updated) > > draft-ietf-mobileip-optim-10.txt (past wg last call,=20 > > sitting on it until > > MIP v6 > > issues resolved) > >=20 > > Moving MIPv4 to draft standard Charlie 10 minutes > >=20 > > Mobile IP v6 security update ?=20 > > draft-team-mobileip-mipv6-sec-reqts-00.txt > > 15 minutes > > Mobile IP v6 other changes in -14 Charlie 5 minutes > > draft-ietf-mobileip-ipv6-14.txt > >=20 > > v4 Low Latency Handover Karim 5 minutes > > draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt > > Is there anyone who can share implementation experiences? > > Is this doc ready for last call? > >=20 > > v6 Fast Handover draft-ietf-mobileip-fast-mipv6-01.txt > > BETH addition? James 10 minutes draft-kempf-beth-ipv6-01.txt > > Implementation experience report Rajeev Koodli 10 minutes > >=20 > > Mobile Network Support Thierry Ernst 15 minutes > > Mobile IP Component Redundancy Gopal 10 minutes > >=20 > > LMM Requirements Carl Williams 15 minutes > > (draft-ietf-mobileip-lmm-requirements-00.txt) > >=20 > > Issues from the list Raj 15 minutes > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 --=20 John WELLS INRIA Rh=F4ne-Alpes, Plan=E8te Project - ENSIMAG 3A/T=E9l=E9comm et R=E9sea= ux Virginia Tech Networking and Visualization Lab PGP Public key: http://www.inrialpes.fr/planete/people/wells/pgpkey.txt --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQE7VflktvPFKAfa3SIRAlPWAKCAJmGJrFH98FR9dOwGphX0EnwhEwCfW8zH kL22x9R32Ku5ElCPtDCsNTE= =Ncxf -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-ipsec@lists.tislabs.com Wed Jul 18 20:43:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6J3h0q29345; Wed, 18 Jul 2001 20:43:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17310 Wed, 18 Jul 2001 22:39:56 -0400 (EDT) Message-Id: <200107190246.WAA18482@bcn.East.Sun.COM> Date: Wed, 18 Jul 2001 22:46:34 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: What does SIT_IDENTITY_ONLY mean? To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: aYxfgCuTkinr4rDDD2IzXw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The "situation" for IKE's DOI as defined in RFC 2407 has 3 bits defined. The bottom one, SIT_IDENTITY_ONLY seems to be defined as indicating that there's an identity payload. Given that you can tell if there's an identity payload, why do you need a bit to tell you that there is one? Anyway, I'm confused. What is that bit for? Thanks, Radia From owner-ipsec@lists.tislabs.com Fri Jul 20 03:24:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KAOBq23113; Fri, 20 Jul 2001 03:24:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA21346 Fri, 20 Jul 2001 05:28:50 -0400 (EDT) Message-Id: <200107200934.FAA05093@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-01.txt Date: Fri, 20 Jul 2001 05:34:33 -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-01.txt Pages : Date : 19-Jul-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-01.txt 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-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-sctp-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: <20010719145630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-sctp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-sctp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145630.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 20 03:24:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KAOGq23125; Fri, 20 Jul 2001 03:24:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA21379 Fri, 20 Jul 2001 05:42:58 -0400 (EDT) Message-Id: <200107200935.FAA05439@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ippcp@external.cisco.com, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shacham-ippcp-rfc2393bis-08.txt Date: Fri, 20 Jul 2001 05:35:22 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Payload Compression Protocol (IPComp) Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas Filename : draft-shacham-ippcp-rfc2393bis-08.txt Pages : 11 Date : 19-Jul-01 This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-08.txt 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-shacham-ippcp-rfc2393bis-08.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-shacham-ippcp-rfc2393bis-08.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: <20010719145755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shacham-ippcp-rfc2393bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-shacham-ippcp-rfc2393bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145755.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 20 03:24:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KAOHq23135; Fri, 20 Jul 2001 03:24:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA21340 Fri, 20 Jul 2001 05:28:41 -0400 (EDT) Message-Id: <200107200934.FAA05046@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-gss-auth-07.txt Date: Fri, 20 Jul 2001 05:34:25 -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 : A GSS-API Authentication Method for IKE Author(s) : D. Piper, B. Swander Filename : draft-ietf-ipsec-isakmp-gss-auth-07.txt Pages : 13 Date : 19-Jul-01 This document describes an alternate authentication method for IKE which makes use of GSS-API to authenticate the Diffie-Hellman exchange. The mechanism described here extends the authentication methods defined in RFC-2409 without introducing any modifications to the IKE key exchange protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-07.txt 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-gss-auth-07.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-gss-auth-07.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: <20010719145621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-gss-auth-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-gss-auth-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145621.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 20 11:55:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6KIt5q14509; Fri, 20 Jul 2001 11:55:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22166 Fri, 20 Jul 2001 13:50:22 -0400 (EDT) Date: Fri, 20 Jul 2001 10:17:34 -0700 (PDT) From: Avram Shacham X-Sender: shacham@zev.net To: ippcp@external.cisco.com cc: ipsec@lists.tislabs.com Subject: Re: I-D ACTION:draft-shacham-ippcp-rfc2393bis-08.txt In-Reply-To: <200107200935.FAA05439@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The changes in version 08 are editorial only, adding (a) A statement that the document obsoletes RFC 2393. (b) The list of changes made since RFC 2393 of which an implementer of RFC 2393 should be aware. This section summarizes the release notes that were posted to the lists with each change of the I-D. Regards, avram On Fri, 20 Jul 2001 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IP Payload Compression Protocol (IPComp) > Author(s) : A. Shacham, R. Monsour, R. Pereira, M. Thomas > Filename : draft-shacham-ippcp-rfc2393bis-08.txt > Pages : 11 > Date : 19-Jul-01 > > This document describes a protocol intended to provide lossless > compression for Internet Protocol datagrams in an Internet > environment. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shacham-ippcp-rfc2393bis-08.txt [...] From owner-ipsec@lists.tislabs.com Sun Jul 22 16:47:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6MNlJq11176; Sun, 22 Jul 2001 16:47:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25828 Sun, 22 Jul 2001 18:40:19 -0400 (EDT) Message-ID: <002e01c11300$9ded8000$0d00000a@testone.masconit.com> Reply-To: "Ranjit Avasarala" From: "Ranjit Avasarala" To: Subject: IP Sec Vs Ip Masq Date: Sun, 22 Jul 2001 17:49:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA25825 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Is IP Sec related to IP Masquerading? like is it possible to club IP Sec with IP Forwarding rule set? thanks Regards Ranjit From owner-ipsec@lists.tislabs.com Sun Jul 22 20:16:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6N3GOq14489; Sun, 22 Jul 2001 20:16:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA26151 Sun, 22 Jul 2001 22:22:28 -0400 (EDT) Message-ID: <3B5B8C21.851DD927@netopia.com> Date: Mon, 23 Jul 2001 10:29:54 +0800 From: "Ildebrando Layon" X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec Subject: ipsec comparison Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm new to this group and I dont know if this had been ask before. Im looking for some comparison information , advantage/disadvantage of using IPsec, IPsec vs L2TP,PPTP,GRE. Regards, Brando Layon From owner-ipsec@lists.tislabs.com Sun Jul 22 21:00:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6N40Xq15061; Sun, 22 Jul 2001 21:00:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26236 Sun, 22 Jul 2001 23:20:58 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IP Sec Vs Ip Masq Date: Sun, 22 Jul 2001 20:28:06 -0700 Message-ID: <4EBB5C35607E7F48B4AE162D956666EF3390ED@guam.corp.axcelerant.com> Thread-Topic: IP Sec Vs Ip Masq Thread-Index: AcETFli8Jc9wbwr1QHKXyxwCMtbccQAEVoFg From: "Christopher Gripp" To: "Ranjit Avasarala" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id XAA26233 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IP Masquerading (a Linux term) is the same as Network Address Translation. IPSec is a group of protocols to provide data encryption and authentication. IPSec MAY be used in conjunction with IP Masquerading but, does not have to be. Christopher Gripp Systems Engineer Axcelerant -----Original Message----- From: Ranjit Avasarala [mailto:ranjitka@email.masconit.com] Sent: Sunday, July 22, 2001 3:50 PM To: ipsec@lists.tislabs.com Subject: IP Sec Vs Ip Masq Hi Is IP Sec related to IP Masquerading? like is it possible to club IP Sec with IP Forwarding rule set? thanks Regards Ranjit From owner-ipsec@lists.tislabs.com Mon Jul 23 08:36:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NFaMq25498; Mon, 23 Jul 2001 08:36:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA27768 Mon, 23 Jul 2001 10:23:47 -0400 (EDT) Message-ID: <198522001762111449570@EAGLE> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 Reply-To: res02mg1@gte.net X-MSMail-Priority: Normal From: "David C. Dickson" To: IPSEC@lists.tislabs.com Subject: 21st Century Commerce Int'l EXPO 2001 - Training Conference - Phoenix, AZ Date: Fri, 20 Jul 2001 21:14:49 -0400 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id VAA22880 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To: IPSEC@LISTS.TISLABS.COM TRAINING CONFERENCE: 21st Century Commerce International EXPO 2001 E-Business://Building Integrated Solutions September 10-13, 2001 Phoenix Civic Plaza Phoenix, Arizona Main Program: Registration: 7:30 a.m., September 11 Program Begins: 8:30 a.m., September 11 Wrap-up: 3:30 p.m., September 13 Continental Breakfast, Refreshments and Lunches included. About the Conference: The 21st Century Commerce International EXPO 2001 will be held in Phoenix, Arizona, September 10-13, 2001. The conference was created in 1987 as a conference and trade exhibition focused on IT solutions for the government marketplace and the Department of Defense. The EXPO has expanded to encompass commercial marketplace best business practices. EXPO offers you an opportunity to hear from some of the nations top business leaders who will discuss and examine all aspects of e-business, from infrastructure to enterprise architecture, to hardware and software, to security issues. On the trade show floor, you will see successful e-business in action: from government agencies to Fortune 500 companies to small- and medium-size enterprises making a difference for tomorrow's wired world. Who should attend: * Senior Managers (government and Industry) * Chief Information Officers * Knowledge Officers * International Business Leaders * eBusiness Architects * Information Technology Officers * Program Managers * Product Data Managers * Customer Relations Managers * Technology Providers * Small-Medium-Large Enterprises * Data Conversion Managers and Providers * Application Service Providers Among those areas that will be discussed in the tracks are: * Defining Requirements for Integrated Solutions * Strategy Focused Execution * Exploiting Value Chain Management * Electronic Enterprises-Broadening Your Space * Integrated Technologies * Electronic Government Enterprise-Governing Beyond Borders Key Presentations: * Mr. Robert D. Johnson, Executive Vice President and COO, Honeywell International and President and CEO, Honeywell Aerospace * Ms. Mary J. Mitchell, Program Executive for Electronic Government Policy, General Services Administration * Mr. Jack Garrison, Director of Integrated Logistics, Lockheed Martin * LTG Daniel G. Brown, Deputy Commander in Chief, US Transportation Command * LTG Charles S. Mahan, Jr., Deputy Chief of Staff for Logistics, US Army * RADM Ray Archer, Defense Logistics Agency * Ms. Ariane Whittemore, Assistant Deputy Chief of Naval Operations, (Fleet Readiness and Logistics) * Dr. Palmer Smith, Director of Government Solutions, Sabre, Inc. * Mr. John F. Phillips, Vice President of Aftermarket Growth, Honeywell * Mr. Barry Lerner, Vice President of Government Sales, Exostar, LLC * Mr. Walt Kozak, PricewaterhouseCoopers * Mr. Pat Holcomb, CommerceOne * Mr. Craig York, Honeywell International Three ways to register: * On-line at www.21cc.org * By fax at 703-522-3192 * By mail: AFEI, 2111 Wilson Boulevard, Suite 400, Arlington, VA 22201 Register prior to August 31 for Early Bird rates! AFEI Members: $750 Government Employees: $825 Non-Member: $900 Tutorials: $100 (September 10) GSA (MOBIS/LOGWORLD Training): $75 (September 10) Tutorials Sessions Include: * Introduction to Supply Chain Management including practical steps in planning for implementation * How to conduct auctions on the Internet. Reverse auctions - how they work - how DoD is using reverse auctions to save money * Strategy Focused Execution including an introduction to Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) * XML with examples of the practical application of XML within Industry and Government * Introduction to Enterprise Application Integration (EAI) * Configuration Management (The transition to an Industry-wide standard) We are pleased to announce that GSA will be holding a LOGWORLD/ MOBIS training session during the EXPO this year. This year the General Services Administration's (GSA) procurement innovations will be presented at the 21st Century Commerce International EXPO 2001 on September 10. GSA will provide training at EXPO 2001 for contractors and Federal agencies interested in the Logistics Worldwide (LOGWORLD) and Management, Organizational and Business Improvement Services (MOBIS) schedule contracts. LOGWORLD enables Federal agencies to procure comprehensive logistics solutions to enhance or replace existing operations and capabilities. Examples of the type of services provided under this schedule include Supply and Value Chain Management; Acquisition Logistics; Distribution and Transportation Logistics; Deployment Logistics; Logistics training services, support products and new services. MOBIS provides Federal agencies with a tool to seek expert advice for improving management and organizational effectiveness. Examples of the type of services provided under the MOBIS schedule are consulting services; facilitation services; survey services; Alternative Dispute Resolution (ADR) services; A76 study support; project management services; training services and support products. www.northwest.gsa.gov/fss/msc Executive Roundtable: This years Executive Roundtable (ERT) theme is Returns on Business Investments in the New Reality. The ERT is a special session for senior management (CEO, COO, CIO, CTO, Sr. Vice Presidents, Presidents, Executive Directors) and is offered by invitation only. If you would like to request an invitation, please contact Michelle Bourke at mbourke@afei.org. Exhibit: Booth space will be reserved on a first-come, first-served basis. Reserve your preferred location as soon as possible. The floorplan has been configured to maximize traffic throughout the display area, and the program schedule will be designed to encourage attendee participation. For more information on available booth space and prices, go to http://www.21cc.org/01exhibits.htm. We have already sold 50% of our booth spaces! Sign up soon! Conference Sponsors: * EXOSTAR * Sprint E Solutions * CSC * Phoenix Business Journal * Government Computer News * National Defense Industrial Association * National Defense Magazine * Thomas Group * BidSource * The Greater Phoenix Chamber of Commerce To view sponsorship opportunities, please visit the website at www.21cc.org Contact: Michelle Beckner Bourke, EXPO Conference Manager, at (703) 247-9473, mbourke@afei.org; If you wish to be REMOVED from this list, please REPLY by placing REMOVE in the subject line. Thank you From owner-ipsec@lists.tislabs.com Mon Jul 23 09:11:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NGBJq28827; Mon, 23 Jul 2001 09:11:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28274 Mon, 23 Jul 2001 11:28:45 -0400 (EDT) Message-ID: <3B5C440D.60596952@storm.ca> Date: Mon, 23 Jul 2001 11:34:37 -0400 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ildebrando Layon CC: ipsec Subject: Re: ipsec comparison References: <3B5B8C21.851DD927@netopia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ildebrando Layon wrote: > > Hi, > I'm new to this group and I dont know if this had been ask before. Im > looking for some comparison information > , advantage/disadvantage of using IPsec, There's some discussion of this in the documentation for the Linux FreeS/WAN IPSEC implementation: http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/ipsec.html#advantages The comparison there is IPSEC vs. things at other kevels, PGP, SSL, .. > IPsec vs L2TP,PPTP,GRE. www.counterpane.com has relevant papers by Schneier and co-authors. Simplified summaries: PPTP is insecure. IPSEC is far too complex. From owner-ipsec@lists.tislabs.com Mon Jul 23 10:25:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NHPiq00575; Mon, 23 Jul 2001 10:25:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28508 Mon, 23 Jul 2001 12:41:12 -0400 (EDT) From: Rett_Walters@payless.com Subject: IPSec Standard - No Flow Control? To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 23 Jul 2001 11:48:44 -0500 X-MIMETrack: Serialize by Router on PSAMAILC/PSS(Release 5.0.7 |March 21, 2001) at 07/23/2001 11:48:47 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a question regarding IPsec inner workings..... Is there a provision for Flow Control in the IPSec Standards? I understand that IPSec essentially runs at Layer 3 which does not include flow control algorithms (usually left to Layer 4 protocols such as TCP); however I have noticed in live implementations of the protocol, long delay networks (250ms round-trip) suffer serious performance issues when compared to non-encrypted TCP communications such as Ftp's, using large (64k) TCP Receive Windows. Trace analysis shows a large percentage of time spent waiting for ACKs to transmitted ESP packets. Is there no way to control the amount of data "in flight", ie setting a higher Window? Using IPSec Encapsulation seems to override or Break the TCP Windows set in the encrypted packet headers, do to its own method of flow control (or lack thereof)..... I am wondering if this was overlooked? Thanks, ___________________________________ Rett D. Walters Network Architect Payless ShoeSource Inc. Phone: 785-295-2049, Fax: 785-295-6666 Email: rett.walters@payless.com From owner-ipsec@lists.tislabs.com Mon Jul 23 11:03:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NI38q01305; Mon, 23 Jul 2001 11:03:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28670 Mon, 23 Jul 2001 13:20:10 -0400 (EDT) From: "Paul Onions" To: Subject: DEFLATE, ZLIB and RFC1951 Date: Mon, 23 Jul 2001 18:13:30 +0100 Message-ID: <000001c1139a$ce083420$a400a8c0@siliconinfusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In the description of DEFLATE in RFC1951 it states that the compressed data is in the form of a sequence of blocks, where each block has a 3-bit header consisting of a BFINAL bit and a BTYPE bit-pair. The BFINAL bit identifies the last block of the sequence and the BTYPE pair indicates whether the block is either non-compressed, compressed with fixed huffman codes, or compressed with dynamic huffman codes. My question is how these bits should be handled when using ZLIB? I can't find any explicit mention of these bits in the ZLIB documentation and, after playing around with ZLIB (using the python module), it seems that it does not produce/understand these bits. Is this correct (and they have to be handled external to ZLIB), or am I misunderstanding something here? Any help would be appreciated, Paul(o) From owner-ipsec@lists.tislabs.com Mon Jul 23 11:12:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NIClq01502; Mon, 23 Jul 2001 11:12:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28737 Mon, 23 Jul 2001 13:35:49 -0400 (EDT) To: Rett_Walters@payless.com Cc: ipsec@lists.tislabs.com Subject: Re: IPSec Standard - No Flow Control? References: From: Derek Atkins Date: 23 Jul 2001 13:42:27 -0400 In-Reply-To: Rett_Walters@payless.com's message of "Mon, 23 Jul 2001 11:48:44 -0500" Message-ID: Lines: 44 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are no ACKs to ESP packets. The encapsulated TCP should be handling the ACKs at (encrypted) layer-4. Could you explain what you mean by a "trace analysis showing a large percentage of time spent waiting for CKs to transmitted ESP packets"? Also, what platform(s) and IPsec implementation(s) are you using? -derek Rett_Walters@payless.com writes: > I have a question regarding IPsec inner workings..... > > Is there a provision for Flow Control in the IPSec Standards? > > I understand that IPSec essentially runs at Layer 3 which does not include > flow control algorithms (usually left to Layer 4 protocols such as TCP); > however I have noticed in live implementations of the protocol, long delay > networks (250ms round-trip) suffer serious performance issues when compared > to non-encrypted TCP communications such as Ftp's, using large (64k) TCP > Receive Windows. Trace analysis shows a large percentage of time spent > waiting for ACKs to transmitted ESP packets. Is there no way to control > the amount of data "in flight", ie setting a higher Window? Using IPSec > Encapsulation seems to override or Break the TCP Windows set in the > encrypted packet headers, do to its own method of flow control (or lack > thereof)..... > > I am wondering if this was overlooked? > > Thanks, > > ___________________________________ > Rett D. Walters > Network Architect > Payless ShoeSource Inc. > Phone: 785-295-2049, Fax: 785-295-6666 > Email: rett.walters@payless.com > > -- 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 Jul 23 11:44:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NIi7q02160; Mon, 23 Jul 2001 11:44:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28778 Mon, 23 Jul 2001 13:50:00 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15196.25905.942643.173464@thomasm-u1.cisco.com> Date: Mon, 23 Jul 2001 10:56:01 -0700 (PDT) To: Rett_Walters@payless.com Cc: ipsec@lists.tislabs.com Subject: IPSec Standard - No Flow Control? In-Reply-To: References: 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 It may be what you're seeing is an artifact of the replay sequence number processing not allowing the full TCP receive window's worth of in flight data. Typically, the replay window is about 32-64 bits, which may be on the edge of interfering with your TCP window. Adjusting its window upward may help, but it's possible that there may be some limits to the size. Mike Rett_Walters@payless.com writes: > I have a question regarding IPsec inner workings..... > > Is there a provision for Flow Control in the IPSec Standards? > > I understand that IPSec essentially runs at Layer 3 which does not include > flow control algorithms (usually left to Layer 4 protocols such as TCP); > however I have noticed in live implementations of the protocol, long delay > networks (250ms round-trip) suffer serious performance issues when compared > to non-encrypted TCP communications such as Ftp's, using large (64k) TCP > Receive Windows. Trace analysis shows a large percentage of time spent > waiting for ACKs to transmitted ESP packets. Is there no way to control > the amount of data "in flight", ie setting a higher Window? Using IPSec > Encapsulation seems to override or Break the TCP Windows set in the > encrypted packet headers, do to its own method of flow control (or lack > thereof)..... > > I am wondering if this was overlooked? > > Thanks, > > ___________________________________ > Rett D. Walters > Network Architect > Payless ShoeSource Inc. > Phone: 785-295-2049, Fax: 785-295-6666 > Email: rett.walters@payless.com > > From owner-ipsec@lists.tislabs.com Mon Jul 23 13:11:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NKBGq04324; Mon, 23 Jul 2001 13:11:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29098 Mon, 23 Jul 2001 15:28:19 -0400 (EDT) From: "Joseph D. Harwood" To: "Michael Thomas" , Cc: Subject: RE: IPSec Standard - No Flow Control? Date: Mon, 23 Jul 2001 12:35:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_01C11374.04C77880" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <15196.25905.942643.173464@thomasm-u1.cisco.com> X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C11374.04C77880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, Are you saying the packets are arriving far enough out of order that some are being discarded because of the sequence number checks? Best Regards, Joseph D. Harwood 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 Michael Thomas > Sent: Monday, July 23, 2001 10:56 AM > To: Rett_Walters@payless.com > Cc: ipsec@lists.tislabs.com > Subject: IPSec Standard - No Flow Control? > > > > It may be what you're seeing is an artifact of the > replay sequence number processing not allowing the > full TCP receive window's worth of in flight data. > Typically, the replay window is about 32-64 bits, > which may be on the edge of interfering with your > TCP window. Adjusting its window upward may help, > but it's possible that there may be some limits to > the size. > > Mike > > Rett_Walters@payless.com writes: > > I have a question regarding IPsec inner workings..... > > > > Is there a provision for Flow Control in the IPSec Standards? > > > > I understand that IPSec essentially runs at Layer 3 which does > not include > > flow control algorithms (usually left to Layer 4 protocols > such as TCP); > > however I have noticed in live implementations of the > protocol, long delay > > networks (250ms round-trip) suffer serious performance issues > when compared > > to non-encrypted TCP communications such as Ftp's, using large > (64k) TCP > > Receive Windows. Trace analysis shows a large percentage of time spent > > waiting for ACKs to transmitted ESP packets. Is there no way > to control > > the amount of data "in flight", ie setting a higher Window? > Using IPSec > > Encapsulation seems to override or Break the TCP Windows set in the > > encrypted packet headers, do to its own method of flow control (or lack > > thereof)..... > > > > I am wondering if this was overlooked? > > > > Thanks, > > > > ___________________________________ > > Rett D. Walters > > Network Architect > > Payless ShoeSource Inc. > > Phone: 785-295-2049, Fax: 785-295-6666 > > Email: rett.walters@payless.com > > > > ------=_NextPart_000_0016_01C11374.04C77880 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0016_01C11374.04C77880-- From owner-ipsec@lists.tislabs.com Mon Jul 23 13:16:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NKGkq04512; Mon, 23 Jul 2001 13:16:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29039 Mon, 23 Jul 2001 15:04:51 -0400 (EDT) From: Rett_Walters@payless.com Subject: Re: IPSec Standard - No Flow Control? To: Derek Atkins Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 23 Jul 2001 14:12:08 -0500 X-MIMETrack: Serialize by Router on PSAMAILC/PSS(Release 5.0.7 |March 21, 2001) at 07/23/2001 02:12:22 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek: Excuse my Terminology. It appears that for each Payload packet sent, there is a small (Approx 98 Byte ESP) frame sent back, now, these could be the encrypted Layer-4 acknowledgements. Here is a sample of the trace: # DeltaT Dest Src Size Summary 1","0.000.000 ","[203.163.90.253] ","[12.13.74.69] "," 1490 ","IP"," ESP SPI=198778318" 2","0.001.198 ","[203.163.90.253] ","[12.13.74.69] "," 1490 ","IP"," ESP SPI=198778318" 3","0.001.191 ","[203.163.90.253] ","[12.13.74.69] "," 1490 ","IP"," ESP SPI=198778318" 4","0.001.243 ","[203.163.90.253] ","[12.13.74.69] "," 1490 ","IP"," ESP SPI=198778318" 5","0.003.525 ","[203.163.90.253] ","[12.13.74.69] "," 1306 ","IP"," ESP SPI=198778318" 6","0.000.136 ","[12.13.74.69] ","[203.163.90.253] "," 98 ","IP"," ESP SPI=1261713583" 7","0.001.377 ","[12.13.74.69] ","[203.163.90.253] "," 98 ","IP"," ESP SPI=1261713583" 8","0.001.510 ","[12.13.74.69] ","[203.163.90.253] "," 98 ","IP"," ESP SPI=1261713583" 9","0.000.418 ","[12.13.74.69] ","[203.163.90.253] "," 98 ","IP"," ESP SPI=1261713583" 10","0.071.579 ","[203.163.90.253] ","[12.13.74.69] "," 1490 ","IP"," ESP SPI=198778318" 11","0.001.145 ","[203.163.90.253] ","[12.13.74.69] "," 1490 ","IP"," ESP SPI=198778318" 12","0.001.227 ","[203.163.90.253] ","[12.13.74.69] "," 1490 ","IP"," ESP SPI=198778318" 13","0.001.209 ","[203.163.90.253] ","[12.13.74.69] "," 1490 ","IP"," ESP SPI=198778318" 14","0.001.247 ","[203.163.90.253] ","[12.13.74.69] "," 1490 ","IP"," ESP SPI=198778318" 15","0.000.943 ","[203.163.90.253] ","[12.13.74.69] "," 1306 ","IP"," ESP SPI=198778318" 16","0.002.576 ","[12.13.74.69] ","[203.163.90.253] "," 98 ","IP"," ESP SPI=1261713583" 17","0.000.985 ","[12.13.74.69] ","[203.163.90.253] "," 98 ","IP"," ESP SPI=1261713583" 18","0.001.809 ","[12.13.74.69] ","[203.163.90.253] "," 98 ","IP"," ESP SPI=1261713583" 19","0.000.404 ","[12.13.74.69] ","[203.163.90.253] "," 98 ","IP"," ESP SPI=1261713583" 20","0.175.945 ","[203.163.90.253] ","[12.13.74.69] "," 1490 ","IP"," ESP SPI=198778318" 21","0.001.298 ","[203.163.90.253] ","[12.13.74.69] "," 1490 ","IP"," ESP SPI=198778318" The problem seems to be a long delay between the 4th 98 (See Frame #9 and # 10, #19 and #20 above) Byte ESP frame and the next set of 1490 byte frames. The delay can be from anywhere around 260 MS to as low as 60 MS, usually closer to the former. This delay kills the throughput of the connection. The implementation is from Newbridge Networks, with their "TimeStep PermitGate" product line. The vendor says this behavior is the nature of the IPSec standard, and their is nothing they can do about it, this also appears to be the opinion of Netscreen Inc, who believe their products would suffer the same issue. Another ipsec list subscriber suggested that I increase the TCP window size further than it is (64k). Unfortunately not all platforms support larger windows, but I will give this a try. Thanks, Rett Walters Derek Atkins cc: ipsec@lists.tislabs.com Subject: Re: IPSec Standard - No Flow Control? 07/23/2001 12:42 PM There are no ACKs to ESP packets. The encapsulated TCP should be handling the ACKs at (encrypted) layer-4. Could you explain what you mean by a "trace analysis showing a large percentage of time spent waiting for CKs to transmitted ESP packets"? Also, what platform(s) and IPsec implementation(s) are you using? -derek Rett_Walters@payless.com writes: > I have a question regarding IPsec inner workings..... > > Is there a provision for Flow Control in the IPSec Standards? > > I understand that IPSec essentially runs at Layer 3 which does not include > flow control algorithms (usually left to Layer 4 protocols such as TCP); > however I have noticed in live implementations of the protocol, long delay > networks (250ms round-trip) suffer serious performance issues when compared > to non-encrypted TCP communications such as Ftp's, using large (64k) TCP > Receive Windows. Trace analysis shows a large percentage of time spent > waiting for ACKs to transmitted ESP packets. Is there no way to control > the amount of data "in flight", ie setting a higher Window? Using IPSec > Encapsulation seems to override or Break the TCP Windows set in the > encrypted packet headers, do to its own method of flow control (or lack > thereof)..... > > I am wondering if this was overlooked? > > Thanks, > > ___________________________________ > Rett D. Walters > Network Architect > Payless ShoeSource Inc. > Phone: 785-295-2049, Fax: 785-295-6666 > Email: rett.walters@payless.com > > -- 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 Jul 23 13:32:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NKW8q04856; Mon, 23 Jul 2001 13:32:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29158 Mon, 23 Jul 2001 15:47:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20010723124650.0436d018@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Jul 2001 12:52:43 -0700 To: Radia Perlman - Boston Center for Networking From: Mark Baugher Subject: Re: What does SIT_IDENTITY_ONLY mean? Cc: ipsec@lists.tislabs.com In-Reply-To: <200107190246.WAA18482@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We left the Situation zero in GDOI since there are no IANA numbers for it that I could find. I interpreted Situation as a refinement of the DOI for labelled security or potentially other purposes by a peer that can understand Situation-specific encodings of the SA payload that follows it. I would appreciate seeing more specification regarding its use. Mark At 10:46 PM 7/18/2001 -0400, Radia Perlman - Boston Center for Networking wrote: >The "situation" for IKE's DOI as defined in RFC 2407 has 3 bits >defined. The bottom one, SIT_IDENTITY_ONLY seems to be defined >as indicating that there's an identity payload. > >Given that you can tell if there's an identity payload, why do you >need a bit to tell you that there is one? > >Anyway, I'm confused. What is that bit for? > >Thanks, > >Radia From owner-ipsec@lists.tislabs.com Mon Jul 23 13:55:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NKtcq05538; Mon, 23 Jul 2001 13:55:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29200 Mon, 23 Jul 2001 16:02:51 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C113B3.06E3CA30" Subject: RE: IPSec Standard - No Flow Control? X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Mon, 23 Jul 2001 13:06:57 -0700 Message-ID: Thread-Topic: IPSec Standard - No Flow Control? Thread-Index: AcETsio4Qh8pYzfuQJSY+yzom1WqigAAL6Xw From: "Chinmay Patel" To: "Michael Thomas" , Cc: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C113B3.06E3CA30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adjust anti-replay window to 96 or 128 and you should be good to go. I concur with Mike. -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Monday, July 23, 2001 10:56 AM To: Rett_Walters@payless.com Cc: ipsec@lists.tislabs.com Subject: IPSec Standard - No Flow Control? It may be what you're seeing is an artifact of the replay sequence number processing not allowing the full TCP receive window's worth of in flight data. Typically, the replay window is about 32-64 bits, which may be on the edge of interfering with your TCP window. Adjusting its window upward may help, but it's possible that there may be some limits to the size. Mike Rett_Walters@payless.com writes: > I have a question regarding IPsec inner workings..... >=20 > Is there a provision for Flow Control in the IPSec Standards? >=20 > I understand that IPSec essentially runs at Layer 3 which does not include > flow control algorithms (usually left to Layer 4 protocols such as TCP); > however I have noticed in live implementations of the protocol, long delay > networks (250ms round-trip) suffer serious performance issues when compared > to non-encrypted TCP communications such as Ftp's, using large (64k) TCP > Receive Windows. Trace analysis shows a large percentage of time spent > waiting for ACKs to transmitted ESP packets. Is there no way to control > the amount of data "in flight", ie setting a higher Window? Using IPSec > Encapsulation seems to override or Break the TCP Windows set in the > encrypted packet headers, do to its own method of flow control (or lack > thereof)..... >=20 > I am wondering if this was overlooked? >=20 > Thanks, >=20 > ___________________________________ > Rett D. Walters > Network Architect > Payless ShoeSource Inc. > Phone: 785-295-2049, Fax: 785-295-6666 > Email: rett.walters@payless.com >=20 >=20 ------_=_NextPart_001_01C113B3.06E3CA30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IPSec Standard - No Flow Control?

Adjust anti-replay window to 96 or 128 and you should = be good to go. I concur with Mike.

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Monday, July 23, 2001 10:56 AM
To: Rett_Walters@payless.com
Cc: ipsec@lists.tislabs.com
Subject: IPSec Standard - No Flow Control?



It may be what you're seeing is an artifact of = the
replay sequence number processing not allowing = the
full TCP receive window's worth of in flight = data.
Typically, the replay window is about 32-64 = bits,
which may be on the edge of interfering with = your
TCP window. Adjusting its window upward may = help,
but it's possible that there may be some limits = to
the size.

       Mike

Rett_Walters@payless.com writes:
 > I have a question regarding IPsec inner = workings.....
 >
 > Is there a provision for Flow Control in = the IPSec Standards?
 >
 > I understand that IPSec essentially runs = at Layer 3 which does not include
 > flow control algorithms (usually left to = Layer 4 protocols such as TCP);
 > however I have noticed in live = implementations of the protocol, long delay
 > networks (250ms round-trip) suffer serious = performance issues when compared
 > to non-encrypted TCP communications such = as Ftp's, using large (64k) TCP
 > Receive Windows.  Trace analysis = shows a large percentage of time spent
 > waiting for ACKs to transmitted ESP = packets.  Is there no way to control
 > the amount of data "in flight", = ie setting a higher Window?   Using IPSec
 > Encapsulation seems to override or Break = the TCP Windows set in the
 > encrypted packet headers, do to its own = method of flow control (or lack
 > thereof).....
 >
 > I am wondering if this was = overlooked?
 >
 > Thanks,
 >
 > ___________________________________
 > Rett D. Walters
 > Network Architect
 > Payless ShoeSource Inc.
 > Phone: 785-295-2049, Fax: = 785-295-6666
 > Email: rett.walters@payless.com
 >
 >

------_=_NextPart_001_01C113B3.06E3CA30-- From owner-ipsec@lists.tislabs.com Mon Jul 23 14:39:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NLdHq06843; Mon, 23 Jul 2001 14:39:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29365 Mon, 23 Jul 2001 16:45:56 -0400 (EDT) Message-Id: <200107232051.f6NKpwS01259@thunk.east.sun.com> From: Bill Sommerfeld To: "Chinmay Patel" cc: "Michael Thomas" , Rett_Walters@payless.com, ipsec@lists.tislabs.com Subject: Re: IPSec Standard - No Flow Control? In-reply-to: Your message of "Mon, 23 Jul 2001 13:06:57 PDT." Reply-to: sommerfeld@East.Sun.COM Date: Mon, 23 Jul 2001 16:51:58 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The trace does not show a large number of packets "in flight" (only 4 or 5); increasing the anti-replay window is thus unlikely to help. I'm suspicious that there might also be a bug in the host tcp (perhaps connected with sending segments smaller than the peer's MSS due to ipsec overhead); getting a packet trace after decryption or before encryption which included the tcp sequence numbers would help in pointing fingers. - Bill From owner-ipsec@lists.tislabs.com Mon Jul 23 14:39:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NLdJq06855; Mon, 23 Jul 2001 14:39:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29298 Mon, 23 Jul 2001 16:34:28 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15196.35783.227887.579356@thomasm-u1.cisco.com> Date: Mon, 23 Jul 2001 13:40:39 -0700 (PDT) To: Rett_Walters@payless.com Cc: Derek Atkins , ipsec@lists.tislabs.com Subject: Re: IPSec Standard - No Flow Control? In-Reply-To: References: 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 The suggestion was to make the IPsec replay window bigger -- not the TCP window. I've heard that some hardware doesn't allow bigger replay windows than 64 (??), which if this is the case, you probably ought to set the TCP window *lower* so that you're at least not dropping so many packets. Mike Rett_Walters@payless.com writes: > > Derek: > > Excuse my Terminology. It appears that for each Payload packet sent, there > is a small (Approx 98 Byte ESP) frame sent back, now, these could be the > encrypted Layer-4 acknowledgements. Here is a sample of the trace: > # DeltaT Dest Src Size > Summary > 1","0.000.000 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 2","0.001.198 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 3","0.001.191 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 4","0.001.243 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 5","0.003.525 ","[203.163.90.253] ","[12.13.74.69] "," 1306 > ","IP"," ESP SPI=198778318" > 6","0.000.136 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 7","0.001.377 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 8","0.001.510 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 9","0.000.418 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 10","0.071.579 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 11","0.001.145 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 12","0.001.227 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 13","0.001.209 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 14","0.001.247 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 15","0.000.943 ","[203.163.90.253] ","[12.13.74.69] "," 1306 > ","IP"," ESP SPI=198778318" > 16","0.002.576 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 17","0.000.985 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 18","0.001.809 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 19","0.000.404 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 20","0.175.945 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 21","0.001.298 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > > The problem seems to be a long delay between the 4th 98 (See Frame #9 and # > 10, #19 and #20 above) Byte ESP frame and the next set of 1490 byte frames. > The delay can be from anywhere around 260 MS to as low as 60 MS, usually > closer to the former. This delay kills the throughput of the connection. > > The implementation is from Newbridge Networks, with their "TimeStep > PermitGate" product line. The vendor says this behavior is the nature of > the IPSec standard, and their is nothing they can do about it, this also > appears to be the opinion of Netscreen Inc, who believe their products > would suffer the same issue. > > Another ipsec list subscriber suggested that I increase the TCP window size > further than it is (64k). Unfortunately not all platforms support larger > windows, but I will give this a try. > > Thanks, > > Rett Walters > > > > Derek Atkins > EDU> cc: ipsec@lists.tislabs.com > Subject: Re: IPSec Standard - No Flow Control? > 07/23/2001 > 12:42 PM > > > > > > > There are no ACKs to ESP packets. The encapsulated TCP should be > handling the ACKs at (encrypted) layer-4. Could you explain what you > mean by a "trace analysis showing a large percentage of time spent > waiting for CKs to transmitted ESP packets"? Also, what platform(s) > and IPsec implementation(s) are you using? > > -derek > > Rett_Walters@payless.com writes: > > > I have a question regarding IPsec inner workings..... > > > > Is there a provision for Flow Control in the IPSec Standards? > > > > I understand that IPSec essentially runs at Layer 3 which does not > include > > flow control algorithms (usually left to Layer 4 protocols such as TCP); > > however I have noticed in live implementations of the protocol, long > delay > > networks (250ms round-trip) suffer serious performance issues when > compared > > to non-encrypted TCP communications such as Ftp's, using large (64k) TCP > > Receive Windows. Trace analysis shows a large percentage of time spent > > waiting for ACKs to transmitted ESP packets. Is there no way to control > > the amount of data "in flight", ie setting a higher Window? Using IPSec > > Encapsulation seems to override or Break the TCP Windows set in the > > encrypted packet headers, do to its own method of flow control (or lack > > thereof)..... > > > > I am wondering if this was overlooked? > > > > Thanks, > > > > ___________________________________ > > Rett D. Walters > > Network Architect > > Payless ShoeSource Inc. > > Phone: 785-295-2049, Fax: 785-295-6666 > > Email: rett.walters@payless.com > > > > > > -- > 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 Jul 23 15:47:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6NMlFq08423; Mon, 23 Jul 2001 15:47:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29676 Mon, 23 Jul 2001 18:03:45 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Mark Baugher'" , "'Radia Perlman - Boston Center for Networking'" Cc: Subject: RE: What does SIT_IDENTITY_ONLY mean? Date: Mon, 23 Jul 2001 17:54:57 -0400 Message-Id: <002201c113c3$2abe4e70$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 In-Reply-To: <4.3.2.7.2.20010723124650.0436d018@mira-sjc5-6.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk During the Son of IKE discussion at the last bakeoff, several people commented that the situation is not particularly useful and it could be removed or simply ignored. 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 Mark Baugher > Sent: Monday, July 23, 2001 3:53 PM > To: Radia Perlman - Boston Center for Networking > Cc: ipsec@lists.tislabs.com > Subject: Re: What does SIT_IDENTITY_ONLY mean? > > > We left the Situation zero in GDOI since there are no IANA > numbers for it > that I could find. I interpreted Situation as a refinement > of the DOI for > labelled > security or potentially other purposes by a peer that can understand > Situation-specific > encodings of the SA payload that follows it. I would > appreciate seeing more > specification regarding its use. > > Mark > At 10:46 PM 7/18/2001 -0400, Radia Perlman - Boston Center > for Networking > wrote: > >The "situation" for IKE's DOI as defined in RFC 2407 has 3 bits > >defined. The bottom one, SIT_IDENTITY_ONLY seems to be defined > >as indicating that there's an identity payload. > > > >Given that you can tell if there's an identity payload, why do you > >need a bit to tell you that there is one? > > > >Anyway, I'm confused. What is that bit for? > > > >Thanks, > > > >Radia > > From owner-ipsec@lists.tislabs.com Mon Jul 23 20:51:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6O3pGG14333; Mon, 23 Jul 2001 20:51:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA00172 Mon, 23 Jul 2001 22:50:09 -0400 (EDT) From: Rett_Walters@payless.com Subject: Re: IPSec Standard - No Flow Control? To: Michael Thomas Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 23 Jul 2001 21:57:40 -0500 X-MIMETrack: Serialize by Router on PSAMAILC/PSS(Release 5.0.7 |March 21, 2001) at 07/23/2001 09:57:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am sorry... I misunderstood, however, I am a bit confused, because we are not dropping packets in this situation, therefore I guess we should be looking elsewhere. This issue is simply slow transfer, similiar to using a small TCP window on a long delay network without any encryption. You don't necessarily drop packets, just spend alot of time waiting on acknowledgements. Rett Walters |--------+-----------------------------> | | Michael Thomas | | | | | | Sent by: | | | owner-ipsec@lists.t| | | islabs.com | | | | | | | | | 07/23/2001 03:40 PM| | | | |--------+-----------------------------> >------------------------------------------------------------------------------------------------------------------------| | | | To: Rett_Walters@payless.com | | cc: Derek Atkins , ipsec@lists.tislabs.com | | Subject: Re: IPSec Standard - No Flow Control? | >------------------------------------------------------------------------------------------------------------------------| The suggestion was to make the IPsec replay window bigger -- not the TCP window. I've heard that some hardware doesn't allow bigger replay windows than 64 (??), which if this is the case, you probably ought to set the TCP window *lower* so that you're at least not dropping so many packets. Mike Rett_Walters@payless.com writes: > > Derek: > > Excuse my Terminology. It appears that for each Payload packet sent, there > is a small (Approx 98 Byte ESP) frame sent back, now, these could be the > encrypted Layer-4 acknowledgements. Here is a sample of the trace: > # DeltaT Dest Src Size > Summary > 1","0.000.000 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 2","0.001.198 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 3","0.001.191 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 4","0.001.243 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 5","0.003.525 ","[203.163.90.253] ","[12.13.74.69] "," 1306 > ","IP"," ESP SPI=198778318" > 6","0.000.136 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 7","0.001.377 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 8","0.001.510 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 9","0.000.418 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 10","0.071.579 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 11","0.001.145 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 12","0.001.227 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 13","0.001.209 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 14","0.001.247 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 15","0.000.943 ","[203.163.90.253] ","[12.13.74.69] "," 1306 > ","IP"," ESP SPI=198778318" > 16","0.002.576 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 17","0.000.985 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 18","0.001.809 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 19","0.000.404 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 20","0.175.945 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 21","0.001.298 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > > The problem seems to be a long delay between the 4th 98 (See Frame #9 and # > 10, #19 and #20 above) Byte ESP frame and the next set of 1490 byte frames. > The delay can be from anywhere around 260 MS to as low as 60 MS, usually > closer to the former. This delay kills the throughput of the connection. > > The implementation is from Newbridge Networks, with their "TimeStep > PermitGate" product line. The vendor says this behavior is the nature of > the IPSec standard, and their is nothing they can do about it, this also > appears to be the opinion of Netscreen Inc, who believe their products > would suffer the same issue. > > Another ipsec list subscriber suggested that I increase the TCP window size > further than it is (64k). Unfortunately not all platforms support larger > windows, but I will give this a try. > > Thanks, > > Rett Walters > > > > Derek Atkins > EDU> cc: ipsec@lists.tislabs.com > Subject: Re: IPSec Standard - No Flow Control? > 07/23/2001 > 12:42 PM > > > > > > > There are no ACKs to ESP packets. The encapsulated TCP should be > handling the ACKs at (encrypted) layer-4. Could you explain what you > mean by a "trace analysis showing a large percentage of time spent > waiting for CKs to transmitted ESP packets"? Also, what platform(s) > and IPsec implementation(s) are you using? > > -derek > > Rett_Walters@payless.com writes: > > > I have a question regarding IPsec inner workings..... > > > > Is there a provision for Flow Control in the IPSec Standards? > > > > I understand that IPSec essentially runs at Layer 3 which does not > include > > flow control algorithms (usually left to Layer 4 protocols such as TCP); > > however I have noticed in live implementations of the protocol, long > delay > > networks (250ms round-trip) suffer serious performance issues when > compared > > to non-encrypted TCP communications such as Ftp's, using large (64k) TCP > > Receive Windows. Trace analysis shows a large percentage of time spent > > waiting for ACKs to transmitted ESP packets. Is there no way to control > > the amount of data "in flight", ie setting a higher Window? Using IPSec > > Encapsulation seems to override or Break the TCP Windows set in the > > encrypted packet headers, do to its own method of flow control (or lack > > thereof)..... > > > > I am wondering if this was overlooked? > > > > Thanks, > > > > ___________________________________ > > Rett D. Walters > > Network Architect > > Payless ShoeSource Inc. > > Phone: 785-295-2049, Fax: 785-295-6666 > > Email: rett.walters@payless.com > > > > > > -- > 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 Tue Jul 24 04:44:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OBiLG18400; Tue, 24 Jul 2001 04:44:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA00937 Tue, 24 Jul 2001 06:37:25 -0400 (EDT) From: "Paul Onions" To: "'Joern Sierwald'" Cc: Subject: RE: DEFLATE, ZLIB and RFC1951 Date: Tue, 24 Jul 2001 11:30:47 +0100 Message-ID: <000401c1142b$b416b1e0$a400a8c0@siliconinfusion.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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3.0.5.32.20010724090805.0500b510@smtp.datafellows.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Joern Sierwald > > ZLIB _does_ produce these. And when single stepping through the > inflate_blocks() routine, it certainly interprets them > correcty. > > NEEDBITS(3) > t = (uInt)b & 7; > s->last = t & 1; > switch (t >> 1) > { > case 0: /* stored */ > [cut] > case 1: /* fixed */ > [cut] > case 2: /* dynamic */ > [cut] > case 3: /* illegal */ > [cut] > } > > s->last is your BFINAL and t >> 1 is BTYPE. > > Jörn > Ah, thank you! I was looking at the most-significant bits of the first byte instead of the least-significant. Silly me :-( Regards, Paul(o) From owner-ipsec@lists.tislabs.com Tue Jul 24 04:44:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OBihG18417; Tue, 24 Jul 2001 04:44:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA01006 Tue, 24 Jul 2001 07:08:37 -0400 (EDT) Message-Id: <3.0.5.32.20010724090805.0500b510@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 24 Jul 2001 09:08:05 +0200 To: "Paul Onions" From: Joern Sierwald Subject: Re: DEFLATE, ZLIB and RFC1951 Cc: In-Reply-To: <000001c1139a$ce083420$a400a8c0@siliconinfusion.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA00570 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 18:13 23.07.01 +0100, Paul Onions wrote: >In the description of DEFLATE in RFC1951 it states that the compressed data >is in the form of a sequence of blocks, where each block has a 3-bit header >consisting of a BFINAL bit and a BTYPE bit-pair. The BFINAL bit identifies >the last block of the sequence and the BTYPE pair indicates whether the >block is either non-compressed, compressed with fixed huffman codes, or >compressed with dynamic huffman codes. > >My question is how these bits should be handled when using ZLIB? > >I can't find any explicit mention of these bits in the ZLIB documentation >and, after playing around with ZLIB (using the python module), it seems that >it does not produce/understand these bits. > >Is this correct (and they have to be handled external to ZLIB), or am I >misunderstanding something here? > >Any help would be appreciated, >Paul(o) > ZLIB _does_ produce these. And when single stepping through the inflate_blocks() routine, it certainly interprets them correcty. NEEDBITS(3) t = (uInt)b & 7; s->last = t & 1; switch (t >> 1) { case 0: /* stored */ [cut] case 1: /* fixed */ [cut] case 2: /* dynamic */ [cut] case 3: /* illegal */ [cut] } s->last is your BFINAL and t >> 1 is BTYPE. J–rn From owner-ipsec@lists.tislabs.com Tue Jul 24 05:45:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OCjqG19372; Tue, 24 Jul 2001 05:45:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA01030 Tue, 24 Jul 2001 07:09:35 -0400 (EDT) Message-Id: <3.0.5.32.20010724092021.032ad520@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 24 Jul 2001 09:20:21 +0200 To: Rett_Walters@payless.com From: Joern Sierwald Subject: Re: IPSec Standard - No Flow Control? Cc: ipsec@lists.tislabs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA00622 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:12 23.07.01 -0500, Rett_Walters@payless.com wrote: > >Derek: > >Excuse my Terminology. It appears that for each Payload packet sent, there >is a small (Approx 98 Byte ESP) frame sent back, now, these could be the >encrypted Layer-4 acknowledgements. Here is a sample of the trace: ># DeltaT Dest Src Size >Summary >1","0.000.000 ","[203.163.90.253] ","[12.13.74.69] "," 1490 >","IP"," ESP SPI=198778318" >2","0.001.198 ","[203.163.90.253] ","[12.13.74.69] "," 1490 >","IP"," ESP SPI=198778318" Well, the 1st hint is the packet size of 1490. Since this is the size after encryption, your IPsec has somehow managed to reduce the TCP MSS. Maybe the normal TCP MTU discovery dicovered the IPsec tunnel, maybe the IPsec fiddled with the MSS option. But this reduction is most likely the cause for the delay. If one of the TCP implementations has problems with an odd MSS, this might just explain the effect. Anyway, to go ahead you should try to get a trace of both encrypted and unecrypted traffic together in one trace. The traffic _and_the_delay_ is caused by the TCP stack, not by the IPsec box. (That's me theory, anyway) Happy TCP analysing to you! J–rn From owner-ipsec@lists.tislabs.com Tue Jul 24 09:20:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OGKlG29977; Tue, 24 Jul 2001 09:20:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01660 Tue, 24 Jul 2001 11:25:38 -0400 (EDT) From: Rett_Walters@payless.com Message-Id: <200107241534.KAA07331@gateway.paylessshoesource.com> Subject: RE: IPSec Standard - No Flow Control? To: "Joergensen, Michael" Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Date: Tue, 24 Jul 2001 09:17:38 -0500 X-MIMETrack: Serialize by Router on PSAMAILC/PSS(Release 5.0.7 |March 21, 2001) at 07/24/2001 09:28:31 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The problem does not occur when IPSec isn't in the picture, hence, doing un-encrypted transmissions over the same network works fine. Alot of subscribers mentioned that is seems that the TCP MSS is set to an interesting size, this is due to the MTU of the Host device being set below 1500 bytes to keep the IPSec Overhead from causing alot of fragmented packets. This was at the suggestion of the vendor, and so far has not had an effect on the problem. Thanks, Rett Walters "Joergensen, Michael" To: "'Rett_Walters@payless.com'" Subject: RE: IPSec Standard - No Flow Control? 07/24/2001 06:04 AM Hi Rett, I've seen similar problems with our products, but there the problem was in the TCP stack, and hence unrelated to the IPSec protocol. Do you observe the same behaviour when IPSec is disabled? As someone else suggested, it will be helpful to see the TCP headers of the unencrypted data, i.e. a capture between the host and the IPSec gateway. This will show where the delay is introduced. My guess is the problem is in the host, not the gateway. Regards, Michael Jorgensen Embedded software engineer Intel Denmark -----Original Message----- From: Rett_Walters@payless.com [mailto:Rett_Walters@payless.com] Sent: 24. juli 2001 04:58 To: Michael Thomas Cc: ipsec@lists.tislabs.com Subject: Re: IPSec Standard - No Flow Control? I am sorry... I misunderstood, however, I am a bit confused, because we are not dropping packets in this situation, therefore I guess we should be looking elsewhere. This issue is simply slow transfer, similiar to using a small TCP window on a long delay network without any encryption. You don't necessarily drop packets, just spend alot of time waiting on acknowledgements. Rett Walters |--------+-----------------------------> | | Michael Thomas | | | | | | Sent by: | | | owner-ipsec@lists.t| | | islabs.com | | | | | | | | | 07/23/2001 03:40 PM| | | | |--------+-----------------------------> > --------------------------------------------------------------------------- ---------------------------------------------| | | | To: Rett_Walters@payless.com | | cc: Derek Atkins , ipsec@lists.tislabs.com | | Subject: Re: IPSec Standard - No Flow Control? | > --------------------------------------------------------------------------- ---------------------------------------------| The suggestion was to make the IPsec replay window bigger -- not the TCP window. I've heard that some hardware doesn't allow bigger replay windows than 64 (??), which if this is the case, you probably ought to set the TCP window *lower* so that you're at least not dropping so many packets. Mike Rett_Walters@payless.com writes: > > Derek: > > Excuse my Terminology. It appears that for each Payload packet sent, there > is a small (Approx 98 Byte ESP) frame sent back, now, these could be the > encrypted Layer-4 acknowledgements. Here is a sample of the trace: > # DeltaT Dest Src Size > Summary > 1","0.000.000 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 2","0.001.198 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 3","0.001.191 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 4","0.001.243 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 5","0.003.525 ","[203.163.90.253] ","[12.13.74.69] "," 1306 > ","IP"," ESP SPI=198778318" > 6","0.000.136 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 7","0.001.377 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 8","0.001.510 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 9","0.000.418 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 10","0.071.579 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 11","0.001.145 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 12","0.001.227 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 13","0.001.209 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 14","0.001.247 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 15","0.000.943 ","[203.163.90.253] ","[12.13.74.69] "," 1306 > ","IP"," ESP SPI=198778318" > 16","0.002.576 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 17","0.000.985 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 18","0.001.809 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 19","0.000.404 ","[12.13.74.69] ","[203.163.90.253] "," 98 > ","IP"," ESP SPI=1261713583" > 20","0.175.945 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > 21","0.001.298 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > ","IP"," ESP SPI=198778318" > > The problem seems to be a long delay between the 4th 98 (See Frame #9 and # > 10, #19 and #20 above) Byte ESP frame and the next set of 1490 byte frames. > The delay can be from anywhere around 260 MS to as low as 60 MS, usually > closer to the former. This delay kills the throughput of the connection. > > The implementation is from Newbridge Networks, with their "TimeStep > PermitGate" product line. The vendor says this behavior is the nature of > the IPSec standard, and their is nothing they can do about it, this also > appears to be the opinion of Netscreen Inc, who believe their products > would suffer the same issue. > > Another ipsec list subscriber suggested that I increase the TCP window size > further than it is (64k). Unfortunately not all platforms support larger > windows, but I will give this a try. > > Thanks, > > Rett Walters > > > > Derek Atkins > EDU> cc: ipsec@lists.tislabs.com > Subject: Re: IPSec Standard - No Flow Control? > 07/23/2001 > 12:42 PM > > > > > > > There are no ACKs to ESP packets. The encapsulated TCP should be > handling the ACKs at (encrypted) layer-4. Could you explain what you > mean by a "trace analysis showing a large percentage of time spent > waiting for CKs to transmitted ESP packets"? Also, what platform(s) > and IPsec implementation(s) are you using? > > -derek > > Rett_Walters@payless.com writes: > > > I have a question regarding IPsec inner workings..... > > > > Is there a provision for Flow Control in the IPSec Standards? > > > > I understand that IPSec essentially runs at Layer 3 which does not > include > > flow control algorithms (usually left to Layer 4 protocols such as TCP); > > however I have noticed in live implementations of the protocol, long > delay > > networks (250ms round-trip) suffer serious performance issues when > compared > > to non-encrypted TCP communications such as Ftp's, using large (64k) TCP > > Receive Windows. Trace analysis shows a large percentage of time spent > > waiting for ACKs to transmitted ESP packets. Is there no way to control > > the amount of data "in flight", ie setting a higher Window? Using IPSec > > Encapsulation seems to override or Break the TCP Windows set in the > > encrypted packet headers, do to its own method of flow control (or lack > > thereof)..... > > > > I am wondering if this was overlooked? > > > > Thanks, > > > > ___________________________________ > > Rett D. Walters > > Network Architect > > Payless ShoeSource Inc. > > Phone: 785-295-2049, Fax: 785-295-6666 > > Email: rett.walters@payless.com > > > > > > -- > 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 Tue Jul 24 09:27:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OGRZG00213; Tue, 24 Jul 2001 09:27:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01716 Tue, 24 Jul 2001 11:50:56 -0400 (EDT) Date: Tue, 24 Jul 2001 09:04:24 -0400 From: Ramin Ali Dousti To: Joern Sierwald Cc: Rett_Walters@payless.com, ipsec@lists.tislabs.com Subject: Re: IPSec Standard - No Flow Control? Message-ID: <20010724090424.E27707@uu.net> References: <3.0.5.32.20010724092021.032ad520@smtp.datafellows.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <3.0.5.32.20010724092021.032ad520@smtp.datafellows.com>; from joern.sierwald@F-Secure.com on Tue, Jul 24, 2001 at 09:20:21AM +0200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Jul 24, 2001 at 09:20:21AM +0200, Joern Sierwald wrote: > At 14:12 23.07.01 -0500, Rett_Walters@payless.com wrote: > > > >Derek: > > > >Excuse my Terminology. It appears that for each Payload packet sent, there > >is a small (Approx 98 Byte ESP) frame sent back, now, these could be the > >encrypted Layer-4 acknowledgements. Here is a sample of the trace: > ># DeltaT Dest Src Size > >Summary > >1","0.000.000 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > >","IP"," ESP SPI=198778318" > >2","0.001.198 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > >","IP"," ESP SPI=198778318" > > Well, the 1st hint is the packet size of 1490. Since this is the > size after encryption, your IPsec has somehow managed to reduce the TCP MSS. > Maybe the normal TCP MTU discovery dicovered the IPsec tunnel, maybe > the IPsec fiddled with the MSS option. Is it not just the opposite? That the segment size has increased? On an Ethernet with 1500 MTU you should have 1460 MSS. This way the last segment might get dropped at the receiving end, while the sender is waiting for the ACK. Ramin > > But this reduction is most likely the cause for the delay. If one of > the TCP implementations has problems with an odd MSS, this might just > explain the effect. > > Anyway, to go ahead you should try to get a trace of both encrypted and > unecrypted traffic together in one trace. The traffic _and_the_delay_ > is caused by the TCP stack, not by the IPsec box. (That's me theory, anyway) > Happy TCP analysing to you! > > Jñrn From owner-ipsec@lists.tislabs.com Tue Jul 24 09:32:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OGWrG00367; Tue, 24 Jul 2001 09:32:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01737 Tue, 24 Jul 2001 11:51:56 -0400 (EDT) Date: Tue, 24 Jul 2001 10:00:45 -0400 From: Ramin Ali Dousti To: Ramin Ali Dousti Cc: Joern Sierwald , Rett_Walters@payless.com, ipsec@lists.tislabs.com Subject: Re: IPSec Standard - No Flow Control? Message-ID: <20010724100045.A27677@uu.net> References: <20010724090424.E27707@uu.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010724090424.E27707@uu.net>; from Ramin.Dousti@wcom.com on Tue, Jul 24, 2001 at 09:04:24AM -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please disregard my previous message. I just proved that sometimes $0.02 is even not worth a penny. Ramin On Tue, Jul 24, 2001 at 09:04:24AM -0400, Ramin Ali Dousti wrote: > Is it not just the opposite? That the segment size has increased? On > an Ethernet with 1500 MTU you should have 1460 MSS. This way the last > segment might get dropped at the receiving end, while the sender is > waiting for the ACK. > > Ramin > From owner-ipsec@lists.tislabs.com Tue Jul 24 09:36:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OGagG00450; Tue, 24 Jul 2001 09:36:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01796 Tue, 24 Jul 2001 12:03:04 -0400 (EDT) To: Rett_Walters@payless.com Cc: "Joergensen, Michael" , ipsec@lists.tislabs.com Subject: Re: IPSec Standard - No Flow Control? References: <200107241534.KAA07331@gateway.paylessshoesource.com> From: Derek Atkins Date: 24 Jul 2001 12:09:43 -0400 In-Reply-To: Rett_Walters@payless.com's message of "Tue, 24 Jul 2001 09:17:38 -0500" Message-ID: Lines: 287 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, 1490 might not be "low enough" for ESP overhead, so you may still be getting fragmentation. You might want to try reducing your MSS to 1480, or maybe even 1400 and trying again. -derek Rett_Walters@payless.com writes: > The problem does not occur when IPSec isn't in the picture, hence, doing > un-encrypted transmissions over the same network works fine. > > Alot of subscribers mentioned that is seems that the TCP MSS is set to an > interesting size, this is due to the MTU of the Host device being set below > 1500 bytes to keep the IPSec Overhead from causing alot of fragmented > packets. This was at the suggestion of the vendor, and so far has not had > an effect on the problem. > > Thanks, > > Rett Walters > > > > > "Joergensen, > Michael" To: "'Rett_Walters@payless.com'" > intel.com> Subject: RE: IPSec Standard - No Flow Control? > > 07/24/2001 06:04 AM > > > > > > > Hi Rett, > > I've seen similar problems with our products, but there the problem was in > the TCP stack, and hence unrelated to the IPSec protocol. Do you observe > the > same behaviour when IPSec is disabled? > > As someone else suggested, it will be helpful to see the TCP headers of the > unencrypted data, i.e. a capture between the host and the IPSec gateway. > This will show where the delay is introduced. My guess is the problem is in > the host, not the gateway. > > Regards, > Michael Jorgensen > Embedded software engineer > Intel Denmark > > > > -----Original Message----- > From: Rett_Walters@payless.com [mailto:Rett_Walters@payless.com] > Sent: 24. juli 2001 04:58 > To: Michael Thomas > Cc: ipsec@lists.tislabs.com > Subject: Re: IPSec Standard - No Flow Control? > > > > I am sorry... I misunderstood, however, I am a bit confused, because we > are not dropping packets in this situation, therefore I guess we should be > looking elsewhere. This issue is simply slow transfer, similiar to using a > small TCP window on a long delay network without any encryption. You don't > necessarily drop packets, just spend alot of time waiting on > acknowledgements. > > Rett Walters > > > > |--------+-----------------------------> > | | Michael Thomas | > | | | > | | Sent by: | > | | owner-ipsec@lists.t| > | | islabs.com | > | | | > | | | > | | 07/23/2001 03:40 PM| > | | | > |--------+-----------------------------> > > > > --------------------------------------------------------------------------- > ---------------------------------------------| > | > | > | To: Rett_Walters@payless.com > | > | cc: Derek Atkins , ipsec@lists.tislabs.com > | > | Subject: Re: IPSec Standard - No Flow Control? > | > > > > --------------------------------------------------------------------------- > ---------------------------------------------| > > > > > > The suggestion was to make the IPsec replay window bigger -- not > the TCP window. I've heard that some hardware doesn't allow bigger > replay windows than 64 (??), which if this is the case, you probably > ought to set the TCP window *lower* so that you're at least not > dropping so many packets. > > Mike > > Rett_Walters@payless.com writes: > > > > Derek: > > > > Excuse my Terminology. It appears that for each Payload packet sent, > there > > is a small (Approx 98 Byte ESP) frame sent back, now, these could be the > > encrypted Layer-4 acknowledgements. Here is a sample of the trace: > > # DeltaT Dest Src Size > > Summary > > 1","0.000.000 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > ","IP"," ESP SPI=198778318" > > 2","0.001.198 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > ","IP"," ESP SPI=198778318" > > 3","0.001.191 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > ","IP"," ESP SPI=198778318" > > 4","0.001.243 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > ","IP"," ESP SPI=198778318" > > 5","0.003.525 ","[203.163.90.253] ","[12.13.74.69] "," 1306 > > ","IP"," ESP SPI=198778318" > > 6","0.000.136 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > ","IP"," ESP SPI=1261713583" > > 7","0.001.377 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > ","IP"," ESP SPI=1261713583" > > 8","0.001.510 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > ","IP"," ESP SPI=1261713583" > > 9","0.000.418 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > ","IP"," ESP SPI=1261713583" > > 10","0.071.579 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > ","IP"," ESP SPI=198778318" > > 11","0.001.145 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > ","IP"," ESP SPI=198778318" > > 12","0.001.227 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > ","IP"," ESP SPI=198778318" > > 13","0.001.209 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > ","IP"," ESP SPI=198778318" > > 14","0.001.247 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > ","IP"," ESP SPI=198778318" > > 15","0.000.943 ","[203.163.90.253] ","[12.13.74.69] "," 1306 > > ","IP"," ESP SPI=198778318" > > 16","0.002.576 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > ","IP"," ESP SPI=1261713583" > > 17","0.000.985 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > ","IP"," ESP SPI=1261713583" > > 18","0.001.809 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > ","IP"," ESP SPI=1261713583" > > 19","0.000.404 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > ","IP"," ESP SPI=1261713583" > > 20","0.175.945 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > ","IP"," ESP SPI=198778318" > > 21","0.001.298 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > ","IP"," ESP SPI=198778318" > > > > The problem seems to be a long delay between the 4th 98 (See Frame #9 > and # > > 10, #19 and #20 above) Byte ESP frame and the next set of 1490 byte > frames. > > The delay can be from anywhere around 260 MS to as low as 60 MS, usually > > closer to the former. This delay kills the throughput of the > connection. > > > > The implementation is from Newbridge Networks, with their "TimeStep > > PermitGate" product line. The vendor says this behavior is the nature > of > > the IPSec standard, and their is nothing they can do about it, this also > > appears to be the opinion of Netscreen Inc, who believe their products > > would suffer the same issue. > > > > Another ipsec list subscriber suggested that I increase the TCP window > size > > further than it is (64k). Unfortunately not all platforms support > larger > > windows, but I will give this a try. > > > > Thanks, > > > > Rett Walters > > > > > > > > > Derek Atkins > > > Rett_Walters@payless.com > > EDU> cc: ipsec@lists.tislabs.com > > > Subject: Re: IPSec Standard > - No Flow Control? > > 07/23/2001 > > > 12:42 PM > > > > > > > > > > > > > > > > > There are no ACKs to ESP packets. The encapsulated TCP should be > > handling the ACKs at (encrypted) layer-4. Could you explain what you > > mean by a "trace analysis showing a large percentage of time spent > > waiting for CKs to transmitted ESP packets"? Also, what platform(s) > > and IPsec implementation(s) are you using? > > > > -derek > > > > Rett_Walters@payless.com writes: > > > > > I have a question regarding IPsec inner workings..... > > > > > > Is there a provision for Flow Control in the IPSec Standards? > > > > > > I understand that IPSec essentially runs at Layer 3 which does not > > include > > > flow control algorithms (usually left to Layer 4 protocols such as > TCP); > > > however I have noticed in live implementations of the protocol, long > > delay > > > networks (250ms round-trip) suffer serious performance issues when > > compared > > > to non-encrypted TCP communications such as Ftp's, using large (64k) > TCP > > > Receive Windows. Trace analysis shows a large percentage of time > spent > > > waiting for ACKs to transmitted ESP packets. Is there no way to > control > > > the amount of data "in flight", ie setting a higher Window? Using > IPSec > > > Encapsulation seems to override or Break the TCP Windows set in the > > > encrypted packet headers, do to its own method of flow control (or > lack > > > thereof)..... > > > > > > I am wondering if this was overlooked? > > > > > > Thanks, > > > > > > ___________________________________ > > > Rett D. Walters > > > Network Architect > > > Payless ShoeSource Inc. > > > Phone: 785-295-2049, Fax: 785-295-6666 > > > Email: rett.walters@payless.com > > > > > > > > > > -- > > 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 Tue Jul 24 10:33:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OHXZG01963; Tue, 24 Jul 2001 10:33:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01933 Tue, 24 Jul 2001 12:49:08 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15197.43098.709331.42030@thomasm-u1.cisco.com> Date: Tue, 24 Jul 2001 09:54:50 -0700 (PDT) To: Derek Atkins Cc: Rett_Walters@payless.com, "Joergensen, Michael" , ipsec@lists.tislabs.com Subject: Re: IPSec Standard - No Flow Control? In-Reply-To: References: <200107241534.KAA07331@gateway.paylessshoesource.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 Derek Atkins writes: > Actually, 1490 might not be "low enough" for ESP overhead, so you may > still be getting fragmentation. You might want to try reducing your MSS > to 1480, or maybe even 1400 and trying again. Actually, I'd go for 1400 to be certain. For ethernet, 1536-14(eth)-20(ip)-20(tcp)-24(~ esp) = ~1458. If you have AH turned on or tunnels as well, it will be lower than 1458, so 1400 is probably a safe lower bound. Mike > > -derek > > Rett_Walters@payless.com writes: > > > The problem does not occur when IPSec isn't in the picture, hence, doing > > un-encrypted transmissions over the same network works fine. > > > > Alot of subscribers mentioned that is seems that the TCP MSS is set to an > > interesting size, this is due to the MTU of the Host device being set below > > 1500 bytes to keep the IPSec Overhead from causing alot of fragmented > > packets. This was at the suggestion of the vendor, and so far has not had > > an effect on the problem. > > > > Thanks, > > > > Rett Walters > > > > > > > > > > "Joergensen, > > Michael" To: "'Rett_Walters@payless.com'" > > > intel.com> Subject: RE: IPSec Standard - No Flow Control? > > > > 07/24/2001 06:04 AM > > > > > > > > > > > > > > Hi Rett, > > > > I've seen similar problems with our products, but there the problem was in > > the TCP stack, and hence unrelated to the IPSec protocol. Do you observe > > the > > same behaviour when IPSec is disabled? > > > > As someone else suggested, it will be helpful to see the TCP headers of the > > unencrypted data, i.e. a capture between the host and the IPSec gateway. > > This will show where the delay is introduced. My guess is the problem is in > > the host, not the gateway. > > > > Regards, > > Michael Jorgensen > > Embedded software engineer > > Intel Denmark > > > > > > > > -----Original Message----- > > From: Rett_Walters@payless.com [mailto:Rett_Walters@payless.com] > > Sent: 24. juli 2001 04:58 > > To: Michael Thomas > > Cc: ipsec@lists.tislabs.com > > Subject: Re: IPSec Standard - No Flow Control? > > > > > > > > I am sorry... I misunderstood, however, I am a bit confused, because we > > are not dropping packets in this situation, therefore I guess we should be > > looking elsewhere. This issue is simply slow transfer, similiar to using a > > small TCP window on a long delay network without any encryption. You don't > > necessarily drop packets, just spend alot of time waiting on > > acknowledgements. > > > > Rett Walters > > > > > > > > |--------+-----------------------------> > > | | Michael Thomas | > > | | | > > | | Sent by: | > > | | owner-ipsec@lists.t| > > | | islabs.com | > > | | | > > | | | > > | | 07/23/2001 03:40 PM| > > | | | > > |--------+-----------------------------> > > > > > > > --------------------------------------------------------------------------- > > ---------------------------------------------| > > | > > | > > | To: Rett_Walters@payless.com > > | > > | cc: Derek Atkins , ipsec@lists.tislabs.com > > | > > | Subject: Re: IPSec Standard - No Flow Control? > > | > > > > > > > --------------------------------------------------------------------------- > > ---------------------------------------------| > > > > > > > > > > > > The suggestion was to make the IPsec replay window bigger -- not > > the TCP window. I've heard that some hardware doesn't allow bigger > > replay windows than 64 (??), which if this is the case, you probably > > ought to set the TCP window *lower* so that you're at least not > > dropping so many packets. > > > > Mike > > > > Rett_Walters@payless.com writes: > > > > > > Derek: > > > > > > Excuse my Terminology. It appears that for each Payload packet sent, > > there > > > is a small (Approx 98 Byte ESP) frame sent back, now, these could be the > > > encrypted Layer-4 acknowledgements. Here is a sample of the trace: > > > # DeltaT Dest Src Size > > > Summary > > > 1","0.000.000 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > > ","IP"," ESP SPI=198778318" > > > 2","0.001.198 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > > ","IP"," ESP SPI=198778318" > > > 3","0.001.191 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > > ","IP"," ESP SPI=198778318" > > > 4","0.001.243 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > > ","IP"," ESP SPI=198778318" > > > 5","0.003.525 ","[203.163.90.253] ","[12.13.74.69] "," 1306 > > > ","IP"," ESP SPI=198778318" > > > 6","0.000.136 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > > ","IP"," ESP SPI=1261713583" > > > 7","0.001.377 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > > ","IP"," ESP SPI=1261713583" > > > 8","0.001.510 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > > ","IP"," ESP SPI=1261713583" > > > 9","0.000.418 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > > ","IP"," ESP SPI=1261713583" > > > 10","0.071.579 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > > ","IP"," ESP SPI=198778318" > > > 11","0.001.145 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > > ","IP"," ESP SPI=198778318" > > > 12","0.001.227 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > > ","IP"," ESP SPI=198778318" > > > 13","0.001.209 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > > ","IP"," ESP SPI=198778318" > > > 14","0.001.247 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > > ","IP"," ESP SPI=198778318" > > > 15","0.000.943 ","[203.163.90.253] ","[12.13.74.69] "," 1306 > > > ","IP"," ESP SPI=198778318" > > > 16","0.002.576 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > > ","IP"," ESP SPI=1261713583" > > > 17","0.000.985 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > > ","IP"," ESP SPI=1261713583" > > > 18","0.001.809 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > > ","IP"," ESP SPI=1261713583" > > > 19","0.000.404 ","[12.13.74.69] ","[203.163.90.253] "," 98 > > > ","IP"," ESP SPI=1261713583" > > > 20","0.175.945 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > > ","IP"," ESP SPI=198778318" > > > 21","0.001.298 ","[203.163.90.253] ","[12.13.74.69] "," 1490 > > > ","IP"," ESP SPI=198778318" > > > > > > The problem seems to be a long delay between the 4th 98 (See Frame #9 > > and # > > > 10, #19 and #20 above) Byte ESP frame and the next set of 1490 byte > > frames. > > > The delay can be from anywhere around 260 MS to as low as 60 MS, usually > > > closer to the former. This delay kills the throughput of the > > connection. > > > > > > The implementation is from Newbridge Networks, with their "TimeStep > > > PermitGate" product line. The vendor says this behavior is the nature > > of > > > the IPSec standard, and their is nothing they can do about it, this also > > > appears to be the opinion of Netscreen Inc, who believe their products > > > would suffer the same issue. > > > > > > Another ipsec list subscriber suggested that I increase the TCP window > > size > > > further than it is (64k). Unfortunately not all platforms support > > larger > > > windows, but I will give this a try. > > > > > > Thanks, > > > > > > Rett Walters > > > > > > > > > > > > > > Derek Atkins > > > > > > Rett_Walters@payless.com > > > EDU> cc: ipsec@lists.tislabs.com > > > > > Subject: Re: IPSec Standard > > - No Flow Control? > > > 07/23/2001 > > > > > 12:42 PM > > > > > > > > > > > > > > > > > > > > > > > > > > > There are no ACKs to ESP packets. The encapsulated TCP should be > > > handling the ACKs at (encrypted) layer-4. Could you explain what you > > > mean by a "trace analysis showing a large percentage of time spent > > > waiting for CKs to transmitted ESP packets"? Also, what platform(s) > > > and IPsec implementation(s) are you using? > > > > > > -derek > > > > > > Rett_Walters@payless.com writes: > > > > > > > I have a question regarding IPsec inner workings..... > > > > > > > > Is there a provision for Flow Control in the IPSec Standards? > > > > > > > > I understand that IPSec essentially runs at Layer 3 which does not > > > include > > > > flow control algorithms (usually left to Layer 4 protocols such as > > TCP); > > > > however I have noticed in live implementations of the protocol, long > > > delay > > > > networks (250ms round-trip) suffer serious performance issues when > > > compared > > > > to non-encrypted TCP communications such as Ftp's, using large (64k) > > TCP > > > > Receive Windows. Trace analysis shows a large percentage of time > > spent > > > > waiting for ACKs to transmitted ESP packets. Is there no way to > > control > > > > the amount of data "in flight", ie setting a higher Window? Using > > IPSec > > > > Encapsulation seems to override or Break the TCP Windows set in the > > > > encrypted packet headers, do to its own method of flow control (or > > lack > > > > thereof)..... > > > > > > > > I am wondering if this was overlooked? > > > > > > > > Thanks, > > > > > > > > ___________________________________ > > > > Rett D. Walters > > > > Network Architect > > > > Payless ShoeSource Inc. > > > > Phone: 785-295-2049, Fax: 785-295-6666 > > > > Email: rett.walters@payless.com > > > > > > > > > > > > > > -- > > > 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 Tue Jul 24 12:36:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OJa6G04719; Tue, 24 Jul 2001 12:36:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02312 Tue, 24 Jul 2001 14:53:59 -0400 (EDT) From: Rett_Walters@payless.com Message-Id: <200107241902.OAA20034@gateway.paylessshoesource.com> Subject: Re: IPSec Standard - No Flow Control? To: sommerfeld@East.Sun.COM Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Date: Tue, 24 Jul 2001 13:37:55 -0500 X-MIMETrack: Serialize by Router on PSAMAILC/PSS(Release 5.0.7 |March 21, 2001) at 07/24/2001 01:38:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I will get some better trace data together and put them on an anonymous FTP..... I will send the list the location when I am done. Thanks, Rett Walters Bill Sommerfeld cc: Sent by: Subject: Re: IPSec Standard - No Flow Control? sommerfeld@thunk.ea st.sun.com 07/24/2001 12:51 PM Please respond to sommerfeld Two comments: - The trace you sent me doesn't include the TCP connection establishment (SYN / SYN+ACK packets); those contain MSS options, and I wanted to see what the negotiated MSS values were... - If you want more help debugging this, put new traces (showing both the connection setup and the connection lag) on an anonymous FTP or web site somewhere and send the URL's to the ipsec list. - Bill From owner-ipsec@lists.tislabs.com Tue Jul 24 14:50:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OLoSs01239; Tue, 24 Jul 2001 14:50:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02522 Tue, 24 Jul 2001 17:04:34 -0400 (EDT) To: "Wang, Cliff" Cc: ipsec@lists.tislabs.com Subject: Re: trivial question: IPsec or IPSec? References: <4652644B98DFF34696801F8F3070D3FE1E190A@D2CSPEXM001.smartpipes.com> From: Derek Atkins Date: 24 Jul 2001 17:11:15 -0400 In-Reply-To: "Wang, Cliff"'s message of "Tue, 24 Jul 2001 21:01:51 -0000" Message-ID: Lines: 19 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I believe, according to the RFCs, the correct spelling is IPsec. However, may word-processing applications will convert "IPsec" to "Ipsec", so I bet many people write it as "IPSec" to get around broken word processors (such as M$ Word). -derek "Wang, Cliff" writes: > I was asked by a tech writer on the term. I always thought IPsec is > the correct spelling such as in RFC 2401, but I also found many people > uses the spelling IPSec. So now even I am confused. Apologize if > this has been clarified before. -- 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 Tue Jul 24 14:50:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OLogs01259; Tue, 24 Jul 2001 14:50:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA02495 Tue, 24 Jul 2001 16:56:14 -0400 (EDT) Message-ID: <4652644B98DFF34696801F8F3070D3FE1E190A@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: ipsec@lists.tislabs.com Subject: trivial question: IPsec or IPSec? Date: Tue, 24 Jul 2001 21:01:51 -0000 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 was asked by a tech writer on the term. I always thought IPsec is the correct spelling such as in RFC 2401, but I also found many people uses the spelling IPSec. So now even I am confused. Apologize if this has been clarified before. From owner-ipsec@lists.tislabs.com Tue Jul 24 14:58:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6OLwMs01366; Tue, 24 Jul 2001 14:58:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02552 Tue, 24 Jul 2001 17:20:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4652644B98DFF34696801F8F3070D3FE1E190A@D2CSPEXM001.smartpipes.com> References: <4652644B98DFF34696801F8F3070D3FE1E190A@D2CSPEXM001.smartpipes.com> Date: Tue, 24 Jul 2001 17:29:55 -0400 To: "Wang, Cliff" From: Stephen Kent Subject: Re: trivial question: IPsec or IPSec? Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:01 PM +0000 7/24/01, Wang, Cliff wrote: >I was asked by a tech writer on the term. I always thought IPsec is >the correct spelling such as in RFC 2401, but I also found many people >uses the spelling IPSec. So now even I am confused. Apologize if >this has been clarified before. IPsec is the correct spelling, as specified in the RFCs. Many folks do misspell it as IPSec, but we try to correct that when we encounter the error. Steve From owner-ipsec@lists.tislabs.com Tue Jul 24 21:08:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6P48As08402; Tue, 24 Jul 2001 21:08:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA03135 Tue, 24 Jul 2001 23:04:52 -0400 (EDT) From: Rett_Walters@payless.com Subject: Re: IPSec Standard - No Flow Control? To: sommerfeld@East.Sun.COM Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 24 Jul 2001 22:12:25 -0500 X-MIMETrack: Serialize by Router on PSAMAILC/PSS(Release 5.0.7 |March 21, 2001) at 07/24/2001 10:12:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To all: The complete trace files are available via anonymous ftp from: ftp://vega.dnsalias.net/outgoing There are 4 files. Here is a description: trusted1.cap.zip - Sniffer Pro format of trusted(LAN) side of VPN (approx 6000 frames) trusted1.prn.zip - ASCII dump of above trace (Only includes first 1500 frames, which should cover everything) untrusted1.cap.zip - Sniffer Pro format of untrusted (Internet) side of VPN (approx 5000 frames) untrusted1.prn.zip - ASCII dump of above trace (Once again, only 1500 frames) Hope this is enough information. BTW, one host in the transfer is set to 1400 MTU to keep fragmentation down. Thanks, Rett Walters |--------+-----------------------------> | | Bill Sommerfeld | | | | | | Sent by: | | | sommerfeld@thunk.ea| | | st.sun.com | | | | | | | | | 07/24/2001 12:51 PM| | | Please respond to | | | sommerfeld | | | | |--------+-----------------------------> >------------------------------------------------------------------------------------------------------------------------| | | | To: Rett_Walters@payless.com | | cc: | | Subject: Re: IPSec Standard - No Flow Control? | >------------------------------------------------------------------------------------------------------------------------| Two comments: - The trace you sent me doesn't include the TCP connection establishment (SYN / SYN+ACK packets); those contain MSS options, and I wanted to see what the negotiated MSS values were... - If you want more help debugging this, put new traces (showing both the connection setup and the connection lag) on an anonymous FTP or web site somewhere and send the URL's to the ipsec list. - Bill From owner-ipsec@lists.tislabs.com Wed Jul 25 07:49:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6PEnos17093; Wed, 25 Jul 2001 07:49:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04478 Wed, 25 Jul 2001 09:21:01 -0400 (EDT) From: Rett_Walters@payless.com Subject: Re: IPSec Standard - No Flow Control? To: Joern Sierwald Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 25 Jul 2001 08:27:54 -0500 X-MIMETrack: Serialize by Router on PSAMAILC/PSS(Release 5.0.7 |March 21, 2001) at 07/25/2001 08:27:59 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA04475 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I seem to be having an ISP issue. I will post to the list when its back up. Thanks, Rett Walters Joern Sierwald cc: Subject: Re: IPSec Standard - No Flow Control? 07/25/2001 01:20 AM At 22:12 24.07.01 -0500, you wrote: > >To all: > >The complete trace files are available via anonymous ftp from: >ftp://vega.dnsalias.net/outgoing > ftp connect just times out. Ping doesn't work. Jörn From owner-ipsec@lists.tislabs.com Wed Jul 25 10:18:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6PHIOs25175; Wed, 25 Jul 2001 10:18:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04959 Wed, 25 Jul 2001 12:23:56 -0400 (EDT) Message-ID: From: Ranjit Kumar Avasarala To: ipsec@lists.tislabs.com Subject: IPSec vs Ipv6 Date: Wed, 25 Jul 2001 11:39:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11528.57FFD546" 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_01C11528.57FFD546 Content-Type: text/plain; charset="iso-8859-1" Regards Ranjit Hi Since IPv6 takes care of Authentication, Privacy capabilities, do we still require IPSec in Ipv6? Regards Ranjit ------_=_NextPart_001_01C11528.57FFD546 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPSec vs Ipv6

Regards
Ranjit
Hi

    Since IPv6 takes care of = Authentication, Privacy capabilities, do we still require IPSec in = Ipv6?

Regards
Ranjit

------_=_NextPart_001_01C11528.57FFD546-- From owner-ipsec@lists.tislabs.com Wed Jul 25 10:59:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6PHxYs26065; Wed, 25 Jul 2001 10:59:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05056 Wed, 25 Jul 2001 13:07:24 -0400 (EDT) Message-Id: <200107251714.f6PHE2n18072@kebe.east.sun.com> Subject: Re: IPSec vs Ipv6 In-Reply-To: from Ranjit Kumar Avasarala at "Jul 25, 2001 11:39:15 am" To: Ranjit Kumar Avasarala Date: Wed, 25 Jul 2001 13:14:02 -0400 (EDT) CC: ipsec@lists.tislabs.com From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering 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 > Since IPv6 takes care of Authentication, Privacy capabilities, do we > still require IPSec in Ipv6? IPv6 takes care of authentication and privacy by EMPLOYING IPsec and requiring its implementation for a fully compliant/interoperable IPv6 implementation. What is now IPsec's AH and ESP came out of IPv6 (back then it was SIPP) work. Dan From owner-ipsec@lists.tislabs.com Wed Jul 25 11:04:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6PI44s26180; Wed, 25 Jul 2001 11:04:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05075 Wed, 25 Jul 2001 13:16:44 -0400 (EDT) Date: Wed, 25 Jul 2001 13:22:59 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: IPSec vs Ipv6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 25 Jul 2001, Ranjit Kumar Avasarala wrote: > Since IPv6 takes care of Authentication, Privacy capabilities, do we > still require IPSec in Ipv6? IPv6 "takes care of" authentication and privacy by requiring that all IPv6 implementations include IPsec. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jul 25 11:54:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6PIsJs26969; Wed, 25 Jul 2001 11:54:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05133 Wed, 25 Jul 2001 14:00:01 -0400 (EDT) From: Steve.Robinson@psti.com Subject: Re: IPSec vs Ipv6 To: Ranjit Kumar Avasarala 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, 25 Jul 2001 14:10:14 -0400 X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.5 |September 22, 2000) at 07/25/2001 07:10:50 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ummmm.... The security requirements that IPv6 "takes care of" is IPsec (now RFC 2402 and RFC 2406), there are no separate protocols that are any easier. Steve Ranjit Kumar Avasarala To: ipsec@lists.tislabs.com Subject: IPSec vs Ipv6 Sent by: owner-ipsec@lists.t islabs.com 07/25/01 12:39 PM Regards Ranjit Hi Since IPv6 takes care of Authentication, Privacy capabilities, do we still require IPSec in Ipv6? Regards Ranjit From owner-ipsec@lists.tislabs.com Wed Jul 25 17:52:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6Q0qts04947; Wed, 25 Jul 2001 17:52:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05725 Wed, 25 Jul 2001 19:57:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message Subject: More MODP Diffie-Hellman groups for IKE Date: Wed, 25 Jul 2001 17:01:46 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1018654BD@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: More MODP Diffie-Hellman groups for IKE Thread-Index: AcEUvnX9Vp0FhjdYTDKpWDlR7Ypx0wAp5rVg From: "William Dixon" To: Cc: "Tero Kivinen" X-OriginalArrivalTime: 26 Jul 2001 00:01:47.0239 (UTC) FILETIME=[29A19F70:01C11566] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Does anybody have any problems with this draft ? Anyone oppose last call for it ? Tero said he hasn't heard much from people, and so we aren't sure who is implementing. But it seems people are happy with the numbers. We should get this out so DOI numbers can be assigned so we can actually interop w/o new group mode. Wm Apologize if this is a resend, didn't see it hit the list yesterday. From owner-ipsec@lists.tislabs.com Wed Jul 25 18:02:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6Q12ws05089; Wed, 25 Jul 2001 18:02:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA05783 Wed, 25 Jul 2001 20:28:30 -0400 (EDT) From: Rett_Walters@payless.com Subject: Re: IPSec Standard - No Flow Control? To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 25 Jul 2001 19:36:04 -0500 X-MIMETrack: Serialize by Router on PSAMAILC/PSS(Release 5.0.7 |March 21, 2001) at 07/25/2001 07:36:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id UAA05780 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The ISP issue mentioned below has been fixed. (Lost cable service) If anyone is still interested, the trace files are again available at: ftp://vega.dnsalias.net/outgoing Thanks, Rett Walters Rett_Walters@payles s.com To: Joern Sierwald Sent by: cc: ipsec@lists.tislabs.com owner-ipsec@lists.t Subject: Re: IPSec Standard - No Flow Control? islabs.com 07/25/2001 08:27 AM I seem to be having an ISP issue. I will post to the list when its back up. Thanks, Rett Walters Joern Sierwald cc: Subject: Re: IPSec Standard - No Flow Control? 07/25/2001 01:20 AM At 22:12 24.07.01 -0500, you wrote: > >To all: > >The complete trace files are available via anonymous ftp from: >ftp://vega.dnsalias.net/outgoing > ftp connect just times out. Ping doesn't work. Jörn From owner-ipsec@lists.tislabs.com Wed Jul 25 18:31:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6Q1V7s05780; Wed, 25 Jul 2001 18:31:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA05821 Wed, 25 Jul 2001 20:57:48 -0400 (EDT) Message-ID: <3B5F6C5E.A5F777DF@cyphers.net> Date: Wed, 25 Jul 2001 18:03:26 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: More MODP Diffie-Hellman groups for IKE References: <2E33960095B58E40A4D3345AB9F65EC1018654BD@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 Looks good to us. The only reason we haven't tested it is because the ID numbers haven't been assigned yet. William Dixon wrote: > > Does anybody have any problems with this draft ? Anyone oppose last > call for it ? Tero said he hasn't heard much from people, and so we > aren't sure who is implementing. But it seems people are happy with the > numbers. > > We should get this out so DOI numbers can be assigned so we can actually > interop w/o new group mode. > > Wm > > Apologize if this is a resend, didn't see it hit the list yesterday. -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ipsec@lists.tislabs.com Thu Jul 26 01:24:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6Q8O1s01283; Thu, 26 Jul 2001 01:24:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA06341 Thu, 26 Jul 2001 03:23:04 -0400 (EDT) Message-ID: <022f01c115a4$c43f7f00$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , Cc: References: <3B320F85.5A8943D5@lmf.ericsson.se> Subject: IPsec, IKE, IPv6 Date: Thu, 26 Jul 2001 10:29:55 +0300 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, The upcoming IETF meeting reminds me that we had a discussion in the last meeting about certain IPv6 related issues in IPsec, and that we were supposed to get back to the discussion on the mailing list. Specifically, our drafts addressed two issues related to IPv6, namely (a) circular IKE/ICMPv6 traffic in normal IPsec use, and (2) if, and how, IPsec can be used to protect IPv6 control signalling. My interpretation of the discussion in the meeting regarding the first issue was that there was a recognition of the problem from the some of the implementors far enough to run into this. But there were question marks regarding how to document this, if a change in RFC 2401 etc is needed. The draft for the second issue mainly describes the problem, and documents some of the security implications. It also briefly mentioned possible ways to reduce configuration effort. My interpretation of the discussions was that some previous work had existed on this space, but people were not sure if any new solutions were needed for the ICMPv6 protection. The main discussion was on the solutions, not the problem. Now, what should we do then? The first issue looks like an existing problem in typical IPsec situations when IPv6 is used. It has an easy solution which most vendors with IPv6 IKE have adopted. I think we should document the issue and the solution, to ensure that future implementors don't have to reinvent the wheel, and more importantly, to ensure interoperability. I happen to believe in small RFCs and quick progress, so I'd rather see this documentation as a separate RFC rather than updated RFC 2401, which might take ages. Therefore, I'm proposing that the WG adopts the first draft as an official work item. (Also, I'd be very interested in testing this against other folks in the Espoo bakeoff the week after next week.) Regarding the second issue, I'm even myself unsure if we need any new solutions, hence any development of possible configuration effort reductions is propably not warranted. However, here too we should perhaps document the issue. Shouldn't we then adopt also the second draft as a work item as well, but not add any more detail on possible solutions? Jari ----- Last meetings's minutes: > IPSEC and IPV6 > > 1. Jari Arkko presented the draft on Effects on ICMPv6 on IKE and > IPsec Policies. This draft covers a problem with circular icmp > traffic. > > 2. Jari Arkko also presented the draft on Manual SA Configuration for IPv6 > Link Local Messages. Analyzed of icmpv6 security implications. Table > presented that showed control functions against weak and strong attackers > at low and high levels. DoS for weak attackers under higher layer security; > man in the middle, spying, and impersonation for all attackers under no > higher layer security; identity selection in all situations, if stateful... > He presented possible ways to reduce the configuration effort which was > about twice the SAs as the number of nodes. > > Comments: Dan McDonald draft on link shared secret, presented in > Adelaide to the v6 group and it could be dragged back up to help with > the manual configuration. > > Steve Kent suggested that we need a more complete story in order to > motivate people. > > We'll need more discussion on the mailing list to see how to proceed > with both of these. The drafts: >Effects of ICMPv6 on IKE and IPsec Policies >http://search.ietf.org/internet-drafts/draft-arkko-icmpv6-ike-effects-00.txt > >Manual SA Configuration for IPv6 Link Local Messages >http://search.ietf.org/internet-drafts/draft-arkko-manual-icmpv6-sas-00.txt From owner-ipsec@lists.tislabs.com Thu Jul 26 01:48:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6Q8m0s04552; Thu, 26 Jul 2001 01:48:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA06541 Thu, 26 Jul 2001 04:10:36 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: , Subject: RE: More MODP Diffie-Hellman groups for IKE Date: Thu, 26 Jul 2001 03:56:45 -0400 Message-Id: <001301c115aa$31370ec0$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: <3B5F6C5E.A5F777DF@cyphers.net> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've implemented them using 40000 + modulus size as the private ID numbers. I much prefer that to New Group mode. But I agree that there is no reason why these shouldn't get DOI numbers assigned. 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 Will Price > Sent: Wednesday, July 25, 2001 9:03 PM > To: ipsec@lists.tislabs.com > Subject: Re: More MODP Diffie-Hellman groups for IKE > > > Looks good to us. > > The only reason we haven't tested it is because the ID numbers haven't > been assigned yet. > > > > William Dixon wrote: > > > > Does anybody have any problems with this draft ? Anyone oppose last > > call for it ? Tero said he hasn't heard much from people, and so we > > aren't sure who is implementing. But it seems people are > happy with the > > numbers. > > > > We should get this out so DOI numbers can be assigned so we > can actually > > interop w/o new group mode. > > > > Wm > > > > Apologize if this is a resend, didn't see it hit the list yesterday. > > -- > > Will Price, Director of Engineering > PGP Security, Inc. > a division of Network Associates, Inc. > From owner-ipsec@lists.tislabs.com Thu Jul 26 08:55:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QFtZs23002; Thu, 26 Jul 2001 08:55:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11017 Thu, 26 Jul 2001 10:31:16 -0400 (EDT) From: Rett_Walters@payless.com Subject: RE: IPSec Standard - No Flow Control? To: "Joergensen, Michael" , clordello@unispherenetworks.com Cc: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 26 Jul 2001 09:24:52 -0500 X-MIMETrack: Serialize by Router on PSAMAILC/PSS(Release 5.0.7 |March 21, 2001) at 07/26/2001 09:38:54 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA11014 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To all: I apologize once again...... My company does not allow ftp traffic into our site (they will not allow us to put up an ftp server; one of our wonderful loss prevention policies.) Therefore I have had to throw one together at home really quick...... And I must have missed the permissions.... They have been fixed and tested. Thanks for all of your time and efforts, Rett Walters "Joergensen, Michael" To: "'Rett_Walters@payless.com'" intel.com> cc: Subject: RE: IPSec Standard - No Flow Control? 07/26/2001 02:43 AM Hi Rett, There appears to be problems with the access rights. I get a "permission denied" when trying to 'get' the files via FTP. -Michael. -----Original Message----- From: Rett_Walters@payless.com [mailto:Rett_Walters@payless.com] Sent: 26. juli 2001 02:36 To: ipsec@lists.tislabs.com Subject: Re: IPSec Standard - No Flow Control? The ISP issue mentioned below has been fixed. (Lost cable service) If anyone is still interested, the trace files are again available at: ftp://vega.dnsalias.net/outgoing Thanks, Rett Walters Rett_Walters@payles s.com To: Joern Sierwald Sent by: cc: ipsec@lists.tislabs.com owner-ipsec@lists.t Subject: Re: IPSec Standard - No Flow Control? islabs.com 07/25/2001 08:27 AM I seem to be having an ISP issue. I will post to the list when its back up. Thanks, Rett Walters Joern Sierwald cc: Subject: Re: IPSec Standard - No Flow Control? 07/25/2001 01:20 AM At 22:12 24.07.01 -0500, you wrote: > >To all: > >The complete trace files are available via anonymous ftp from: >ftp://vega.dnsalias.net/outgoing > ftp connect just times out. Ping doesn't work. Jörn From owner-ipsec@lists.tislabs.com Thu Jul 26 14:51:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6QLpUs01088; Thu, 26 Jul 2001 14:51:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11847 Thu, 26 Jul 2001 16:51:24 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message Subject: More MODP Diffie-Hellman groups for IKE Date: Tue, 24 Jul 2001 21:00:09 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1018654A2@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: More MODP Diffie-Hellman groups for IKE Thread-Index: AcEUvnX9Vp0FhjdYTDKpWDlR7Ypx0w== From: "William Dixon" To: Cc: "Tero Kivinen" X-OriginalArrivalTime: 25 Jul 2001 04:00:11.0556 (UTC) FILETIME=[4D416E40:01C114BE] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Does anybody have any problems with this draft ? Anyone oppose last call for it ? Tero said he hasn't heard much from people, and so we aren't sure who is implementing. It seems people are happy with the numbers. We should get this out so DOI numbers can be assigned so we can actually interop w/o new group mode. Wm From owner-ipsec@lists.tislabs.com Fri Jul 27 03:01:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RA10s09222; Fri, 27 Jul 2001 03:01:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA12927 Fri, 27 Jul 2001 04:50:00 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE7838128210@ROC-76-204.nai.com> From: "Mason, David" To: "'William Dixon'" , ipsec@lists.tislabs.com Cc: Tero Kivinen Subject: RE: More MODP Diffie-Hellman groups for IKE Date: Fri, 27 Jul 2001 01:54:50 -0700 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 A cryptographer had told me that with the larger MODP DH groups (2048 and higher) that it would be advantageous if the least and most significant 128-bits were set to 1's. Cons: CPU time required to generate and validate new primes People who have already implemented the drafts would have to change their implementations Less random bits in the primes The format would change slightly compared to the smaller primes Pros: Large word processors could take advantage of certain performance improving optimizations Primes still contain more random bits than the smaller primes Since the DOI numbers haven't been assigned yet people will have to change their code anyways Future advances in CPU architecture might make the optimizations available to general purpose CPUs Special purpose DH acceleration cards might take advantage of the optimizations Decision would be made based on a cryptographic basis rather than format looks Are there any cryptographers out there listening that could comment on the classical remainder algorithm and the Montgomery-style remainder algorithms and how much of an advantage the trial quotient digit always taken as the high order word of the dividend and the multiplier digit always taken to be the low order word of the dividend is? I'm guessing that all that is required to take advantage of these optimizations is the ability to perform 64-bit integer operations with a 128-bit result (but it could be 128-bit operations with a 256-bit result). Either way I think it is important to take a forward looking approach on this matter. These larger DH groups are really going to slow down the key exchange so any optimization that can be found should be taken advantage of. -dave -----Original Message----- From: William Dixon [mailto:wdixon@windows.microsoft.com] Sent: Wednesday, July 25, 2001 12:00 AM To: ipsec@lists.tislabs.com Cc: Tero Kivinen Subject: More MODP Diffie-Hellman groups for IKE Does anybody have any problems with this draft ? Anyone oppose last call for it ? Tero said he hasn't heard much from people, and so we aren't sure who is implementing. It seems people are happy with the numbers. We should get this out so DOI numbers can be assigned so we can actually interop w/o new group mode. Wm From owner-ipsec@lists.tislabs.com Fri Jul 27 04:41:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RBfWs13387; Fri, 27 Jul 2001 04:41:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA13107 Fri, 27 Jul 2001 07:02:08 -0400 (EDT) Message-Id: <200107271107.HAA06703@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-lifetime-00.txt Date: Fri, 27 Jul 2001 07:07:56 -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 : Responder Lifetime Notify Message for IKE Author(s) : S. Fanning Filename : draft-ietf-ipsec-ike-lifetime-00.txt Pages : 5 Date : 26-Jul-01 This document describes how the RESPONDER-LIFETIME notify message, used within the ISAKMP DOI can be used to facilitate lifetime negotiation and rekeying. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt 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-lifetime-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-ietf-ipsec-ike-lifetime-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: <20010726170632.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-lifetime-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170632.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 27 07:35:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6REZvs17113; Fri, 27 Jul 2001 07:35:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13422 Fri, 27 Jul 2001 09:41:48 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15201.28429.799003.22867@thomasm-u1.cisco.com> Date: Fri, 27 Jul 2001 06:39:25 -0700 (PDT) To: Internet-Drafts@ietf.org Cc: IETF-Announce:;, ipsec@lists.tislabs.com Subject: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt In-Reply-To: <200107271107.HAA06703@ietf.org> References: <200107271107.HAA06703@ietf.org> 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 Er, wouldn't the more sensible thing to do here in general is to create a means of having a reliable Delete notification? This is what KINK does, and seems a lot more sensible/robust overall. I'll note that this still seems to have the packet loss problem described in section 3b. Mike Internet-Drafts@ietf.org writes: > 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 : Responder Lifetime Notify Message for IKE > Author(s) : S. Fanning > Filename : draft-ietf-ipsec-ike-lifetime-00.txt > Pages : 5 > Date : 26-Jul-01 > > This document describes how the RESPONDER-LIFETIME notify message, > used within the ISAKMP DOI can be used to facilitate lifetime > negotiation and rekeying. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt > > 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-lifetime-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-ietf-ipsec-ike-lifetime-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. > Content-Type: text/plain > Content-ID: <20010726170632.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt > Content-Type: text/plain > Content-ID: <20010726170632.I-D@ietf.org> From owner-ipsec@lists.tislabs.com Fri Jul 27 08:27:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RFR0s20167; Fri, 27 Jul 2001 08:27:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13548 Fri, 27 Jul 2001 10:34:28 -0400 (EDT) Message-ID: <003601c116a9$cfb78700$872745ab@cisco.com> From: "Scott Fanning" To: "Michael Thomas" , Cc: , References: <200107271107.HAA06703@ietf.org> <15201.28429.799003.22867@thomasm-u1.cisco.com> Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt Date: Fri, 27 Jul 2001 07:38:33 -0700 Organization: Cisco Systems 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.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Er, you are right, but I don't see much movement on the ack'd notify front. Since changing IKE is not allowed, this seemed like the easiest route to move forward with. Also, acks could be lost as well, so 3b could happen in the ACK'd case as well. I do not claim that this solves every problem, but I think it is a simple solution that could be implemented in a short amount of time, with little interop issues. Scott ----- Original Message ----- From: "Michael Thomas" To: Cc: ; Sent: Friday, July 27, 2001 6:39 AM Subject: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt > > Er, wouldn't the more sensible thing to do here in > general is to create a means of having a reliable > Delete notification? This is what KINK does, and > seems a lot more sensible/robust overall. I'll > note that this still seems to have the packet loss > problem described in section 3b. > > Mike > > Internet-Drafts@ietf.org writes: > > 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 : Responder Lifetime Notify Message for IKE > > Author(s) : S. Fanning > > Filename : draft-ietf-ipsec-ike-lifetime-00.txt > > Pages : 5 > > Date : 26-Jul-01 > > > > This document describes how the RESPONDER-LIFETIME notify message, > > used within the ISAKMP DOI can be used to facilitate lifetime > > negotiation and rekeying. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt > > > > 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-lifetime-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-ietf-ipsec-ike-lifetime-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. > > Content-Type: text/plain > > Content-ID: <20010726170632.I-D@ietf.org> > > > > ENCODING mime > > FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt > > Content-Type: text/plain > > Content-ID: <20010726170632.I-D@ietf.org> From owner-ipsec@lists.tislabs.com Fri Jul 27 08:38:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RFcNs22160; Fri, 27 Jul 2001 08:38:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13589 Fri, 27 Jul 2001 10:46:43 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15201.32842.935371.152117@thomasm-u1.cisco.com> Date: Fri, 27 Jul 2001 07:52:58 -0700 (PDT) To: "Scott Fanning" Cc: "Michael Thomas" , , , Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt In-Reply-To: <003601c116a9$cfb78700$872745ab@cisco.com> References: <200107271107.HAA06703@ietf.org> <15201.28429.799003.22867@thomasm-u1.cisco.com> <003601c116a9$cfb78700$872745ab@cisco.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 Scott Fanning writes: > Er, you are right, but I don't see much movement on the ack'd notify front. > Since changing IKE is not allowed, this seemed like the easiest route to > move forward with. Also, acks could be lost as well, so 3b could happen in > the ACK'd case as well. I do not claim that this solves every problem, but I > think it is a simple solution that could be implemented in a short amount of > time, with little interop issues. If there were a son-of-ike, would this be a potential change? It seems like all that his necessary is to have a bit which requires the peer to send a (potentially empty) notification in response. As far as the ACK lossage goes, there are two cases: 1) initiator loses the response from respondent 2) respondent loses ACK from initiator In case one, the initiator would obliged to retransmit its request since it didn't get a response. In case two, it's just a matter of knowing when to *really* shutdown the SA so that in-flight packets aren't lost, if it keeps the SA open at all while waiting for the ACK. In that case, a grace timer which expires in lieu of the ACK is probably sufficient since it's really just a courtesy. If respondent needs a fail safe method, it can, as well, send the delete notification as an initiator. Mike > > Scott > ----- Original Message ----- > From: "Michael Thomas" > To: > Cc: ; > Sent: Friday, July 27, 2001 6:39 AM > Subject: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt > > > > > > Er, wouldn't the more sensible thing to do here in > > general is to create a means of having a reliable > > Delete notification? This is what KINK does, and > > seems a lot more sensible/robust overall. I'll > > note that this still seems to have the packet loss > > problem described in section 3b. > > > > Mike > > > > Internet-Drafts@ietf.org writes: > > > 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 : Responder Lifetime Notify Message for IKE > > > Author(s) : S. Fanning > > > Filename : draft-ietf-ipsec-ike-lifetime-00.txt > > > Pages : 5 > > > Date : 26-Jul-01 > > > > > > This document describes how the RESPONDER-LIFETIME notify message, > > > used within the ISAKMP DOI can be used to facilitate lifetime > > > negotiation and rekeying. > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt > > > > > > 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-lifetime-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-ietf-ipsec-ike-lifetime-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. > > > Content-Type: text/plain > > > Content-ID: <20010726170632.I-D@ietf.org> > > > > > > ENCODING mime > > > FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt > > > Content-Type: text/plain > > > Content-ID: <20010726170632.I-D@ietf.org> > From owner-ipsec@lists.tislabs.com Fri Jul 27 08:49:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RFnqs24296; Fri, 27 Jul 2001 08:49:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA13625 Fri, 27 Jul 2001 10:53:11 -0400 (EDT) Message-ID: <005001c116ac$6dae9af0$872745ab@cisco.com> From: "Scott Fanning" To: "Michael Thomas" Cc: "Michael Thomas" , References: <200107271107.HAA06703@ietf.org><15201.28429.799003.22867@thomasm-u1.cisco.com><003601c116a9$cfb78700$872745ab@cisco.com> <15201.32842.935371.152117@thomasm-u1.cisco.com> Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt Date: Fri, 27 Jul 2001 07:57:17 -0700 Organization: Cisco Systems 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.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One of my motivations of this draft was to "gently" push for a son-of-ike. I would love to see the ACK'd notify messages in Son-of-ike or maybe recognition that this is a stateful protocol that either requires connection based transport, or better defined robustness in the draft. I still think that, until that day comes, this is still a useful proposal. Maybe this could be in the son-of-ike as well. Scott ----- Original Message ----- From: "Michael Thomas" To: "Scott Fanning" Cc: "Michael Thomas" ; ; Sent: Friday, July 27, 2001 7:52 AM Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt > Scott Fanning writes: > > Er, you are right, but I don't see much movement on the ack'd notify front. > > Since changing IKE is not allowed, this seemed like the easiest route to > > move forward with. Also, acks could be lost as well, so 3b could happen in > > the ACK'd case as well. I do not claim that this solves every problem, but I > > think it is a simple solution that could be implemented in a short amount of > > time, with little interop issues. > > If there were a son-of-ike, would this be a potential change? > It seems like all that his necessary is to have a bit which > requires the peer to send a (potentially empty) notification > in response. > > As far as the ACK lossage goes, there are two cases: > > 1) initiator loses the response from respondent > 2) respondent loses ACK from initiator > > In case one, the initiator would obliged to retransmit > its request since it didn't get a response. In case two, > it's just a matter of knowing when to *really* shutdown > the SA so that in-flight packets aren't lost, if it keeps > the SA open at all while waiting for the ACK. In that > case, a grace timer which expires in lieu of the ACK > is probably sufficient since it's really just a courtesy. > If respondent needs a fail safe method, it can, as well, > send the delete notification as an initiator. > > Mike > > > > > Scott > > ----- Original Message ----- > > From: "Michael Thomas" > > To: > > Cc: ; > > Sent: Friday, July 27, 2001 6:39 AM > > Subject: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt > > > > > > > > > > Er, wouldn't the more sensible thing to do here in > > > general is to create a means of having a reliable > > > Delete notification? This is what KINK does, and > > > seems a lot more sensible/robust overall. I'll > > > note that this still seems to have the packet loss > > > problem described in section 3b. > > > > > > Mike > > > > > > Internet-Drafts@ietf.org writes: > > > > 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 : Responder Lifetime Notify Message for IKE > > > > Author(s) : S. Fanning > > > > Filename : draft-ietf-ipsec-ike-lifetime-00.txt > > > > Pages : 5 > > > > Date : 26-Jul-01 > > > > > > > > This document describes how the RESPONDER-LIFETIME notify message, > > > > used within the ISAKMP DOI can be used to facilitate lifetime > > > > negotiation and rekeying. > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt > > > > > > > > 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-lifetime-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-ietf-ipsec-ike-lifetime-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. > > > > Content-Type: text/plain > > > > Content-ID: <20010726170632.I-D@ietf.org> > > > > > > > > ENCODING mime > > > > FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt > > > > Content-Type: text/plain > > > > Content-ID: <20010726170632.I-D@ietf.org> > > From owner-ipsec@lists.tislabs.com Fri Jul 27 08:51:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RFp8s24490; Fri, 27 Jul 2001 08:51:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13670 Fri, 27 Jul 2001 11:05:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Fri, 27 Jul 2001 16:19:10 +0200 To: ipsec@lists.tislabs.com From: Paul Hoffman / IMC Subject: Fwd: Last Call: Securing L2TP using IPSEC to Proposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Quite relevant to this WG. >To: IETF-Announce: ; >Cc: l2tp@l2tp.net >From: The IESG >SUBJECT: Last Call: Securing L2TP using IPSEC to Proposed Standard >Reply-to: iesg@ietf.org >Date: Wed, 25 Jul 2001 13:02:40 -0400 >Sender: scoya@cnri.reston.va.us > > >The IESG has received a request from the Layer Two Tunneling Protocol >Extensions Working Group to consider Securing L2TP using IPSEC > as a Proposed Standard. > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by August 25, 2001. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-security-04.txt From owner-ipsec@lists.tislabs.com Fri Jul 27 10:05:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RH5xs26355; Fri, 27 Jul 2001 10:05:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13799 Fri, 27 Jul 2001 12:17:04 -0400 (EDT) Message-ID: <8894CA1F87A5D411BD24009027EE7838128218@ROC-76-204.nai.com> From: "Mason, David" To: "'Scott Fanning'" , Michael Thomas Cc: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt Date: Fri, 27 Jul 2001 09:21:51 -0700 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 my motivations of this draft was to "gently" push for a son-of-ike. I > would love to see the ACK'd notify messages in Son-of-ike or maybe > recognition that this is a stateful protocol that either requires connection > based transport, or better defined robustness in the draft. I still think > that, until that day comes, this is still a useful proposal. Maybe this > could be in the son-of-ike as well. Hopefully son-of-ike will incorporate draft-ietf-ipsec-ike-hash-revised-02.txt in which case phase 1 responder lifetimes can be protected within the phase 1 exchange. Although this info would then be exposed in Aggressive Mode (or the AM replacement if there is one in son-of-ike), it will at least be protected from modification under the revised hash. I have seen many implementations that already send IKE responder lifetimes. In RFC2407 when it mentioned using the cookies for the SPI that's what I thought it was referring to (IKE not IPsec responder-lifetime). In the spirit of be strict in what you send and forgiving in what you'll accept it should be noted that the receiver of IKE responder lifetimes SHOULD accept a Notify DOI field of IPSEC (1) as well as IKE (0). -dave From owner-ipsec@lists.tislabs.com Fri Jul 27 10:25:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RHP9s26935; Fri, 27 Jul 2001 10:25:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13827 Fri, 27 Jul 2001 12:33:52 -0400 (EDT) Message-ID: <007201c116ba$6ef06160$872745ab@cisco.com> From: "Scott Fanning" To: "Mason, David" , "Michael Thomas" Cc: References: <8894CA1F87A5D411BD24009027EE7838128218@ROC-76-204.nai.com> Subject: Re: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt Date: Fri, 27 Jul 2001 09:37:31 -0700 Organization: Cisco Systems 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.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks. I am hoping that all of us can pull together to do the son-of-ike based on all the lessons learned. I very much agree that the revised hash is the way to go, and needs to be built into the next ike revision. I would like hybrid as well to cover the remote access angle, but thats another story :-) Does anybody know the current status of son-of-ike? I missed the last IETF, and I had heard that there was a presentation done on it. Is there anything on the agenda for an update? Scott ----- Original Message ----- From: "Mason, David" To: "'Scott Fanning'" ; "Michael Thomas" Cc: Sent: Friday, July 27, 2001 9:21 AM Subject: RE: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt > > One of my motivations of this draft was to "gently" push for a son-of-ike. > I > > would love to see the ACK'd notify messages in Son-of-ike or maybe > > recognition that this is a stateful protocol that either requires > connection > > based transport, or better defined robustness in the draft. I still think > > that, until that day comes, this is still a useful proposal. Maybe this > > could be in the son-of-ike as well. > > Hopefully son-of-ike will incorporate > draft-ietf-ipsec-ike-hash-revised-02.txt > in which case phase 1 responder lifetimes can be protected within the phase > 1 > exchange. Although this info would then be exposed in Aggressive Mode (or > the > AM replacement if there is one in son-of-ike), it will at least be protected > from modification under the revised hash. > > I have seen many implementations that already send IKE responder lifetimes. > In RFC2407 when it mentioned using the cookies for the SPI that's what I > thought it was referring to (IKE not IPsec responder-lifetime). > > In the spirit of be strict in what you send and forgiving in what you'll > accept it should be noted that the receiver of IKE responder lifetimes > SHOULD accept a Notify DOI field of IPSEC (1) as well as IKE (0). > > -dave From owner-ipsec@lists.tislabs.com Fri Jul 27 10:25:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RHPWs26954; Fri, 27 Jul 2001 10:25:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13851 Fri, 27 Jul 2001 12:42:09 -0400 (EDT) From: "Geoffrey Huang" To: "Michael Thomas" , Cc: Subject: RE: I-D ACTION:draft-ietf-ipsec-ike-lifetime-00.txt Date: Fri, 27 Jul 2001 09:53:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <15201.28429.799003.22867@thomasm-u1.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Er, wouldn't the more sensible thing to do here in > general is to create a means of having a reliable > Delete notification? This is what KINK does, and > seems a lot more sensible/robust overall. I'll > note that this still seems to have the packet loss > problem described in section 3b. I don't think the issue is strictly a lost delete notification; rather, the matter is also interoperability between those implementations that bind the IKE and IPSec SAs together (otherwise known as "continuous channel mode") and those that don't. Some CCM implementations rely on pre-empting phase 1 rekeys to keep the IKE SAs up. This is only always possible if something like the Responder Lifetime message is sent -- if the RL message isn't sent, the CCM implementation won't know when its peer intends to time its IKE SAs out until it receives the delete notify. In this situation, an ACKed delete notiy won't be sufficient. -g > Mike > > Internet-Drafts@ietf.org writes: > > 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 : Responder Lifetime Notify Message for IKE > > Author(s) : S. Fanning > > Filename : draft-ietf-ipsec-ike-lifetime-00.txt > > Pages : 5 > > Date : 26-Jul-01 > > > > This document describes how the RESPONDER-LIFETIME notify message, > > used within the ISAKMP DOI can be used to facilitate lifetime > > negotiation and rekeying. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt > > 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-lifetime-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-ietf-ipsec-ike-lifetime-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. > Content-Type: text/plain > Content-ID: <20010726170632.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-ipsec-ike-lifetime-00.txt > Content-Type: text/plain > Content-ID: <20010726170632.I-D@ietf.org> From owner-ipsec@lists.tislabs.com Fri Jul 27 12:23:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6RJNPs29356; Fri, 27 Jul 2001 12:23:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA14130 Fri, 27 Jul 2001 14:30:57 -0400 (EDT) Message-ID: <002301c116af$eb7fe580$3a51a741@homero> From: =?iso-8859-1?Q?Gerardo_Ar=E9valo_Tamayo?= To: "Eric Stewart" References: <200107252214.f6PMEEo06243@phl5.note.com> Subject: Re: Freedback: Comments IPsec Expert Date: Fri, 27 Jul 2001 10:11:36 -0500 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When I started designing and deploying IPsec Expert, I was thinking on create an application that would guide step by step to planning a secure network using IPsec. But the information that I could get was about how IPsec works (the inner parts - RFC2401 - RFC2402 - RFC2406 RFC2411), and that kind of information doesn't tell me how to deploy IPsec at all. Looking at IPsec List I couldn't understand more about how to configure it. The only information that helped me was about interoperability problems (Implementing IPsec: Making security work on VPNs, Intranets, and Extranets). The idea is that I can do an application that aid to anyone who want configure or plan a secure network, but just if I can get information that tell me how do it first. I don't know if that kind of information exists, but certainly just people that have experience working on IPsec can provide the right information to form the knowledge base of the expert system. The members of IPsec List are the perfect knowledge source. Besides, everyone can take advantage with the developing of IPsec Expert due to this is an application that anyone can use, freely, and wherever part of the world. This is the opportunity to put all the knowledge that you have in one place, ready to use and with the information that you want. Thanks for your time, and I will be open to any suggestion. ----- Original Message ----- From: "Eric Stewart" To: Sent: Wednesday, July 25, 2001 5:14 PM Subject: Freedback: Comments IPsec Expert > While your application covers most of the common things to keep in mind when deploying IPSec (I really like to warnings offered in the final analysis), it would be appropriate to create a tool with some additional flexibility. In otherwords, it appears that the final analysis is somewhat canned and not entirely intuitive on the individual users unique situation. From owner-ipsec@lists.tislabs.com Fri Jul 27 18:04:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6S14os05097; Fri, 27 Jul 2001 18:04:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA14732 Fri, 27 Jul 2001 20:12:33 -0400 (EDT) Message-ID: From: "Flynn, Michael" To: "'ipsec@lists.tislabs.com'" Cc: "Thomas, Greg" Subject: IPsec Bakeoff Date: Fri, 27 Jul 2001 17:18:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To help interoperability testing VeriSign has created some accounts that you can use to obtain VeriSign certs. Some of you may have used these accounts in the past. A link to pages describing the accounts, their CAs, and how to use them is on this page http://www.verisign.com/partnernet/enterprise/tools/index.html under the blue title "IPsec Bakeoff." For help or if you find an error please send email to bakeoff-support@verisign.com. You may begin to use the accounts immediately. Michael Flynn mflynn@verisign.com 650.426.3415 From owner-ipsec@lists.tislabs.com Sun Jul 29 23:21:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6U6LAs28601; Sun, 29 Jul 2001 23:21:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17945 Mon, 30 Jul 2001 00:24:28 -0400 (EDT) Reply-To: From: "Awan Kumar" To: Subject: IPSec performance statistics Date: Mon, 30 Jul 2001 09:56:32 +0530 Message-Id: <000001c118af$d0d44440$0702060a@future.futsoft.com> MIME-Version: 1.0 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.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Can anybody provide some statistics on the percentage of change in performance (throughtput) due to the inclusion of IPsec in the IP stack. Are there any statistics available which shows the reduction in performance due to the use of DES or 3DES for ESP. Thanks in advance. Regards, Awan ---------------------------- Awan Kumar Sharma Sr. Software Engg., Future Software Ltd., Chennai, India. Ph: 4330 550 Extn: 437 (www.futsoft.com) ------------------------------ From owner-ipsec@lists.tislabs.com Mon Jul 30 00:25:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6U7PMs09095; Mon, 30 Jul 2001 00:25:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA18094 Mon, 30 Jul 2001 02:21:30 -0400 (EDT) Message-Id: <4.3.2-J.20010730123826.061f3a90@trc.mew.co.jp> X-Sender: fukuda/trc.mew.co.jp@pop3.norton.antivirus X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Mon, 30 Jul 2001 15:24:47 +0900 To: ipsec@lists.tislabs.com From: Naohiro Fukuda Subject: IPsec Bakeoff in Finland Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_15398011==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_15398011==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear IPSec Bakeoff Participant, For VPN bakeoff in Finland, I'm developing IPSec Analyzer to help the interoperability test. This is a beta version, but it should be work fine. http://210.232.73.130/downloads/ike2.1.beta.zip If you try it, please mail to 'fukuda@trc.mew.co.jp', with your MAC adresss to issue the license key. Best Regards, -Naohiro Fukuda ---------------------------------------------------------------------------------------------------------------------------- Naohiro Fukuda Matsushita Electric Works, Ltd. New Business Planning Office E-mail: fukuda@trc.mew.co.jp Homepage: http://www.nais-netcocoon.com/eng/ikeview/home/home_f.html ----------------------------------------------------------------------------------------------------------------------------- --=====================_15398011==_.ALT Content-Type: text/html; charset="us-ascii" Dear IPSec Bakeoff Participant,

For VPN bakeoff in Finland, I'm developing IPSec Analyzer to help the interoperability test.

This is a beta version, but it should be work fine.

http://210.232.73.130/downloads/ike2.1.beta.zip

If you try it, please mail to 'fukuda@trc.mew.co.jp', with your MAC adresss to issue the license key.

Best Regards,

-Naohiro Fukuda

----------------------------------------------------------------------------------------------------------------------------
Naohiro Fukuda
Matsushita Electric Works, Ltd.
New Business Planning Office
E-mail:         fukuda@trc.mew.co.jp
Homepage:       http://www.nais-netcocoon.com/eng/ikeview/home/home_f.html
-----------------------------------------------------------------------------------------------------------------------------
 --=====================_15398011==_.ALT-- From owner-ipsec@lists.tislabs.com Mon Jul 30 00:45:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6U7jMs11434; Mon, 30 Jul 2001 00:45:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA18147 Mon, 30 Jul 2001 02:54:40 -0400 (EDT) Message-Id: <4.3.2-J.20010730155756.061f3a90@trc.mew.co.jp> X-Sender: fukuda/trc.mew.co.jp@pop3.norton.antivirus X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Mon, 30 Jul 2001 15:58:01 +0900 To: ipsec@lists.tislabs.com From: Naohiro Fukuda Subject: IPsec Bakeoff in Finland Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear IPSec Bakeoff Participant, For VPN bakeoff in Finland, I'm developing IPSec Analyzer to help the interoperability test. This is a beta version, but it should be work fine. http://210.232.73.130/downloads/ike2.1.beta.zip If you try it, please mail to 'fukuda@trc.mew.co.jp', with your MAC adresss to issue the license key. Best Regards, -Naohiro Fukuda ---------------------------------------------------------------------------------------------------------------------------- Naohiro Fukuda Matsushita Electric Works, Ltd. New Business Planning Office E-mail: fukuda@trc.mew.co.jp Homepage: http://www.nais-netcocoon.com/eng/ikeview/home/home_f.html ----------------------------------------------------------------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Jul 30 02:25:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6U9PSs19242; Mon, 30 Jul 2001 02:25:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA18403 Mon, 30 Jul 2001 04:25:29 -0400 (EDT) To: Naohiro Fukuda Cc: ipsec@lists.tislabs.com In-reply-to: fukuda's message of Mon, 30 Jul 2001 15:24:47 +0900. <4.3.2-J.20010730123826.061f3a90@trc.mew.co.jp> 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: IPsec Bakeoff in Finland From: Jun-ichiro itojun Hagino Date: Mon, 30 Jul 2001 17:18:55 +0900 Message-Id: <20010730081855.2376C7BB@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Dear IPSec Bakeoff Participant, >For VPN bakeoff in Finland, I'm developing IPSec Analyzer to help the >interoperability test. >This is a beta version, but it should be work fine. >http://210.232.73.130/downloads/ike2.1.beta.zip >If you try it, please mail to 'fukuda@trc.mew.co.jp', with your MAC adresss >to issue the license key. could you talk a little bit about systems requirements? like, does it work on NetBSD? :-) itojun From owner-ipsec@lists.tislabs.com Mon Jul 30 02:46:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6U9k0s20500; Mon, 30 Jul 2001 02:46:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA18537 Mon, 30 Jul 2001 05:00:17 -0400 (EDT) Message-Id: <4.3.2-J.20010730174818.04c85d88@trc.mew.co.jp> X-Sender: fukuda/trc.mew.co.jp@pop3.norton.antivirus X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Mon, 30 Jul 2001 18:03:35 +0900 To: Jun-ichiro itojun Hagino From: Naohiro Fukuda Subject: Re: IPsec Bakeoff in Finland Cc: ipsec@lists.tislabs.com In-Reply-To: <20010730081855.2376C7BB@starfruit.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear itojun, Please look at the following page about the system requirements; http://www.nais-netcocoon.com/eng/ikeview/spec/system/system1.html That Analyzer only works on Windows 98, ME, NT, and 2000 now. NetBSD is not supported yet. #Sorry, the following page have very slow line, I'm very sorry for the inconvenient # to download. I will move the ike2.1.beta.zip to another site as soon as possible. Best Regards, At 17:18 01/07/30 +0900, you wrote: > >Dear IPSec Bakeoff Participant, > >For VPN bakeoff in Finland, I'm developing IPSec Analyzer to help the > >interoperability test. > >This is a beta version, but it should be work fine. > >http://210.232.73.130/downloads/ike2.1.beta.zip > >If you try it, please mail to 'fukuda@trc.mew.co.jp', with your MAC adresss > >to issue the license key. > > could you talk a little bit about systems requirements? like, > does it work on NetBSD? :-) > >itojun ---------------------------------------------------------------------------------------- Naohiro Fukuda Matsushita Electric Works, Ltd. Network Security Group New Business Planning Office Address: 5-13-2, Mita, Minato-ku, Tokyo 108-8351, Japan Tel: +81-3-3452-3390 Fax: +81-3-3451-0793 E-mail: fukuda@trc.mew.co.jp Homepage: http://www.netcocoon.com ---------------------------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Jul 30 06:04:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UD4Vs27840; Mon, 30 Jul 2001 06:04:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18994 Mon, 30 Jul 2001 08:04:11 -0400 (EDT) From: ryu@fujixerox.co.jp Date: Mon, 30 Jul 2001 21:10:12 +0900 (JST) Message-Id: <20010730.211012.24545741.ryu@fujixerox.co.jp> To: ipsec@lists.tislabs.com Subject: X.509 CA interoperability test on IPsec Bakeoff in Finland X-Mailer: Mew version 1.95b121 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear IPSec Bakeoff Participant, On VPN bakeoff in Finland, Fuji Xerox want to test a CA which is implemented in JAVA. Does anyone has a interest/or give a chance to test our CA's certificate fit on your IPsec product ? Thank you. Ryu Inada Fuji Xerox Co., Ltd. From owner-ipsec@lists.tislabs.com Mon Jul 30 11:18:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UIIas08900; Mon, 30 Jul 2001 11:18:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19768 Mon, 30 Jul 2001 13:02:59 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Draft Agenda for the IPSEC working group... From: tytso@mit.edu Phone: (781) 391-3464 Message-Id: Date: Mon, 30 Jul 2001 13:09:22 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The following is a draft agenda which Barbara and I put together. Comments would be appreciated before we send it into the secretariat. My apologies for the delay in preparing the agenda; this wasn't Barbara's fault, by my own --- my travel schedule has been nothing short of insane lately.... - Ted IPsec Working Group Draft Agenda Tuesday, August 6, 13:00-15:00 Agenda Bashing Nits and gnats - MIB update - IANA numbers for XAUTH and Modecfg - GSSAPI-IKE doc status - MODP D-H group definitions - AES cipher doc Son of IKE Introduction - immediate changes to IKE SCEP NAT/FW Traversal - other clarifications/mods Wednesday, August 7, 15:45-16:45 Son of IKE - draft-kaufman-ipsec-improveike-00.txt presentation by Andrew K - DPD/Keepalives/Birth-Death Certs discussion - roadmap for SOI work From owner-ipsec@lists.tislabs.com Mon Jul 30 12:38:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UJcBs10617; Mon, 30 Jul 2001 12:38:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20024 Mon, 30 Jul 2001 14:27:57 -0400 (EDT) To: Naohiro Fukuda Cc: ipsec@lists.tislabs.com In-reply-to: fukuda's message of Mon, 30 Jul 2001 15:24:47 +0900. <4.3.2-J.20010730123826.061f3a90@trc.mew.co.jp> 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: IPsec Bakeoff in Finland From: Jun-ichiro itojun Hagino Date: Mon, 30 Jul 2001 17:18:55 +0900 Message-Id: <20010730081855.2376C7BB@starfruit.itojun.org> X-OriginalArrivalTime: 30 Jul 2001 18:33:50.0843 (UTC) FILETIME=[2DA69CB0:01C11926] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Dear IPSec Bakeoff Participant, >For VPN bakeoff in Finland, I'm developing IPSec Analyzer to help the >interoperability test. >This is a beta version, but it should be work fine. >http://210.232.73.130/downloads/ike2.1.beta.zip >If you try it, please mail to 'fukuda@trc.mew.co.jp', with your MAC adresss >to issue the license key. could you talk a little bit about systems requirements? like, does it work on NetBSD? :-) itojun From owner-ipsec@lists.tislabs.com Mon Jul 30 14:36:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ULa9s12973; Mon, 30 Jul 2001 14:36:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20397 Mon, 30 Jul 2001 16:24:07 -0400 (EDT) From: ryu@fujixerox.co.jp Date: Mon, 30 Jul 2001 21:10:12 +0900 (JST) Message-Id: <20010730.211012.24545741.ryu@fujixerox.co.jp> To: ipsec@lists.tislabs.com Subject: X.509 CA interoperability test on IPsec Bakeoff in Finland X-Mailer: Mew version 1.95b121 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2001 20:29:56.0203 (UTC) FILETIME=[655433B0:01C11936] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear IPSec Bakeoff Participant, On VPN bakeoff in Finland, Fuji Xerox want to test a CA which is implemented in JAVA. Does anyone has a interest/or give a chance to test our CA's certificate fit on your IPsec product ? Thank you. Ryu Inada Fuji Xerox Co., Ltd. From owner-ipsec@lists.tislabs.com Mon Jul 30 14:37:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ULbSs13024; Mon, 30 Jul 2001 14:37:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20418 Mon, 30 Jul 2001 16:36:04 -0400 (EDT) Reply-To: From: "Awan Kumar" To: Subject: IPSec performance statistics Date: Mon, 30 Jul 2001 09:56:32 +0530 Message-Id: <000001c118af$d0d44440$0702060a@future.futsoft.com> MIME-Version: 1.0 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.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2001 20:10:16.0609 (UTC) FILETIME=[A63C7110:01C11933] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Can anybody provide some statistics on the percentage of change in performance (throughtput) due to the inclusion of IPsec in the IP stack. Are there any statistics available which shows the reduction in performance due to the use of DES or 3DES for ESP. Thanks in advance. Regards, Awan ---------------------------- Awan Kumar Sharma Sr. Software Engg., Future Software Ltd., Chennai, India. Ph: 4330 550 Extn: 437 (www.futsoft.com) ------------------------------ From owner-ipsec@lists.tislabs.com Mon Jul 30 14:43:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6ULhfs13125; Mon, 30 Jul 2001 14:43:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20450 Mon, 30 Jul 2001 16:51:07 -0400 (EDT) Message-ID: <49B96FCC784BC54F9675A6B558C3464E28570E@MAIL.NetOctave.com> From: Sadiki Mwanyoha To: ipsec@lists.tislabs.com Subject: Bakeoff PKI Date: Mon, 30 Jul 2001 16:54:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Does anyone know whether bakeoff participants will be assigned mandatory X.509 certificates/private-keys? Or can we bring/generate our own? I learned that the Versign certificates are completely optional from an interoperability standpoint. Sadiki Mwanyoha Software Engineer NetOctave, Inc. P.O. Box 14824 Research Triangle Park North Carolina 27709 919.463.9903 x306 919.463.9905 (fax) smwanyoha@netoctave.com From owner-ipsec@lists.tislabs.com Mon Jul 30 15:11:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UMBqs13547; Mon, 30 Jul 2001 15:11:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20466 Mon, 30 Jul 2001 17:01:10 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15205.52368.735204.207156@thomasm-u1.cisco.com> Date: Mon, 30 Jul 2001 14:07:28 -0700 (PDT) To: ipsec@lists.tislabs.com Subject: same SPI/different exchange 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 What is the intended behavior of IKE if you receive a proposal for a SPI which already exists? Should the old one be deinstalled and the new one installed? Mike From owner-ipsec@lists.tislabs.com Mon Jul 30 15:23:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UMN8s13796; Mon, 30 Jul 2001 15:23:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20502 Mon, 30 Jul 2001 17:24:41 -0400 (EDT) Message-Id: <200107302130.f6ULUjS23345@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: same SPI/different exchange In-reply-to: Your message of "Mon, 30 Jul 2001 14:07:28 PDT." <15205.52368.735204.207156@thomasm-u1.cisco.com> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 30 Jul 2001 17:30:44 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > What is the intended behavior of IKE if you > receive a proposal for a SPI which already exists? If this happens, the peer is probably buggy .. > Should the old one be deinstalled and the new one installed? This sounds like the robust thing to do; I'd want to be careful to ensure that the old and new instances were treated as "different" (from the point of view any caching which might be going on..) - Bill From owner-ipsec@lists.tislabs.com Mon Jul 30 15:30:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UMUEs13926; Mon, 30 Jul 2001 15:30:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20517 Mon, 30 Jul 2001 17:31:48 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15205.54202.867405.483780@thomasm-u1.cisco.com> Date: Mon, 30 Jul 2001 14:38:02 -0700 (PDT) To: sommerfeld@East.Sun.COM Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: same SPI/different exchange In-Reply-To: <200107302130.f6ULUjS23345@thunk.east.sun.com> References: <15205.52368.735204.207156@thomasm-u1.cisco.com> <200107302130.f6ULUjS23345@thunk.east.sun.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 Bill Sommerfeld writes: > > What is the intended behavior of IKE if you > > receive a proposal for a SPI which already exists? > > If this happens, the peer is probably buggy .. Really? Doesn't this happen as a natural consequence of retransmissions? > > Should the old one be deinstalled and the new one installed? > > This sounds like the robust thing to do; I'd want to be careful to > ensure that the old and new instances were treated as "different" > (from the point of view any caching which might be going on..) Right. They could change proposals, etc too. Mike From owner-ipsec@lists.tislabs.com Mon Jul 30 15:39:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6UMdbs14152; Mon, 30 Jul 2001 15:39:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20531 Mon, 30 Jul 2001 17:35:25 -0400 (EDT) Message-Id: <200107302141.f6ULfQS23512@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Thomas cc: sommerfeld@East.Sun.COM, ipsec@lists.tislabs.com Subject: Re: same SPI/different exchange In-reply-to: Your message of "Mon, 30 Jul 2001 14:38:02 PDT." <15205.54202.867405.483780@thomasm-u1.cisco.com> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 30 Jul 2001 17:41:26 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Bill Sommerfeld writes: > > > What is the intended behavior of IKE if you > > > receive a proposal for a SPI which already exists? > > > > If this happens, the peer is probably buggy .. > > Really? Doesn't this happen as a natural consequence of > retransmissions? I'd hope that replay detection would prevent that case .. > > This sounds like the robust thing to do; I'd want to be careful to > > ensure that the old and new instances were treated as "different" > > (from the point of view any caching which might be going on..) > > Right. They could change proposals, etc too. different proposals, different keys, reset sequence number space, etc., From owner-ipsec@lists.tislabs.com Mon Jul 30 20:15:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6V3Fbs18720; Mon, 30 Jul 2001 20:15:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA21143 Mon, 30 Jul 2001 22:16:13 -0400 (EDT) Message-ID: <004601c11968$24cb9720$e70310ac@cwc.nus.edu.sg> Reply-To: "Parijat Mishra" From: "Parijat Mishra" To: , References: <000001c118af$d0d44440$0702060a@future.futsoft.com> Subject: Re: IPSec performance statistics Date: Tue, 31 Jul 2001 10:25:57 +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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There will be lots of statistics, but they'll depend on the machines used, and the packet size. However, my observation is that with ESP-3DES, the time taken to process packets is almost doubled. It should be easy to run performance tests for your own setup. Parijat ----- Original Message ----- From: "Awan Kumar" To: Sent: Monday, July 30, 2001 12:26 PM Subject: IPSec performance statistics | Hi, | Can anybody provide some statistics on the percentage of change in | performance (throughtput) due to the inclusion of IPsec in the IP stack. Are | there any statistics available which shows the reduction in performance due | to the use of DES or 3DES for ESP. | | Thanks in advance. | | Regards, | Awan | | ---------------------------- | Awan Kumar Sharma | Sr. Software Engg., | Future Software Ltd., | Chennai, India. | Ph: 4330 550 Extn: 437 | (www.futsoft.com) | ------------------------------ | | From owner-ipsec@lists.tislabs.com Mon Jul 30 22:26:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6V5Q4s20867; Mon, 30 Jul 2001 22:26:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA21392 Tue, 31 Jul 2001 00:39:44 -0400 (EDT) Message-Id: <4.3.2.7.1.20010730212945.00bb2d80@golf.cpgdesign.analog.com> X-Sender: ramana@golf.cpgdesign.analog.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Jul 2001 21:42:36 -0700 To: ipsec@lists.tislabs.com From: Ramana Yarlagadda Subject: SHS type 3 test Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi This is a question about the Encryption algorithms used in the IPSec. Under the secure hash standard testing : FIPS PUB 180-1, descibes three areas of the Secure hash standard : message of verying length, selected long messages and psuedo randomly generated messages. The first two type of tests ( Messages of verying length and selected long messages) are easy to cover and i think it ocvers most of the algorithm. Then what is the significance of the SHS type3 test which more time consuming. Does it cover any kind of cases which are not covered by other type of tests? Can somebody throw soem light on this? -thanks in advancs -ramana From owner-ipsec@lists.tislabs.com Tue Jul 31 02:46:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6V9kRs18815; Tue, 31 Jul 2001 02:46:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA21792 Tue, 31 Jul 2001 04:45:26 -0400 (EDT) Reply-To: From: "Awan Kumar" To: , "'Michael Thomas'" Cc: Subject: RE: same SPI/different exchange Date: Tue, 31 Jul 2001 14:18:56 +0530 Message-Id: <000201c1199d$a3135e80$0702060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200107302141.f6ULfQS23512@thunk.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, The RFC says that the tuple has to be unique. If an SA has already been negotiated with a peer, and IKE gets a proposal from a different peer with the same SPI, there should not be any problem as the tuple is still unique. I do not think that there should be any problem in accepting the same SPI from a different peer. If the same peer sends a same proposal again, then the peer implementation is buggy. I think there should not be any problem even if a same peer proposes same SPI, but for different protocols (i.e one for AH and the other for ESP). > Bill Sommerfeld writes: > > > What is the intended behavior of IKE if you > > > receive a proposal for a SPI which already exists? > > > > If this happens, the peer is probably buggy .. > > Really? Doesn't this happen as a natural consequence of > retransmissions? >I'd hope that replay detection would prevent that case .. REPLAY DETECTION BY IKE !!! > > This sounds like the robust thing to do; I'd want to be careful to > > ensure that the old and new instances were treated as "different" > > (from the point of view any caching which might be going on..) > > Right. They could change proposals, etc too. different proposals, different keys, reset sequence number space, etc., Regards, Awan From owner-ipsec@lists.tislabs.com Tue Jul 31 04:26:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VBQ0s24418; Tue, 31 Jul 2001 04:26:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA22098 Tue, 31 Jul 2001 06:41:45 -0400 (EDT) Message-Id: <4.3.2-J.20010731175852.0476ad20@trc.mew.co.jp> X-Sender: fukuda/trc.mew.co.jp@pop3.norton.antivirus X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Tue, 31 Jul 2001 19:37:45 +0900 To: ipsec@lists.tislabs.com From: Naohiro Fukuda Subject: Re: IPsec Bakeoff in Finland In-Reply-To: <4.3.2-J.20010730155756.061f3a90@trc.mew.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear IPSec Bakeoff Participant, I moved the following download site to: http://www.nais-netcocoon.com/eng/ikeview/down_htm/update/update1.html If you like, please download the new beta version 2.1.0731 of Latest Beta Trial Version, to scroll down the page and push the download button of the bottom. Note: NOT UPPER download button on the page, but BOTTOM one. It includes the following useful functions for the interoperability test of IPSec Bakeoff in Finland. 1. Decrypt IKE, ESP, verify the AH, and ESP-Auth, with SKEYID-D, A, E. *You do not have to put Initial Vector now. If you decrypt the ID packet of IKE with known SKEYID-E, it automatically decrypts the followed IKE packets. If you put the SKEYID-D, you can automatically decrypt ESP, AH using Security->Update IPSec SA sub menu. 2. De-compress the IPComp. 3. Reassemble the IP packets. 4. Strip off the IPSec header if it were decrypted. 5. NAT traversal( latest draft ) 6. Certificate export function. * If you have X.509 Certificate data, focus it on the detail window of NetCocoon Analyzer and File->Save Data as *.cer file. You can check the Certificate Profile, critical, non-critical, with MS's Certificate Viewer. 7. Xauth, Mode Config... may be... 8. Simple Packet Generator(edit, cut, paste, copy, and replay...and so on.) 9. You can save/load the *.tsv(tab separated space file) and make your own packet sequence as your like. 10. And more Peer To Peer Viewer including filtering, TCP Session Viewer, Base64 decoder, normal text viewer... Best Regards, At 15:58 01/07/30 +0900, you wrote: >Dear IPSec Bakeoff Participant, > >For VPN bakeoff in Finland, I'm developing IPSec Analyzer to help the >interoperability test. > >This is a beta version, but it should be work fine. > >http://210.232.73.130/downloads/ike2.1.beta.zip > >If you try it, please mail to 'fukuda@trc.mew.co.jp', with your MAC >adresss to issue the license key. > >Best Regards, > >-Naohiro Fukuda > >---------------------------------------------------------------------------------------------------------------------------- >Naohiro Fukuda >Matsushita Electric Works, Ltd. >New Business Planning Office >E-mail: fukuda@trc.mew.co.jp >Homepage: http://www.nais-netcocoon.com/eng/ikeview/home/home_f.html >----------------------------------------------------------------------------------------------------------------------------- > > ---------------------------------------------------------------------------------------- Naohiro Fukuda Matsushita Electric Works, Ltd. Network Security Group New Business Planning Office Address: 5-13-2, Mita, Minato-ku, Tokyo 108-8351, Japan Tel: +81-3-3452-3390 Fax: +81-3-3451-0793 E-mail: fukuda@trc.mew.co.jp Homepage: http://www.netcocoon.com ---------------------------------------------------------------------------------------- From owner-ipsec@lists.tislabs.com Tue Jul 31 09:31:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VGVVs06984; Tue, 31 Jul 2001 09:31:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA22644 Tue, 31 Jul 2001 11:29:06 -0400 (EDT) Message-ID: <80B684C5E29FD211AA8000A0C9CDD91908FCE8DB@il0015exch005u.ih.lucent.com> From: "Kopeikin, Roy A (Roy)" To: Parijat Mishra , awank@future.futsoft.com, ipsec@lists.tislabs.com Subject: RE: IPSec performance statistics Date: Tue, 31 Jul 2001 10:31:43 -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 Correct me if I'm wrong but I think this is a non-issue for corporate VPNs since accelerator boards are typically integrated to handle the encryption and decryption functions. It is unacceptable for VPNs to degrade router/internework performance. Roy -----Original Message----- From: Parijat Mishra [mailto:mishrap@cwc.nus.edu.sg] Sent: Monday, July 30, 2001 9:26 PM To: awank@future.futsoft.com; ipsec@lists.tislabs.com Subject: Re: IPSec performance statistics There will be lots of statistics, but they'll depend on the machines used, and the packet size. However, my observation is that with ESP-3DES, the time taken to process packets is almost doubled. It should be easy to run performance tests for your own setup. Parijat ----- Original Message ----- From: "Awan Kumar" To: Sent: Monday, July 30, 2001 12:26 PM Subject: IPSec performance statistics | Hi, | Can anybody provide some statistics on the percentage of change in | performance (throughtput) due to the inclusion of IPsec in the IP stack. Are | there any statistics available which shows the reduction in performance due | to the use of DES or 3DES for ESP. | | Thanks in advance. | | Regards, | Awan | | ---------------------------- | Awan Kumar Sharma | Sr. Software Engg., | Future Software Ltd., | Chennai, India. | Ph: 4330 550 Extn: 437 | (www.futsoft.com) | ------------------------------ | | From owner-ipsec@lists.tislabs.com Tue Jul 31 09:50:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VGoss07325; Tue, 31 Jul 2001 09:50:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22697 Tue, 31 Jul 2001 12:11:36 -0400 (EDT) X-mProtect: Tue, 31 Jul 2001 09:17:58 -0700 Nokia Silicon Valley Messaging Protection Message-ID: <3B66789F.1065396@iprg.nokia.com> Date: Tue, 31 Jul 2001 09:21:35 +0000 From: Marc Solsona-Palomar X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Kopeikin, Roy A (Roy)" CC: Parijat Mishra , awank@future.futsoft.com, ipsec@lists.tislabs.com Subject: Re: IPSec performance statistics References: <80B684C5E29FD211AA8000A0C9CDD91908FCE8DB@il0015exch005u.ih.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPsec processing implies an overhead. Even the fact to send the packet somewhere else (like to an accelerator card) means cycles lost. What an accelerator will provide is more unified results across different algorithms as the chips have been optimized for this type of processing. marc "Kopeikin, Roy A (Roy)" wrote: > Correct me if I'm wrong but I think this is a non-issue for corporate VPNs > since accelerator boards are typically integrated to handle the encryption > and decryption functions. It is unacceptable for VPNs to degrade > router/internework performance. > Roy > > -----Original Message----- > From: Parijat Mishra [mailto:mishrap@cwc.nus.edu.sg] > Sent: Monday, July 30, 2001 9:26 PM > To: awank@future.futsoft.com; ipsec@lists.tislabs.com > Subject: Re: IPSec performance statistics > > There will be lots of statistics, but they'll depend on the machines > used, and the packet size. However, my observation is that with > ESP-3DES, the time taken to process packets is almost doubled. > > It should be easy to run performance tests for your own setup. > > Parijat > ----- Original Message ----- > From: "Awan Kumar" > To: > Sent: Monday, July 30, 2001 12:26 PM > Subject: IPSec performance statistics > > | Hi, > | Can anybody provide some statistics on the percentage of change in > | performance (throughtput) due to the inclusion of IPsec in the IP > stack. Are > | there any statistics available which shows the reduction in > performance due > | to the use of DES or 3DES for ESP. > | > | Thanks in advance. > | > | Regards, > | Awan > | > | ---------------------------- > | Awan Kumar Sharma > | Sr. Software Engg., > | Future Software Ltd., > | Chennai, India. > | Ph: 4330 550 Extn: 437 > | (www.futsoft.com) > | ------------------------------ > | > | From owner-ipsec@lists.tislabs.com Tue Jul 31 09:58:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VGwIs07547; Tue, 31 Jul 2001 09:58:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22718 Tue, 31 Jul 2001 12:19:21 -0400 (EDT) Message-ID: <80B684C5E29FD211AA8000A0C9CDD91908FCE967@il0015exch005u.ih.lucent.com> From: "Kopeikin, Roy A (Roy)" To: Marc Solsona-Palomar Cc: Parijat Mishra , awank@future.futsoft.com, ipsec@lists.tislabs.com Subject: RE: IPSec performance statistics Date: Tue, 31 Jul 2001 11:26:04 -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 Marc, Do you think these cycles lost can bd quantified into performanc statistics? roy -----Original Message----- From: Marc Solsona-Palomar [mailto:marc@iprg.nokia.com] Sent: Tuesday, July 31, 2001 4:22 AM To: Kopeikin, Roy A (Roy) Cc: Parijat Mishra; awank@future.futsoft.com; ipsec@lists.tislabs.com Subject: Re: IPSec performance statistics IPsec processing implies an overhead. Even the fact to send the packet somewhere else (like to an accelerator card) means cycles lost. What an accelerator will provide is more unified results across different algorithms as the chips have been optimized for this type of processing. marc "Kopeikin, Roy A (Roy)" wrote: > Correct me if I'm wrong but I think this is a non-issue for corporate VPNs > since accelerator boards are typically integrated to handle the encryption > and decryption functions. It is unacceptable for VPNs to degrade > router/internework performance. > Roy > > -----Original Message----- > From: Parijat Mishra [mailto:mishrap@cwc.nus.edu.sg] > Sent: Monday, July 30, 2001 9:26 PM > To: awank@future.futsoft.com; ipsec@lists.tislabs.com > Subject: Re: IPSec performance statistics > > There will be lots of statistics, but they'll depend on the machines > used, and the packet size. However, my observation is that with > ESP-3DES, the time taken to process packets is almost doubled. > > It should be easy to run performance tests for your own setup. > > Parijat > ----- Original Message ----- > From: "Awan Kumar" > To: > Sent: Monday, July 30, 2001 12:26 PM > Subject: IPSec performance statistics > > | Hi, > | Can anybody provide some statistics on the percentage of change in > | performance (throughtput) due to the inclusion of IPsec in the IP > stack. Are > | there any statistics available which shows the reduction in > performance due > | to the use of DES or 3DES for ESP. > | > | Thanks in advance. > | > | Regards, > | Awan > | > | ---------------------------- > | Awan Kumar Sharma > | Sr. Software Engg., > | Future Software Ltd., > | Chennai, India. > | Ph: 4330 550 Extn: 437 > | (www.futsoft.com) > | ------------------------------ > | > | From owner-ipsec@lists.tislabs.com Tue Jul 31 10:55:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VHtOs08863; Tue, 31 Jul 2001 10:55:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22870 Tue, 31 Jul 2001 13:12:38 -0400 (EDT) Message-ID: <9D048F4A422CD411A56500B0D0209C5B028F3607@NS-CA> From: Michael Choung Shieh To: "'Kopeikin, Roy A (Roy)'" , Marc Solsona-Palomar Cc: Parijat Mishra , awank@future.futsoft.com, ipsec@lists.tislabs.com Subject: RE: IPSec performance statistics Date: Tue, 31 Jul 2001 10:18:18 -0700 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 The performance lost of ipsec processing depends on the architecture of the design and the size of packets. Some vendors can achieve wire-speed while the others only improve a little even with hardware acceleration. It's also easier to boost the performance for large size packets(1500bytes) than small size (64bytes). Hardware accelaration does reduce the difference of processing time between encryption algorithms. The differences between DES and 3DES processing may be less than 10%. I would say the performance really depends on the gateway you used. There are many reports and comparisons out there. -------------------------------------------- Michael Shieh NetScreen Technologies, Inc 350 Oakmead Parkway Sunnyvale, CA 94085 TEL: (408)730-6060 FAX: (408)730-6050 Email: mshieh@netscreen.com -------------------------------------------- -----Original Message----- From: Kopeikin, Roy A (Roy) [mailto:rkopeikin@lucent.com] Sent: Tuesday, July 31, 2001 9:26 AM To: Marc Solsona-Palomar Cc: Parijat Mishra; awank@future.futsoft.com; ipsec@lists.tislabs.com Subject: RE: IPSec performance statistics Marc, Do you think these cycles lost can bd quantified into performanc statistics? roy -----Original Message----- From: Marc Solsona-Palomar [mailto:marc@iprg.nokia.com] Sent: Tuesday, July 31, 2001 4:22 AM To: Kopeikin, Roy A (Roy) Cc: Parijat Mishra; awank@future.futsoft.com; ipsec@lists.tislabs.com Subject: Re: IPSec performance statistics IPsec processing implies an overhead. Even the fact to send the packet somewhere else (like to an accelerator card) means cycles lost. What an accelerator will provide is more unified results across different algorithms as the chips have been optimized for this type of processing. marc "Kopeikin, Roy A (Roy)" wrote: > Correct me if I'm wrong but I think this is a non-issue for corporate VPNs > since accelerator boards are typically integrated to handle the encryption > and decryption functions. It is unacceptable for VPNs to degrade > router/internework performance. > Roy > > -----Original Message----- > From: Parijat Mishra [mailto:mishrap@cwc.nus.edu.sg] > Sent: Monday, July 30, 2001 9:26 PM > To: awank@future.futsoft.com; ipsec@lists.tislabs.com > Subject: Re: IPSec performance statistics > > There will be lots of statistics, but they'll depend on the machines > used, and the packet size. However, my observation is that with > ESP-3DES, the time taken to process packets is almost doubled. > > It should be easy to run performance tests for your own setup. > > Parijat > ----- Original Message ----- > From: "Awan Kumar" > To: > Sent: Monday, July 30, 2001 12:26 PM > Subject: IPSec performance statistics > > | Hi, > | Can anybody provide some statistics on the percentage of change in > | performance (throughtput) due to the inclusion of IPsec in the IP > stack. Are > | there any statistics available which shows the reduction in > performance due > | to the use of DES or 3DES for ESP. > | > | Thanks in advance. > | > | Regards, > | Awan > | > | ---------------------------- > | Awan Kumar Sharma > | Sr. Software Engg., > | Future Software Ltd., > | Chennai, India. > | Ph: 4330 550 Extn: 437 > | (www.futsoft.com) > | ------------------------------ > | > | From owner-ipsec@lists.tislabs.com Tue Jul 31 10:55:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VHtTs08875; Tue, 31 Jul 2001 10:55:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA22878 Tue, 31 Jul 2001 13:16:00 -0400 (EDT) X-Delivered-For: X-mProtect: Tue, 31 Jul 2001 10:22:25 -0700 Nokia Silicon Valley Messaging Protection Message-ID: <3B6687BA.C00FF3A1@iprg.nokia.com> Date: Tue, 31 Jul 2001 10:26:02 +0000 From: Marc Solsona-Palomar X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "ipsec@lists.tislabs.com" Subject: Re: IPSec performance statistics Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't have any numbers available but from the top of my head I can see three elements that will determine the accelerator overhead: - Compiler - System architecture - Memory access implementation. I understand that some of these elements can be minimized but that will be the case of a typical accelerator. I believe all those could be quantified. There is a lot more to be done when IPsec is in place that just route the packet, and keeping up with wire speed becomes a bigger challenge. I agree that the goal is to provide wirespeed for secure connections and I think everybody is working on it. Right? marc. "Kopeikin, Roy A (Roy)" wrote: > Marc, > Do you think these cycles lost can bd quantified into performanc statistics? > roy > > -----Original Message----- > From: Marc Solsona-Palomar [mailto:marc@iprg.nokia.com] > Sent: Tuesday, July 31, 2001 4:22 AM > To: Kopeikin, Roy A (Roy) > Cc: Parijat Mishra; awank@future.futsoft.com; ipsec@lists.tislabs.com > Subject: Re: IPSec performance statistics > > IPsec processing implies an overhead. Even the fact to send the packet > somewhere else (like to an accelerator card) means cycles lost. What an > accelerator will provide is more unified results across different algorithms > as the chips have been optimized for this type of processing. > > marc > > "Kopeikin, Roy A (Roy)" wrote: > > > Correct me if I'm wrong but I think this is a non-issue for corporate VPNs > > since accelerator boards are typically integrated to handle the encryption > > and decryption functions. It is unacceptable for VPNs to degrade > > router/internework performance. > > Roy > > > > -----Original Message----- > > From: Parijat Mishra [mailto:mishrap@cwc.nus.edu.sg] > > Sent: Monday, July 30, 2001 9:26 PM > > To: awank@future.futsoft.com; ipsec@lists.tislabs.com > > Subject: Re: IPSec performance statistics > > > > There will be lots of statistics, but they'll depend on the machines > > used, and the packet size. However, my observation is that with > > ESP-3DES, the time taken to process packets is almost doubled. > > > > It should be easy to run performance tests for your own setup. > > > > Parijat > > ----- Original Message ----- > > From: "Awan Kumar" > > To: > > Sent: Monday, July 30, 2001 12:26 PM > > Subject: IPSec performance statistics > > > > | Hi, > > | Can anybody provide some statistics on the percentage of change in > > | performance (throughtput) due to the inclusion of IPsec in the IP > > stack. Are > > | there any statistics available which shows the reduction in > > performance due > > | to the use of DES or 3DES for ESP. > > | > > | Thanks in advance. > > | > > | Regards, > > | Awan > > | > > | ---------------------------- > > | Awan Kumar Sharma > > | Sr. Software Engg., > > | Future Software Ltd., > > | Chennai, India. > > | Ph: 4330 550 Extn: 437 > > | (www.futsoft.com) > > | ------------------------------ > > | > > | From owner-ipsec@lists.tislabs.com Tue Jul 31 12:30:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f6VJUqs10791; Tue, 31 Jul 2001 12:30:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA23081 Tue, 31 Jul 2001 14:42:35 -0400 (EDT) Message-Id: <5.0.2.1.2.20010731124944.04073690@128.230.92.5> X-Sender: mfratto@128.230.92.5 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 31 Jul 2001 13:01:13 -0400 To: "Kopeikin, Roy A (Roy)" , Parijat Mishra , awank@future.futsoft.com, ipsec@lists.tislabs.com From: Mike Fratto Subject: RE: IPSec performance statistics In-Reply-To: <80B684C5E29FD211AA8000A0C9CDD91908FCE8DB@il0015exch005u.ih .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My once every three year post begins: Depends on what kind of performance statistics you are looking for: raw througput, pps, or latency. And and what packet size. In general, IPsec VPN using tunnel mode ESP, 3DES, HMAC-MD5: 1) will degrade performance over non-VPN traffic. How much is quantifiable. At larger packet sizes, software only crypto will get you about 6-10 Mb/s. Accelerated VPN (using an accelerator card in a general purpose computer) will boost you to about 30 Mb/s. Optimized hardware and software can get you over 100 Mb/s full duplex. 2) processing larger packet sizes tends to be more efficient and thus provide increased performance. 3) smaller packet sizes tends to decrease performance. Using DES doesn't help much. There have been several performance reviews published over the last several years. For more detailed information, read the test bed scenario and if you have specific questions about the testing, contact the author for details. mike At 10:31 AM 7/31/2001 -0500, Kopeikin, Roy A (Roy) wrote: >Correct me if I'm wrong but I think this is a non-issue for corporate VPNs >since accelerator boards are typically integrated to handle the encryption >and decryption functions. It is unacceptable for VPNs to degrade >router/internework performance. >Roy > >-----Original Message----- >From: Parijat Mishra [mailto:mishrap@cwc.nus.edu.sg] >Sent: Monday, July 30, 2001 9:26 PM >To: awank@future.futsoft.com; ipsec@lists.tislabs.com >Subject: Re: IPSec performance statistics > > >There will be lots of statistics, but they'll depend on the machines >used, and the packet size. However, my observation is that with >ESP-3DES, the time taken to process packets is almost doubled. > >It should be easy to run performance tests for your own setup. > >Parijat >----- Original Message ----- >From: "Awan Kumar" >To: >Sent: Monday, July 30, 2001 12:26 PM >Subject: IPSec performance statistics > > >| Hi, >| Can anybody provide some statistics on the percentage of change in >| performance (throughtput) due to the inclusion of IPsec in the IP >stack. Are >| there any statistics available which shows the reduction in >performance due >| to the use of DES or 3DES for ESP. >| >| Thanks in advance. >| >| Regards, >| Awan >| >| ---------------------------- >| Awan Kumar Sharma >| Sr. Software Engg., >| Future Software Ltd., >| Chennai, India. >| Ph: 4330 550 Extn: 437 >| (www.futsoft.com) >| ------------------------------ >| >| ___________________ Mike Fratto Senior Technology Editor Network Computing 001 Machinery Hall Syracuse University Syracuse, NY 13244 ___________________ From owner-ipsec@lists.tislabs.com Tue Jul 31 19:13:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f712Dws17370; Tue, 31 Jul 2001 19:13:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA23689 Tue, 31 Jul 2001 21:07:28 -0400 (EDT) Message-ID: <004f01c11a27$c5f50360$e70310ac@cwc.nus.edu.sg> Reply-To: "Parijat Mishra" From: "Parijat Mishra" To: References: Subject: Re: [Design] A hardware acceleration project for FreeS/WAN Date: Wed, 1 Aug 2001 09:17: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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Linux has a `channel bonding' patch, IIRC. Would that not do the trick for even `client' models of the NIC? Admittedly, my info about that patch is a bit old. Perhaps it does not work on modern kernels. Parijat ----- Original Message ----- From: "Trumper, Fabian" To: "Sandy Harris" ; Sent: Wednesday, August 01, 2001 6:16 AM Subject: RE: [Design] A hardware acceleration project for FreeS/WAN | Both server and client models are supported. The only difference between | them is that with the server model one can build a 'team', which is an | aggregation of adapters to make them look like a single virtual device to | the OS. Also note that some models support only DES and not 3DES. | I am still working towards making this work available for public download, | but it may take a couple of months resolve the internal issues. Sorry. I | will inform this forum of any progress. | Fabi | | -----Original Message----- | From: Sandy Harris [mailto:sandy@storm.ca] | Sent: Tue, July 31, 2001 10:51 PM | To: design@lists.freeswan.org | Subject: Re: [Design] A hardware acceleration project for FreeS/WAN | Importance: High | | | Fabian Trumper wrote: | | > I'd like to introduce myself to this forum - my name is Fabian Trumper, I | live | > in Israel and work for Intel's Communication Group. My team is responsible | for | > the development of the Intel e100 Ethernet NIC driver. | > | > I wanted to take advantage of the Pro/100s (which has crypto acceleration | > functionality ) for IPsec acceleration in Linux so ... | | Anyone in Ottawa who'd like to play with Fabian's code, I was just at | Northern Micro on Colonnade Road and they have a half dozen Pro/100S | boards on the shelf at $75 each. | | Some are labelled as the 'server model', others not. Fabian: what's the | difference? | | They also have several Intel PCMCIA adapters with the crypto accleration | chips at $95. Fabian: does your code support these? | _______________________________________________ | Design mailing list | Design@lists.freeswan.org | http://lists.freeswan.org/mailman/listinfo/design | _______________________________________________ | Design mailing list | Design@lists.freeswan.org | http://lists.freeswan.org/mailman/listinfo/design |