From owner-ipsec@lists.tislabs.com Tue Aug 1 03:03:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA10564; Tue, 1 Aug 2000 03:03:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA18438 Tue, 1 Aug 2000 04:10:11 -0400 (EDT) Reply-To: From: "Moti Frances" To: "'Kavsan, Bronislav'" , Cc: "Nitsan Baider (E-mail)" , "Tamir Zegman (E-mail)" Subject: RE: VPN Bakeoff question Date: Tue, 1 Aug 2000 11:20:22 +0200 Message-ID: <003701bffb99$b8260250$2c8d96d4@checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Slava & all, Yes, we'd be glad to do hybrid with S-ID tests in the coming bakeoff. Moti Frances Encryption Group, R&D Check Point Software Technologies Ltd. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kavsan, Bronislav > Sent: Sunday, July 30, 2000 5:19 PM > To: ipsec@lists.tislabs.com > Subject: VPN Bakeoff question > > > Is anyone interested in testing XAUTH, Hybrid Auth or CRACK > using SecurID > tokens at the September bakeoff? > > If there is enough interest - RSA Security will set up > integrated ACE/RADIUS > server there and configure/distribute SecurID tokens to the > participants of > the bakeoff. > > Thank you, > > Slava Kavsan > RSA Security Inc. > > From owner-ipsec@lists.tislabs.com Tue Aug 1 03:26:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14281; Tue, 1 Aug 2000 03:26:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA18628 Tue, 1 Aug 2000 05:00:45 -0400 (EDT) Reply-To: From: "Moti Frances" To: "'Kavsan, Bronislav'" Cc: Subject: RE: VPN Bakeoff question Date: Tue, 1 Aug 2000 12:10:47 +0200 Message-ID: <005101bffba0$c365c8b0$2c8d96d4@checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Slave & all, We'd be glad to test Hybrid with S-ID tokens, both client & server. Moti Frances, Encryption Group, R&D Check Point Software Technologies > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kavsan, Bronislav > Sent: Sunday, July 30, 2000 5:19 PM > To: ipsec@lists.tislabs.com > Subject: VPN Bakeoff question > > > Is anyone interested in testing XAUTH, Hybrid Auth or CRACK > using SecurID > tokens at the September bakeoff? > > If there is enough interest - RSA Security will set up > integrated ACE/RADIUS > server there and configure/distribute SecurID tokens to the > participants of > the bakeoff. > > Thank you, > > Slava Kavsan > RSA Security Inc. > From owner-ipsec@lists.tislabs.com Tue Aug 1 07:59:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03244; Tue, 1 Aug 2000 07:59:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19352 Tue, 1 Aug 2000 09:12:14 -0400 (EDT) Message-Id: <200007312319.QAA14257@mailman.cisco.com> X-Sender: anfreema@sj-email X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Sun, 30 Jul 2000 16:18:13 -0700 To: l2tp@ipsec.org, ietf-ppp@merit.edu, ipsec@lists.tislabs.com From: Anita Freeman Subject: Update for Sept 2000 VPN Interoperability Workshop Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_18187235==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_18187235==_.ALT Content-Type: text/plain; charset="us-ascii" First a reminder to make your hotel reservations for the VPN Interoperability Workshop, September 18-22, 2000 at the Paradise Point Resort in San Diego, California. The reservation number is 800-344-2626. Please register under the VPN Workshop room block for the discounted rate of $159 per night (plus tax). The cutoff date for this room block is August 15th. There are a few modifications to the application and schedule for the September 2000 VPN Workshop. The application for the workshop has been moved to a new server and is now available at: http://209.249.66.84/vpnworkshop/ On Tuesday evening, September 19, 2000, the California Broadband User's Group will sponsor an appreciation event for the workshop attendees. At 7 PM we will board a Sternwheeler, the William D. Evans, at the Bahia Resort Hotel for a two hour cocktail cruise in San Diego's Mission Bay. The cruise will replace the reception originally scheduled for September 20, 2000. The VPN Workshop is being sponsored by VeriSign, SSH, Hi/fn, WindRiver, Entrust, Nokia, Alcatel, RedBack, Microsoft, Cisco, and UUNET, a Worldcom Company. The protocols being tested at this workshop are: IPsec IKE IPComp L2TP over Transport-Mode IPsec PPTP PPPoE PPPoATM L2TPoATM Thanks, Anita Freeman --=====================_18187235==_.ALT Content-Type: text/html; charset="us-ascii" First a reminder to make your hotel reservations for the VPN Interoperability Workshop, September 18-22, 2000 at the Paradise Point Resort in San Diego, California. The reservation number is 800-344-2626. Please register under the VPN Workshop room block for the discounted rate of $159 per night (plus tax). The cutoff date for this room block is August 15th. There are a few modifications to the application and schedule for the September 2000 VPN Workshop. The application for the workshop has been moved to a new server and is now available at: http://209.249.66.84/vpnworkshop/ On Tuesday evening, September 19, 2000, the California Broadband User's Group will sponsor an appreciation event for the workshop attendees. At 7 PM we will board a Sternwheeler, the William D. Evans, at the Bahia Resort Hotel for a two hour cocktail cruise in San Diego's Mission Bay. The cruise will replace the reception originally scheduled for September 20, 2000. The VPN Workshop is being sponsored by VeriSign, SSH, Hi/fn, WindRiver, Entrust, Nokia, Alcatel, RedBack, Microsoft, Cisco, and UUNET, a Worldcom Company. The protocols being tested at this workshop are: IPsec IKE IPComp L2TP over Transport-Mode IPsec PPTP PPPoE PPPoATM L2TPoATM Thanks, Anita Freeman --=====================_18187235==_.ALT-- From owner-ipsec@lists.tislabs.com Tue Aug 1 08:49:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09454; Tue, 1 Aug 2000 08:49:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19554 Tue, 1 Aug 2000 10:33:53 -0400 (EDT) Message-Id: <4.2.2.20000801074015.00bc1890@localhost> X-Sender: cmadson@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 01 Aug 2000 07:44:10 -0700 To: guttman@mitre.org (Joshua D. Guttman) From: Cheryl Madson Subject: Re: Cisco "dynamic-map"s Cc: ipsec@lists.tislabs.com, guttman@mitre.org (Joshua D. Guttman), "Grant M. Wagner" , fnc@mitre.org (Chase, Frederick N.), althomas@mitre.org (Herzog, Amy L.), bede@mitre.org (McCall, Bede B.) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:05 PM 7/28/00 , Joshua D. Guttman wrote: >I'd be grateful for information about a particular aspect of Cisco's >implementation. This mailing list isn't the best one for such questions. You should be able to contact the Cisco Technical Assistance Center and/or your local SE to get help. - C =============================================== Cheryl Madson Strategic Cryptographic Development; Systems & Solutions Engineering Cisco Systems, Inc. cmadson@cisco.com From owner-ipsec@lists.tislabs.com Tue Aug 1 10:31:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12690; Tue, 1 Aug 2000 10:31:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19898 Tue, 1 Aug 2000 12:13:40 -0400 (EDT) Message-ID: <023b01bffbd5$01d16850$cd0100c0@FABIO> From: =?iso-8859-1?Q?F=E1bio_Santana_Bispo?= To: , , , "Anita Freeman" References: <200007312319.QAA14257@mailman.cisco.com> Subject: Re: Update for Sept 2000 VPN Interoperability Workshop Date: Tue, 1 Aug 2000 13:24:46 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0238_01BFFBBB.DC6ED390" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0238_01BFFBBB.DC6ED390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I will make a work about VPN and maybe implement one. I want to know = the best book about VPN and sites that talk about it. Thanks F=E1bio ----- Original Message -----=20 From: Anita Freeman=20 To: l2tp@ipsec.org ; ietf-ppp@merit.edu ; ipsec@lists.tislabs.com=20 Sent: Sunday, July 30, 2000 8:18 PM Subject: Update for Sept 2000 VPN Interoperability Workshop First a reminder to make your hotel reservations for the VPN = Interoperability Workshop, September 18-22, 2000 at the Paradise Point = Resort in San Diego, California. The reservation number is 800-344-2626. = Please register under the VPN Workshop room block for the discounted = rate of $159 per night (plus tax). The cutoff date for this room block = is August 15th. There are a few modifications to the application and = schedule for the September 2000 VPN Workshop. The application for the = workshop has been moved to a new server and is now available at: = http://209.249.66.84/vpnworkshop/ On Tuesday evening, September 19, = 2000, the California Broadband User's Group will sponsor an appreciation = event for the workshop attendees. At 7 PM we will board a Sternwheeler, = the William D. Evans, at the Bahia Resort Hotel for a two hour cocktail = cruise in San Diego's Mission Bay. The cruise will replace the reception = originally scheduled for September 20, 2000. The VPN Workshop is being = sponsored by VeriSign, SSH, Hi/fn, WindRiver, Entrust, Nokia, Alcatel, = RedBack, Microsoft, Cisco, and UUNET, a Worldcom Company. The protocols = being tested at this workshop are: IPsec IKE IPComp L2TP over = Transport-Mode IPsec PPTP PPPoE PPPoATM L2TPoATM Thanks, Anita Freeman=20 ------=_NextPart_000_0238_01BFFBBB.DC6ED390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
    I will make a work = about VPN and=20 maybe implement one. I want to know the best book about VPN and sites = that talk=20 about it.
 
Thanks
 
F=E1bio
----- Original Message -----
From:=20 Anita = Freeman=20
To: l2tp@ipsec.org ; ietf-ppp@merit.edu ; ipsec@lists.tislabs.com
Sent: Sunday, July 30, 2000 = 8:18 PM
Subject: Update for Sept 2000 = VPN=20 Interoperability Workshop

First a reminder to make your hotel reservations for = the VPN=20 Interoperability Workshop, September 18-22, 2000 at the Paradise Point = Resort=20 in San Diego, California. The reservation number is 800-344-2626. = Please=20 register under the VPN Workshop room block for the discounted rate of = $159 per=20 night (plus tax). The cutoff date for this room block is August 15th. = There=20 are a few modifications to the application and schedule for the = September 2000=20 VPN Workshop. The application for the workshop has been moved to a new = server=20 and is now available at: http://209.249.66.84/vpnworkshop/ On Tuesday = evening,=20 September 19, 2000, the California Broadband User's Group will sponsor = an=20 appreciation event for the workshop attendees. At 7 PM we will board a = Sternwheeler, the William D. Evans, at the Bahia Resort Hotel for a = two hour=20 cocktail cruise in San Diego's Mission Bay. The cruise will replace = the=20 reception originally scheduled for September 20, 2000. The VPN = Workshop is=20 being sponsored by VeriSign, SSH, Hi/fn, WindRiver, Entrust, Nokia, = Alcatel,=20 RedBack, Microsoft, Cisco, and UUNET, a Worldcom Company. The = protocols being=20 tested at this workshop are: IPsec IKE IPComp L2TP over Transport-Mode = IPsec=20 PPTP PPPoE PPPoATM L2TPoATM Thanks, Anita Freeman = ------=_NextPart_000_0238_01BFFBBB.DC6ED390-- From owner-ipsec@lists.tislabs.com Tue Aug 1 10:31:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12699; Tue, 1 Aug 2000 10:31:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19914 Tue, 1 Aug 2000 12:16:24 -0400 (EDT) Message-ID: <517244DCC735D411A9BF00E029309B37015AA8@sanjose.broadpac.com> From: Ruchir Malhotra To: "Ipsec (E-mail)" Subject: IPSEC and ISAKMP MIBs Date: Tue, 1 Aug 2000 09:23:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, What are the latest drafts and/or RFCs on IPSEC and ISAKMP CONFIGURATION MIBs (not monitoring MIBs) ? Regards Ruchir From owner-ipsec@lists.tislabs.com Tue Aug 1 10:32:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12744; Tue, 1 Aug 2000 10:32:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19973 Tue, 1 Aug 2000 12:31:51 -0400 (EDT) Date: Tue, 1 Aug 2000 13:41:16 -0300 (ADT) From: ANDREW ARRON LITTLE X-Sender: little@borg To: ipsec-list Subject: IPSec Performance Tests In-Reply-To: <397EE19F.5AE38323@F-Secure.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello: I am looking for some resources for IPSec performance testing/analysis. If anyone knows of any information on this topic could you please let me know. Andrew From owner-ipsec@lists.tislabs.com Tue Aug 1 10:43:49 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12879; Tue, 1 Aug 2000 10:43:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19999 Tue, 1 Aug 2000 12:35:03 -0400 (EDT) Message-ID: <5F235E8F67EAD311993200D0B708A6D809CF1F@email.rapidstream.com> From: leemay yen To: "'Kavsan, Bronislav'" , ipsec@lists.tislabs.com Subject: RE: VPN Bakeoff question Date: Tue, 1 Aug 2000 09:43:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Slava: Yes, we would like to test XAuth with Radius/SecuredID. Then, just wonder if we also have a chance to test Radius/CHAP ? Plus, is there any vendor to support IKE/CONF with or w/o Radius ? Would like to know how to interoperate with your implementation ? Thanks in advance for your info. Leemay Yen RapidStream, Inc. -----Original Message----- From: Kavsan, Bronislav [mailto:bkavsan@rsasecurity.com] Sent: Sunday, July 30, 2000 8:19 AM To: ipsec@lists.tislabs.com Subject: VPN Bakeoff question Is anyone interested in testing XAUTH, Hybrid Auth or CRACK using SecurID tokens at the September bakeoff? If there is enough interest - RSA Security will set up integrated ACE/RADIUS server there and configure/distribute SecurID tokens to the participants of the bakeoff. Thank you, Slava Kavsan RSA Security Inc. From owner-ipsec@lists.tislabs.com Tue Aug 1 11:03:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13246; Tue, 1 Aug 2000 11:03:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20102 Tue, 1 Aug 2000 13:05:17 -0400 (EDT) Message-ID: <398705A4.59860CEA@redcreek.com> Date: Tue, 01 Aug 2000 10:15:16 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruchir Malhotra CC: "Ipsec (E-mail)" Subject: Re: IPSEC and ISAKMP MIBs References: <517244DCC735D411A9BF00E029309B37015AA8@sanjose.broadpac.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ruchir Malhotra wrote: > > Hi, > What are the latest drafts and/or RFCs on IPSEC and ISAKMP CONFIGURATION > MIBs (not monitoring MIBs) ? > > Regards > Ruchir The only currently active ipsec mibs are for monitoring only. I know of no configuration mibs that have been written up. Scott From owner-ipsec@lists.tislabs.com Tue Aug 1 11:05:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13284; Tue, 1 Aug 2000 11:05:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20066 Tue, 1 Aug 2000 12:53:30 -0400 (EDT) Date: Tue, 1 Aug 2000 13:03:31 -0400 From: Jim Tiller X-Mailer: The Bat! (v1.44) Reply-To: "Jim Tiller, CISSP" Organization: Belenos, Inc. X-Priority: 3 (Normal) Message-ID: <9079792064.20000801130331@belenosinc.com> To: Ari Huttunen CC: ipsec-list Subject: Re: Comments regarding IPsec NAT traversal / new proposal In-reply-To: <397EE19F.5AE38323@F-Secure.com> References: <397EE19F.5AE38323@F-Secure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk AH> ASSUMPTION: We do *not* wish to use the same UDP port for both IKE and AH> IPsec traffic encapsulated in UDP. This is because we'd loose the possibility AH> to filter these traffic types separately in a firewall. For this purpose we've AH> reserved the port 2797 from IANA. This should be a default with an option to modify at the remote system/initiator. The reasoning is that port 2797 may not be typically open in foreign networks, in that event the initiator can request to establish the session over a common port (i.e. 53) that is typically open on firewalls. AH> In particular, the method of negotiating and setting up UDP encapsulation as AH> defined in draft-stenberg-ipsec-nat-traversal-00.txt is too complex. We propose the following AH> mechanism for discussion: AH> 1) IKE phase 1 is not modified. AH> 2) IKE phase 2 adds a new protocol ID, AH> Protocol ID Value AH> ----------- ----- AH> RESERVED 0 AH> PROTO_ISAKMP 1 AH> PROTO_IPSEC_AH 2 AH> PROTO_IPSEC_ESP 3 AH> PROTO_IPCOMP 4 AH> PROTO_IPSEC_ESP_OVER_UDP X Agreed - however, your assuming IKE will survive NAT. Will this affect the available authentication mechanisms? -jim From owner-ipsec@lists.tislabs.com Tue Aug 1 12:00:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14515; Tue, 1 Aug 2000 12:00:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20215 Tue, 1 Aug 2000 13:39:04 -0400 (EDT) Message-ID: From: "Kavsan, Bronislav" To: "'leemay yen'" , ipsec@lists.tislabs.com Subject: RE: VPN Bakeoff question Date: Tue, 1 Aug 2000 13:48:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Leemay, We will set up an integrated ACE/RADIUS server and configure it to provide both SecurID token-based and password-based authentication service. There will be a process of enrolling users on this server and providing them with SecurID tokens. Slava > -----Original Message----- > From: leemay yen [mailto:leemay_yen@rapidstream.com] > Sent: Tuesday, August 01, 2000 12:44 PM > To: Kavsan, Bronislav; ipsec@lists.tislabs.com > Subject: RE: VPN Bakeoff question > > > Hi, Slava: > > Yes, we would like to test XAuth with Radius/SecuredID. > Then, just wonder if we also have a chance to > test Radius/CHAP ? > > Plus, is there any vendor to support IKE/CONF with or w/o Radius ? > Would like to know how to interoperate with your implementation ? > > Thanks in advance for your info. > > Leemay Yen > RapidStream, Inc. > > -----Original Message----- > From: Kavsan, Bronislav [mailto:bkavsan@rsasecurity.com] > Sent: Sunday, July 30, 2000 8:19 AM > To: ipsec@lists.tislabs.com > Subject: VPN Bakeoff question > > > Is anyone interested in testing XAUTH, Hybrid Auth or CRACK > using SecurID > tokens at the September bakeoff? > > If there is enough interest - RSA Security will set up > integrated ACE/RADIUS > server there and configure/distribute SecurID tokens to the > participants of > the bakeoff. > > Thank you, > > Slava Kavsan > RSA Security Inc. > From owner-ipsec@lists.tislabs.com Tue Aug 1 13:24:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16413; Tue, 1 Aug 2000 13:24:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20790 Tue, 1 Aug 2000 14:55:53 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B003695028@hdsmsx31.hd.intel.com> From: "Shriver, John" To: "'Ruchir Malhotra'" , "Ipsec (E-mail)" Subject: RE: IPSEC and ISAKMP MIBs Date: Tue, 1 Aug 2000 12:05:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk See the COPS-PR PIB for IPsec (draft-ietf-ipsp-ipsecpib-00.txt), and the work of the IP Security Policy working group. This PIB should also be usable for SNMP, but it will not be an easy thing to use that way. IPsec configuration rather stresses the expressive capabilities of SNMP, to say the least. COPS-PR is probably a much better way to configure IPsec than SNMP. Tim Jenkins and I have never had any intent of even trying to do IPsec configuration in our monitoring MIB efforts. The very thought made us dizzy... > -----Original Message----- > From: Ruchir Malhotra [mailto:ruchir@broadpac.com] > Sent: Tuesday, August 01, 2000 12:23 PM > To: Ipsec (E-mail) > Subject: IPSEC and ISAKMP MIBs > > > Hi, > What are the latest drafts and/or RFCs on IPSEC and ISAKMP > CONFIGURATION > MIBs (not monitoring MIBs) ? > > Regards > Ruchir > From owner-ipsec@lists.tislabs.com Tue Aug 1 14:19:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17325; Tue, 1 Aug 2000 14:19:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21292 Tue, 1 Aug 2000 16:09:17 -0400 (EDT) Message-ID: <398730C1.961D2D2A@redcreek.com> Date: Tue, 01 Aug 2000 13:19:13 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Shriver, John" CC: "'Ruchir Malhotra'" , "Ipsec (E-mail)" Subject: Re: IPSEC and ISAKMP MIBs References: <392A357CE6FFD111AC3E00A0C99848B003695028@hdsmsx31.hd.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We use an snmp mib for policy configuration, and I don't think it's all that difficult to represent ipsec security policy in a mib. Ours is in its first rev and definitely needs revision, but we do not expect this to be troublesome as we advance. "Shriver, John" wrote: > > See the COPS-PR PIB for IPsec (draft-ietf-ipsp-ipsecpib-00.txt), and the > work of the IP Security Policy working group. This PIB should also be > usable for SNMP, but it will not be an easy thing to use that way. IPsec > configuration rather stresses the expressive capabilities of SNMP, to say > the least. COPS-PR is probably a much better way to configure IPsec than > SNMP. > > Tim Jenkins and I have never had any intent of even trying to do IPsec > configuration in our monitoring MIB efforts. The very thought made us > dizzy... > > > -----Original Message----- > > From: Ruchir Malhotra [mailto:ruchir@broadpac.com] > > Sent: Tuesday, August 01, 2000 12:23 PM > > To: Ipsec (E-mail) > > Subject: IPSEC and ISAKMP MIBs > > > > > > Hi, > > What are the latest drafts and/or RFCs on IPSEC and ISAKMP > > CONFIGURATION > > MIBs (not monitoring MIBs) ? > > > > Regards > > Ruchir > > From owner-ipsec@lists.tislabs.com Tue Aug 1 14:21:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17378; Tue, 1 Aug 2000 14:21:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21311 Tue, 1 Aug 2000 16:12:21 -0400 (EDT) Message-ID: <002f01bffbf6$6f5dad40$37874993@redcreek.com> From: "Ricky Charlet" To: "Shriver, John" , "'Ruchir Malhotra'" , "Ipsec (E-mail)" References: <392A357CE6FFD111AC3E00A0C99848B003695028@hdsmsx31.hd.intel.com> Subject: Re: IPSEC and ISAKMP MIBs Date: Tue, 1 Aug 2000 13:24:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ----- Original Message ----- From: Shriver, John To: 'Ruchir Malhotra' ; Ipsec (E-mail) Sent: Tuesday, August 01, 2000 12:05 PM Subject: RE: IPSEC and ISAKMP MIBs > See the COPS-PR PIB for IPsec (draft-ietf-ipsp-ipsecpib-00.txt), and the > work of the IP Security Policy working group. This PIB should also be > usable for SNMP, but it will not be an easy thing to use that way. IPsec > configuration rather stresses the expressive capabilities of SNMP, to say > the least. COPS-PR is probably a much better way to configure IPsec than > SNMP. Not so. I have written an IPsec configuration MIB. It's not public just yet, but I did want to say on this thread that SNMP is quiet capable of configuring IPsec. If there is interest in developing an interoperable IPsec config MIB, then I'd be happy to share my experiences. Otherwise, I'll not bore this list with a largish MIB doc. > > Tim Jenkins and I have never had any intent of even trying to do IPsec > configuration in our monitoring MIB efforts. The very thought made us > dizzy... > > > -----Original Message----- > > From: Ruchir Malhotra [mailto:ruchir@broadpac.com] > > Sent: Tuesday, August 01, 2000 12:23 PM > > To: Ipsec (E-mail) > > Subject: IPSEC and ISAKMP MIBs > > > > > > Hi, > > What are the latest drafts and/or RFCs on IPSEC and ISAKMP > > CONFIGURATION > > MIBs (not monitoring MIBs) ? > > > > Regards > > Ruchir > > > From owner-ipsec@lists.tislabs.com Tue Aug 1 16:51:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20589; Tue, 1 Aug 2000 16:51:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA21688 Tue, 1 Aug 2000 18:11:56 -0400 (EDT) Message-ID: <517244DCC735D411A9BF00E029309B37015AAF@sanjose.broadpac.com> From: Ruchir Malhotra To: "'Ricky Charlet'" , "Shriver, John" , Ruchir Malhotra , "Ipsec (E-mail)" Subject: RE: IPSEC and ISAKMP MIBs Date: Tue, 1 Aug 2000 15:18:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would love to see this "largish" MIB doc Ruchir -----Original Message----- From: Ricky Charlet [mailto:rcharlet@redcreek.com] Sent: Tuesday, August 01, 2000 1:24 PM To: Shriver, John; 'Ruchir Malhotra'; Ipsec (E-mail) Subject: Re: IPSEC and ISAKMP MIBs ----- Original Message ----- From: Shriver, John To: 'Ruchir Malhotra' ; Ipsec (E-mail) Sent: Tuesday, August 01, 2000 12:05 PM Subject: RE: IPSEC and ISAKMP MIBs > See the COPS-PR PIB for IPsec (draft-ietf-ipsp-ipsecpib-00.txt), and the > work of the IP Security Policy working group. This PIB should also be > usable for SNMP, but it will not be an easy thing to use that way. IPsec > configuration rather stresses the expressive capabilities of SNMP, to say > the least. COPS-PR is probably a much better way to configure IPsec than > SNMP. Not so. I have written an IPsec configuration MIB. It's not public just yet, but I did want to say on this thread that SNMP is quiet capable of configuring IPsec. If there is interest in developing an interoperable IPsec config MIB, then I'd be happy to share my experiences. Otherwise, I'll not bore this list with a largish MIB doc. > > Tim Jenkins and I have never had any intent of even trying to do IPsec > configuration in our monitoring MIB efforts. The very thought made us > dizzy... > > > -----Original Message----- > > From: Ruchir Malhotra [mailto:ruchir@broadpac.com] > > Sent: Tuesday, August 01, 2000 12:23 PM > > To: Ipsec (E-mail) > > Subject: IPSEC and ISAKMP MIBs > > > > > > Hi, > > What are the latest drafts and/or RFCs on IPSEC and ISAKMP > > CONFIGURATION > > MIBs (not monitoring MIBs) ? > > > > Regards > > Ruchir > > > From owner-ipsec@lists.tislabs.com Tue Aug 1 22:43:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA13413; Tue, 1 Aug 2000 22:43:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA22973 Wed, 2 Aug 2000 00:08:14 -0400 (EDT) To: ietf-cat-wg@lists.stanford.edu, ietf-krb-wg@anl.gov, ipsec@lists.tislabs.com Subject: Kerberized Key Management Protocol BOF, Wed, Aug 2, 0900-1130 From: Derek Atkins Date: 02 Aug 2000 00:17:11 -0400 Message-ID: Lines: 27 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Kerberized Key Management Protocol (KKMP) BOF will be meeting in South Room 10 from 0900-1130 tomorrow, Wednesday, August 2. A short description of KKMP follows. -derek KKMP is trying to create a standards track protocol to facilitate centralized key exchange in an application independent fashion. Participating systems will use the Kerberos architecture as defined in RFC 1510 for key management and the KKMP protocol between applications. The goal of KKMP group is to produce a streamlined, fast, easily managed, and cryptographically sound protocol that is flexible enough to be able to be extended for many applications. The focus of the initial protocol will be keying IPsec security associations as defined in RFC 2401. The working group may consider means to key other protocols in the future, but the initial goal of the KKMP working group is specifically targeted at producing a streamlined and efficient keying mechanism for IPsec. The working group will not be involved with, nor should it require changes to either IPsec (RFC 2401), or Kerberos (RFC 1510). -- 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 N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Aug 2 00:07:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA16845; Wed, 2 Aug 2000 00:07:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA23250 Wed, 2 Aug 2000 01:50:10 -0400 (EDT) Message-ID: <002201bffc46$e137bd20$8a1b6e0a@jariws1.arenanet.fi> From: "Jari Arkko" To: "Ruchir Malhotra" , "'Ricky Charlet'" , "Shriver, John" , "Ipsec (E-mail)" Subject: Re: IPSEC and ISAKMP MIBs Date: Wed, 2 Aug 2000 08:59:53 +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 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > configuration rather stresses the expressive capabilities of SNMP, to say > the least. COPS-PR is probably a much better way to configure IPsec than > SNMP. Personally, I don't think the representation mechanisms are the issue. There are several MIBs for configuring IPsec though they are private, we have one too. It is possible, though there is no getting around the fact that IPsec configuration is complicated. But: If we would actually get down to discussing the MIB or the PIB or the whatever for configuring IPsec, I believe we'd see many arguments exactly how the policies etc. are to be represented and exactly what can be configured, which parameters are mandatory for all implementations, at what level the configurations are presented and so on. Much more discussions than in the case of the monitoring MIBs, which have been redesigned multiple times. It would be interesting to compare the configuration MIB approach and the IPsec policy WG approach. If the latter reaches a consensus on a schema for IPsec policy, perhaps the same schema could be represented in multiple ways, as an LDAP database, as a textual language, as COPS PIB, as an SNMP MIB, ...? Jari Arkko Ericsson From owner-ipsec@lists.tislabs.com Wed Aug 2 08:02:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10784; Wed, 2 Aug 2000 08:02:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24581 Wed, 2 Aug 2000 09:12:50 -0400 (EDT) Message-ID: <01a701bffc84$d61e8430$d2814993@cisco.com> From: "Stephane Beaulieu" To: "Kavsan, Bronislav" , References: Subject: Re: VPN Bakeoff question Date: Wed, 2 Aug 2000 09:23:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Cisco will be testing XAUTH both Client and Server side. A central RADIUS Server and an SDI server would be great ! Thanks Slava, Stephane. ----- Original Message ----- From: "Kavsan, Bronislav" To: Sent: Sunday, July 30, 2000 11:18 AM Subject: VPN Bakeoff question > Is anyone interested in testing XAUTH, Hybrid Auth or CRACK using SecurID > tokens at the September bakeoff? > > If there is enough interest - RSA Security will set up integrated ACE/RADIUS > server there and configure/distribute SecurID tokens to the participants of > the bakeoff. > > Thank you, > > Slava Kavsan > RSA Security Inc. > > From owner-ipsec@lists.tislabs.com Wed Aug 2 13:10:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA22510; Wed, 2 Aug 2000 13:09:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26022 Wed, 2 Aug 2000 14:25:06 -0400 (EDT) Message-ID: <00c401bffcb0$a05f3160$37874993@redcreek.com> From: "Ricky Charlet" To: "Ipsec (E-mail)" , Cc: "Jari Arkko" References: <517244DCC735D411A9BF00E029309B37015AA8@sanjose.broadpac.com> <398705A4.59860CEA@redcreek.com> Subject: Re: IPSEC and ISAKMP MIBs Date: Wed, 2 Aug 2000 11:36:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, I'd like to survey for interest in developing an IPsec config mib for use with SNMP. We (redcreek) developed an enteprise mib for ipsec-cfg. Jari Arkko has posted that his company has also devleoped an ipsec-cfg mib and hints that he knows of others. Ruchir Malhotra started this thread by asking if an ietf ipsec-cfg mib existed. So I ask the question, shall we develop an ipsec-cfg mib as an IETF document? If it turns out that we do have sufficient interest to go forward on this, then I'd like to make several suggestions: o we collect and direct an intereseted group at the ipsec meeting this thursday o we involve people from snmp-conf o we involve people from ipsec-policy o (maybe) this effort should be handled under the ipsec-policy WG? Of course, if there is not much interest in this direction, then nevermid. Ricky Charlet rcharlet@redcreek.com From owner-ipsec@lists.tislabs.com Wed Aug 2 15:08:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24824; Wed, 2 Aug 2000 15:08:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26703 Wed, 2 Aug 2000 17:07:22 -0400 (EDT) Message-ID: <000a01bffcc7$4af19120$37874993@redcreek.com> From: "Ricky Charlet" To: "Vlado Zafirov" , References: <397C5ACC.95403F1D@radware.com> Subject: Re: New draft-vlado-keep-alive-02 Date: Wed, 2 Aug 2000 14:19:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, There are now two drafts about how to do heartbeats/keepalives with IPsec. Back in Adelaide, we were directed by our WG chair (who was directed by the AD's) to build a compelling case for the need for keepalives before the working group would take it up. I think that Vlado's problem description shows one huge motivation why we should care about this, namely as an enabler for fault recovery. The IPSRA group has also settled on a requirement that gateways must be able to detect the disaperance of clients as an enabler to accounting. In my estimation, these two motivations are each sufficient on their own to move forward with a heartbeat/keepalive work. (It remains to debate how best to do this) But I just wanted to state my opinion that I think this is valid working group effort. Any one have other thoughts here???? Ricky Charlet rcharlet@redcreek.com ----- Original Message ----- From: Vlado Zafirov To: Sent: Monday, July 24, 2000 8:03 AM Subject: New draft-vlado-keep-alive-02 > Hi, > This is my new version of the draft. I hope I addressed most of the > issues of the previous one. > > -- > Vlado Zafirov > RADWare, INC > Technical Support Engineer > Tel: (202) 625-1505 > Fax: (202) 625-1506 > > Confidentiality Note: This e-mail, and any attachment to it, contains > privileged and confidential information intended only for the use of the > individual(s) or entity > named in the e-mail. If the reader of this e-mail is not the intended > recipient, or the employee or agent responsible for delivering it to the > intended recipient, you are > hereby notified that reading it is strictly prohibited. If you have > received this e-mail in error, please immediately return it to the > sender and delete it from your system. > Thank you. > > From owner-ipsec@lists.tislabs.com Wed Aug 2 15:08:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24838; Wed, 2 Aug 2000 15:08:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26696 Wed, 2 Aug 2000 17:07:02 -0400 (EDT) Message-ID: <000901bffcc7$400abc00$37874993@redcreek.com> From: "Ricky Charlet" To: "Vlado Zafirov" , References: <397C5ACC.95403F1D@radware.com> Subject: Re: New draft-vlado-keep-alive-02 Date: Wed, 2 Aug 2000 14:18:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, There are now two drafts about how to do heartbeats/keepalives with IPsec. Back in Adelaide, we were directed by our WG chair (who was directed by the AD's) to build a compelling case for the need for keepalives before the working group would take it up. I think that Vlado's problem description shows one huge motivation why we should care about this, namely as an enabler for fault recovery. The IPSRA group has also settled on a requirement that gateways must be able to detect the disaperance of clients as an enabler to accounting. In my estimation, these two motivations are each sufficient on their own to move forward with a heartbeat/keepalive work. (It remains to debate how best to do this) But I just wanted to state my opinion that I think this is valid working group effort. Any one have other thoughts here???? Ricky Charlet rcharlet@redcreek.com ----- Original Message ----- From: Vlado Zafirov To: Sent: Monday, July 24, 2000 8:03 AM Subject: New draft-vlado-keep-alive-02 > Hi, > This is my new version of the draft. I hope I addressed most of the > issues of the previous one. > > -- > Vlado Zafirov > RADWare, INC > Technical Support Engineer > Tel: (202) 625-1505 > Fax: (202) 625-1506 > > Confidentiality Note: This e-mail, and any attachment to it, contains > privileged and confidential information intended only for the use of the > individual(s) or entity > named in the e-mail. If the reader of this e-mail is not the intended > recipient, or the employee or agent responsible for delivering it to the > intended recipient, you are > hereby notified that reading it is strictly prohibited. If you have > received this e-mail in error, please immediately return it to the > sender and delete it from your system. > Thank you. > > From owner-ipsec@lists.tislabs.com Wed Aug 2 15:11:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24886; Wed, 2 Aug 2000 15:11:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26708 Wed, 2 Aug 2000 17:07:41 -0400 (EDT) Message-ID: <000b01bffcc7$562c52a0$37874993@redcreek.com> From: "Ricky Charlet" To: "Vlado Zafirov" , References: <397C5ACC.95403F1D@radware.com> Subject: Re: New draft-vlado-keep-alive-02 Date: Wed, 2 Aug 2000 14:19:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, There are now two drafts about how to do heartbeats/keepalives with IPsec. Back in Adelaide, we were directed by our WG chair (who was directed by the AD's) to build a compelling case for the need for keepalives before the working group would take it up. I think that Vlado's problem description shows one huge motivation why we should care about this, namely as an enabler for fault recovery. The IPSRA group has also settled on a requirement that gateways must be able to detect the disaperance of clients as an enabler to accounting. In my estimation, these two motivations are each sufficient on their own to move forward with a heartbeat/keepalive work. (It remains to debate how best to do this) But I just wanted to state my opinion that I think this is valid working group effort. Any one have other thoughts here???? Ricky Charlet rcharlet@redcreek.com ----- Original Message ----- From: Vlado Zafirov To: Sent: Monday, July 24, 2000 8:03 AM Subject: New draft-vlado-keep-alive-02 > Hi, > This is my new version of the draft. I hope I addressed most of the > issues of the previous one. > > -- > Vlado Zafirov > RADWare, INC > Technical Support Engineer > Tel: (202) 625-1505 > Fax: (202) 625-1506 > > Confidentiality Note: This e-mail, and any attachment to it, contains > privileged and confidential information intended only for the use of the > individual(s) or entity > named in the e-mail. If the reader of this e-mail is not the intended > recipient, or the employee or agent responsible for delivering it to the > intended recipient, you are > hereby notified that reading it is strictly prohibited. If you have > received this e-mail in error, please immediately return it to the > sender and delete it from your system. > Thank you. > > From owner-ipsec@lists.tislabs.com Wed Aug 2 15:12:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA24924; Wed, 2 Aug 2000 15:12:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA26713 Wed, 2 Aug 2000 17:07:54 -0400 (EDT) Message-ID: <000c01bffcc7$5dd513c0$37874993@redcreek.com> From: "Ricky Charlet" To: "Vlado Zafirov" , References: <397C5ACC.95403F1D@radware.com> Subject: Re: New draft-vlado-keep-alive-02 Date: Wed, 2 Aug 2000 14:19:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, There are now two drafts about how to do heartbeats/keepalives with IPsec. Back in Adelaide, we were directed by our WG chair (who was directed by the AD's) to build a compelling case for the need for keepalives before the working group would take it up. I think that Vlado's problem description shows one huge motivation why we should care about this, namely as an enabler for fault recovery. The IPSRA group has also settled on a requirement that gateways must be able to detect the disaperance of clients as an enabler to accounting. In my estimation, these two motivations are each sufficient on their own to move forward with a heartbeat/keepalive work. (It remains to debate how best to do this) But I just wanted to state my opinion that I think this is valid working group effort. Any one have other thoughts here???? Ricky Charlet rcharlet@redcreek.com ----- Original Message ----- From: Vlado Zafirov To: Sent: Monday, July 24, 2000 8:03 AM Subject: New draft-vlado-keep-alive-02 > Hi, > This is my new version of the draft. I hope I addressed most of the > issues of the previous one. > > -- > Vlado Zafirov > RADWare, INC > Technical Support Engineer > Tel: (202) 625-1505 > Fax: (202) 625-1506 > > Confidentiality Note: This e-mail, and any attachment to it, contains > privileged and confidential information intended only for the use of the > individual(s) or entity > named in the e-mail. If the reader of this e-mail is not the intended > recipient, or the employee or agent responsible for delivering it to the > intended recipient, you are > hereby notified that reading it is strictly prohibited. If you have > received this e-mail in error, please immediately return it to the > sender and delete it from your system. > Thank you. > > From owner-ipsec@lists.tislabs.com Thu Aug 3 06:38:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA08294; Thu, 3 Aug 2000 06:38:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA28774 Thu, 3 Aug 2000 07:52:06 -0400 (EDT) From: Uri Blumenthal Message-Id: <200008022126.RAA24022@buoy.watson.ibm.com> Subject: Re: IPSEC and ISAKMP MIBs To: rcharlet@redcreek.com (Ricky Charlet) Date: Wed, 2 Aug 2000 17:26:12 -0400 (EDT) Cc: ipsec@lists.tislabs.com ("Ipsec (E-mail)"), snmpv3@lists.tislabs.com In-Reply-To: <00c401bffcb0$a05f3160$37874993@redcreek.com> from "Ricky Charlet" at Aug 02, 2000 11:36:51 AM Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ricky Charlet says: > I'd like to survey for interest in developing an IPsec config mib for > use with SNMP. We (redcreek) developed an enteprise mib for ipsec-cfg. Jari > Arkko has posted that his company has also devleoped an ipsec-cfg mib and > hints that he knows of others. Ruchir Malhotra started this thread by asking > if an ietf ipsec-cfg mib existed. So I ask the question, shall we develop > an ipsec-cfg mib as an IETF document? IMHO it would make sense to do so. A standard protocol kinda deserves a standard MIB. (:-) As the first step. maybe you guys (those with some ipsec-cfg MIB ideas and/or code) can meet and settle it between yourselves which objects/features are a-must (and which can be conveniently lost)? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- From owner-ipsec@lists.tislabs.com Thu Aug 3 10:50:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21477; Thu, 3 Aug 2000 10:50:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01550 Thu, 3 Aug 2000 12:10:00 -0400 (EDT) Message-ID: <001101bffd66$ec7efce0$37874993@redcreek.com> From: "Ricky Charlet" To: "Ricky Charlet" , "Vlado Zafirov" , References: <397C5ACC.95403F1D@radware.com> <000901bffcc7$400abc00$37874993@redcreek.com> Subject: Re: New draft-vlado-keep-alive-02 Date: Thu, 3 Aug 2000 09:21:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk My apologies for the multiple posts. It was user error. Ricky Charlet From owner-ipsec@lists.tislabs.com Thu Aug 3 18:43:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12403; Thu, 3 Aug 2000 18:43:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA21190 Thu, 3 Aug 2000 20:31:20 -0400 (EDT) From: "Luis A. Sanchez" Message-Id: <200008040037.UAA00313@nutmeg.bbn.com> Subject: Re: IPSEC and ISAKMP MIBs In-Reply-To: <002201bffc46$e137bd20$8a1b6e0a@jariws1.arenanet.fi> from Jari Arkko at "Aug 2, 2000 08:59:53 am" To: Jari Arkko Date: Thu, 3 Aug 2000 20:37:28 -0400 (EDT) CC: Ruchir Malhotra , "'Ricky Charlet'" , "Shriver, John" , "Ipsec (E-mail)" Reply-to: lsanchez@bbn.com X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > It would be interesting to compare the configuration MIB approach and the IPsec > policy WG approach. If the latter reaches a consensus on a schema for IPsec policy, > perhaps the same schema could be represented in multiple ways, as an LDAP database, > as a textual language, as COPS PIB, as an SNMP MIB, ...? > Jari, The IPsec policy configuration document is moving forward in IPSP. There is already an IPsec PIB document and it derives from the IPsec configuration data model. The configuration MIB will follow the same steps. On a separate note, I suggest we move this discussion to the IPsec Policy mailing list (ipsec-policy@vpnc.org) Luis From owner-ipsec@lists.tislabs.com Thu Aug 3 18:43:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12437; Thu, 3 Aug 2000 18:43:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA20890 Thu, 3 Aug 2000 20:18:56 -0400 (EDT) From: "Luis A. Sanchez" Message-Id: <200008040025.UAA00296@nutmeg.bbn.com> Subject: Re: IPSEC and ISAKMP MIBs In-Reply-To: <00c401bffcb0$a05f3160$37874993@redcreek.com> from Ricky Charlet at "Aug 2, 2000 11:36:51 am" To: Ricky Charlet Date: Thu, 3 Aug 2000 20:25:06 -0400 (EDT) CC: "Ipsec (E-mail)" , snmpv3@lists.tislabs.com, Jari Arkko Reply-to: lsanchez@bbn.com X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Howdy, > I'd like to survey for interest in developing an IPsec config mib for > use with SNMP. We (redcreek) developed an enteprise mib for ipsec-cfg. Jari > Arkko has posted that his company has also devleoped an ipsec-cfg mib and > hints that he knows of others. Ruchir Malhotra started this thread by asking > if an ietf ipsec-cfg mib existed. So I ask the question, shall we develop > an ipsec-cfg mib as an IETF document? > > If it turns out that we do have sufficient interest to go forward on this, > then I'd like to make several suggestions: > o we collect and direct an intereseted group at the ipsec meeting this > thursday > o we involve people from snmp-conf > o we involve people from ipsec-policy > o (maybe) this effort should be handled under the ipsec-policy WG? There is interest and yes, it is part of the IPSP WG charter. Jon Saperia (co-chair) of snmpconf offered to find someone from that WG to help editing the document. So if you want the job you got it. Luis > > Of course, if there is not much interest in this direction, then > nevermid. > > Ricky Charlet > rcharlet@redcreek.com > From owner-ipsec@lists.tislabs.com Thu Aug 3 19:28:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA16242; Thu, 3 Aug 2000 19:28:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA24702 Thu, 3 Aug 2000 21:28:18 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: Subject: Heartbeats Straw Poll Date: Thu, 3 Aug 2000 21:31:41 -0400 Message-Id: <000001bffdb3$bf70fe90$a3d0788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The straw poll at the meeting indicated, just as it did in Australia, that there is neither consensus for or against pursuing a heartbeat protocol in IPsec. >From my observation of which people put their hands up, it seems to me that most of those who voted 'yea' work for commercial VPN vendors, whereas most of those who voted 'nay' are academics or developers of free software. While this is an obvious distinction, it may represent a differing perspective among the commercial and non-commercial facets of our WG. To those who voted against the idea of a keep-alive protocol, how do you propose that we ensure high availablilty IPsec for our customers who demand it? Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Thu Aug 3 20:14:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA20110; Thu, 3 Aug 2000 20:14:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA27184 Thu, 3 Aug 2000 22:11:23 -0400 (EDT) Date: Thu, 3 Aug 2000 22:20:30 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Heartbeats Straw Poll In-Reply-To: <000001bffdb3$bf70fe90$a3d0788a@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 3 Aug 2000, Andrew Krywaniuk wrote: > From my observation of which people put their hands up, it seems to me that > most of those who voted 'yea' work for commercial VPN vendors, whereas most > of those who voted 'nay' are academics or developers of free software... Speaking as a free-software developer (technical lead of FreeS/WAN), our current analysis says that an IKE-level heartbeat is necessary and important. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Aug 4 08:09:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10961; Fri, 4 Aug 2000 08:09:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19243 Fri, 4 Aug 2000 09:39:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <000001bffdb3$bf70fe90$a3d0788a@andrewk3.ca.newbridge.com> References: <000001bffdb3$bf70fe90$a3d0788a@andrewk3.ca.newbridge.com> Date: Fri, 4 Aug 2000 09:48:29 -0400 To: ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: Heartbeats Straw Poll Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:31 PM -0400 8/3/00, Andrew Krywaniuk wrote: > >From my observation of which people put their hands up, it seems to me that >most of those who voted 'yea' work for commercial VPN vendors, whereas most >of those who voted 'nay' are academics or developers of free software. Your observation disagreed with mine. I saw plenty of commercial VPN vendors raise their hand for "no heartbeat specification from the WG" (and, of course, plenty raising their hand in favor). When the group was asked "how many people understand this proposal", I saw lots of people who I would have hoped would have raised their hands not doing so (and not voting in the next two questions, thankfully). Sounds like we might want a *short*, concise statement of the problem to the list before the straw poll is taken next. Maybe start with a neutral description of the problem, followed by two paragraphs in favor and two opposed. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Aug 4 08:26:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA14828; Fri, 4 Aug 2000 08:26:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19605 Fri, 4 Aug 2000 10:27:16 -0400 (EDT) Message-ID: <398AD511.3E96F46A@radware.com> Date: Fri, 04 Aug 2000 10:37:05 -0400 From: Vlado Zafirov X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: andrew.krywaniuk@alcatel.com CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <000001bffdb3$bf70fe90$a3d0788a@andrewk3.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I still don't understand what all these people have against the idea? Andrew Krywaniuk wrote: > The straw poll at the meeting indicated, just as it did in Australia, that > there is neither consensus for or against pursuing a heartbeat protocol in > IPsec. > > From my observation of which people put their hands up, it seems to me that > most of those who voted 'yea' work for commercial VPN vendors, whereas most > of those who voted 'nay' are academics or developers of free software. > > While this is an obvious distinction, it may represent a differing > perspective among the commercial and non-commercial facets of our WG. > > To those who voted against the idea of a keep-alive protocol, how do you > propose that we ensure high availablilty IPsec for our customers who demand > it? > > Andrew > -------------------------------------- > Beauty with out truth is insubstantial. > Truth without beauty is unbearable. -- Vlado Zafirov RADWare, INC Technical Support Engineer Tel: (202) 625-1505 Fax: (202) 625-1506 Confidentiality note: This message, and any attachments to it, contains privileged/confidential information of RADWARE Ltd./RADWARE Inc. and may not be disclosed, used, copied, or transmitted in any form or by any means without prior written permission from RADWARE. If you are not the intended recipient, delete the message and any attachments from your system without reading or copying it, and kindly notify the sender by e-mail. Thank you. From owner-ipsec@lists.tislabs.com Fri Aug 4 08:27:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15024; Fri, 4 Aug 2000 08:27:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19589 Fri, 4 Aug 2000 10:26:14 -0400 (EDT) Message-ID: <398AD4D3.BE284A79@radware.com> Date: Fri, 04 Aug 2000 10:36:03 -0400 From: Vlado Zafirov X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Henry Spencer CC: IP Security List Subject: Re: Heartbeats Straw Poll References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yeah! We need that keep-alive. Henry, what you have agianst the idea for using Phase 2 SA? I am using FreeSwan and I've implemented my idea there. Works fine. Henry Spencer wrote: > On Thu, 3 Aug 2000, Andrew Krywaniuk wrote: > > From my observation of which people put their hands up, it seems to me that > > most of those who voted 'yea' work for commercial VPN vendors, whereas most > > of those who voted 'nay' are academics or developers of free software... > > Speaking as a free-software developer (technical lead of FreeS/WAN), our > current analysis says that an IKE-level heartbeat is necessary and important. > > Henry Spencer > henry@spsystems.net -- Vlado Zafirov RADWare, INC Technical Support Engineer Tel: (202) 625-1505 Fax: (202) 625-1506 Confidentiality note: This message, and any attachments to it, contains privileged/confidential information of RADWARE Ltd./RADWARE Inc. and may not be disclosed, used, copied, or transmitted in any form or by any means without prior written permission from RADWARE. If you are not the intended recipient, delete the message and any attachments from your system without reading or copying it, and kindly notify the sender by e-mail. Thank you. From owner-ipsec@lists.tislabs.com Fri Aug 4 08:53:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17104; Fri, 4 Aug 2000 08:53:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19780 Fri, 4 Aug 2000 10:52:57 -0400 (EDT) Message-Id: <200008041502.e74F2JS110555@thunk.east.sun.com> From: Bill Sommerfeld To: Paul Hoffman cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-reply-to: Your message of "Fri, 04 Aug 2000 09:48:29 EDT." Reply-to: sommerfeld@East.Sun.COM Date: Fri, 04 Aug 2000 11:02:19 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As several people brought up in the meeting, "keepalives" under the wrong circumstances tend to turn into "make-deads". IKE and IPSEC implementations should not delete SA's prior to their normal expiration merely because they haven't heard from the other end in a while. There appear to be two different properties people are looking for from heartbeats/keepalives: First, rapid recovery from loss of state on one end of a security association (due to power loss/reboot/reset), so a new IKE SA can be initiated on one end or the other. Once this happens, the half-dead state on one end can be garbage collected as a result of an affirmative indication (IKE INITIAL-CONTACT) that the other side lost state. Second, detection of loss of connectivity between two security gateways so that traffic can be rerouted through an alternate gateway. This is really a dynamic routing problem and could (and probably should) be done without prematurely tearing down IKE SA's and IPSEC SA's which may still exist and may still be useful once the connectivity comes back. It's not clear that the same protocol feature can/should provide both of these properties.. - Bill From owner-ipsec@lists.tislabs.com Fri Aug 4 10:23:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA19787; Fri, 4 Aug 2000 10:23:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20068 Fri, 4 Aug 2000 12:25:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4368.4 content-class: urn:content-classes:message Subject: IKE Question... Date: Fri, 4 Aug 2000 12:35:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <6EDB5387450D554B91BEACCC30E134F002BC10@exchange.itsolutions-us.com> Thread-Topic: IKE Question... Thread-Index: Ab/+MgSI1OCfLiI3Rz6hvlDnBaQpQA== From: "Rick Replogle" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id MAA20065 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I apologise, in advance,if this question has been asked before, or if it jsut plain seems silly to you. During the initial negotiation of IKE, what prevents someone sniffing on the network from picking up the information transmitted needed by the communicating computers to generate the key? Thus allowing said sniffer to generate an identical copy of the key and decrypting any information subsiquently transmitted. Thanks in Advance. Rick Replogle Network Engineer rreplogle@itsolutions-us.com From owner-ipsec@lists.tislabs.com Fri Aug 4 11:15:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20544; Fri, 4 Aug 2000 11:15:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20442 Fri, 4 Aug 2000 13:19:56 -0400 (EDT) Message-ID: <398AFD8A.7EB3B732@radware.com> Date: Fri, 04 Aug 2000 13:29:46 -0400 From: Vlado Zafirov X-Mailer: Mozilla 4.74 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: sommerfeld@East.Sun.COM CC: Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <200008041502.e74F2JS110555@thunk.east.sun.com> Content-Type: multipart/alternative; boundary="------------648E00E12905A37B19DEDBC5" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --------------648E00E12905A37B19DEDBC5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bill, Concider the following situation (Active) +-------+ | SGW 1 | +-------+ +-------+------- Internet -------- | SGW 3 | +-------+-------/ +-------+ | SGW 2 | +-------+ (Backup) SGW = Secure Gateway If SGW 1 dies SGW doesn't have a clue about the SPIs that SGW 3 is sending. How he will inform the other end? About the problem on routing. This is intermitment problem and if there is no connectivity for more that X seconds it's a good idea to delete the SA. What if somebody re-routed connection to somewhere and getting packets with the intent to crack the key? If SGW start sending only UDP 500 IKE clean-text messages he will be doomed Bill Sommerfeld wrote: > As several people brought up in the meeting, "keepalives" under the > wrong circumstances tend to turn into "make-deads". IKE and IPSEC > implementations should not delete SA's prior to their normal > expiration merely because they haven't heard from the other end in a > while. > > There appear to be two different properties people are looking for > from heartbeats/keepalives: > > First, rapid recovery from loss of state on one end of a security > association (due to power loss/reboot/reset), so a new IKE SA can be > initiated on one end or the other. Once this happens, the half-dead > state on one end can be garbage collected as a result of an > affirmative indication (IKE INITIAL-CONTACT) that the other side lost > state. > > Second, detection of loss of connectivity between two security > gateways so that traffic can be rerouted through an alternate gateway. > This is really a dynamic routing problem and could (and probably > should) be done without prematurely tearing down IKE SA's and IPSEC > SA's which may still exist and may still be useful once the > connectivity comes back. > > It's not clear that the same protocol feature can/should provide both > of these properties.. > > - Bill -- Vlado Zafirov RADWare, INC Technical Support Engineer Tel: (202) 625-1505 Fax: (202) 625-1506 Confidentiality note: This message, and any attachments to it, contains privileged/confidential information of RADWARE Ltd./RADWARE Inc. and may not be disclosed, used, copied, or transmitted in any form or by any means without prior written permission from RADWARE. If you are not the intended recipient, delete the message and any attachments from your system without reading or copying it, and kindly notify the sender by e-mail. Thank you. --------------648E00E12905A37B19DEDBC5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bill,
    Concider the following situation
 

     (Active)
     +-------+
     | SGW 1 |                          +-------+
     +-------+------- Internet -------- | SGW 3 |
     +-------+-------/                  +-------+
     | SGW 2 |
     +-------+
     (Backup)

     SGW = Secure Gateway

If SGW 1 dies SGW doesn't have a clue about the SPIs that SGW 3 is sending. How he will inform the other end?
About the problem on routing. This is intermitment problem and if there is no connectivity for more that X seconds it's a good idea to delete the SA. What if somebody re-routed connection to somewhere and getting packets with the intent to crack the key? If SGW start sending only UDP 500 IKE clean-text messages he will be doomed

Bill Sommerfeld wrote:

As several people brought up in the meeting, "keepalives" under the
wrong circumstances tend to turn into "make-deads".  IKE and IPSEC
implementations should not delete SA's prior to their normal
expiration merely because they haven't heard from the other end in a
while.

There appear to be two different properties people are looking for
from heartbeats/keepalives:

First, rapid recovery from loss of state on one end of a security
association (due to power loss/reboot/reset), so a new IKE SA can be
initiated on one end or the other.  Once this happens, the half-dead
state on one end can be garbage collected as a result of an
affirmative indication (IKE INITIAL-CONTACT) that the other side lost
state.

Second, detection of loss of connectivity between two security
gateways so that traffic can be rerouted through an alternate gateway.
This is really a dynamic routing problem and could (and probably
should) be done without prematurely tearing down IKE SA's and IPSEC
SA's which may still exist and may still be useful once the
connectivity comes back.

It's not clear that the same protocol feature can/should provide both
of these properties..

                                                - Bill

--
Vlado Zafirov
RADWare, INC
Technical Support Engineer
Tel: (202) 625-1505
Fax: (202) 625-1506

Confidentiality note: This message, and any attachments to it, contains
privileged/confidential information of RADWARE Ltd./RADWARE Inc. and may
not be disclosed, used, copied, or transmitted in any form or by any means
without prior written permission from RADWARE. If you are not the intended
recipient, delete the message and any attachments from your system without
reading or copying it, and kindly notify the sender by e-mail. Thank you.
  --------------648E00E12905A37B19DEDBC5-- From owner-ipsec@lists.tislabs.com Fri Aug 4 12:54:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21718; Fri, 4 Aug 2000 12:54:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20649 Fri, 4 Aug 2000 14:34:17 -0400 (EDT) Date: Fri, 4 Aug 2000 14:42:10 -0400 (EDT) From: Skip Booth To: Bill Sommerfeld cc: Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <200008041502.e74F2JS110555@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would add a third reason for heartbeats/keepalives. To be able to do accurate accounting the SG needs to know within a reasonable time that the client has disconnected. If the interface to the AAA server is through IKE and not some other protocol, than IKE must have a mechanism for detecting a lost peer. This issue has been raised on several occasions on the IPSRA list. -Skip On Fri, 4 Aug 2000, Bill Sommerfeld wrote: > As several people brought up in the meeting, "keepalives" under the > wrong circumstances tend to turn into "make-deads". IKE and IPSEC > implementations should not delete SA's prior to their normal > expiration merely because they haven't heard from the other end in a > while. > > There appear to be two different properties people are looking for > from heartbeats/keepalives: > > First, rapid recovery from loss of state on one end of a security > association (due to power loss/reboot/reset), so a new IKE SA can be > initiated on one end or the other. Once this happens, the half-dead > state on one end can be garbage collected as a result of an > affirmative indication (IKE INITIAL-CONTACT) that the other side lost > state. > > Second, detection of loss of connectivity between two security > gateways so that traffic can be rerouted through an alternate gateway. > This is really a dynamic routing problem and could (and probably > should) be done without prematurely tearing down IKE SA's and IPSEC > SA's which may still exist and may still be useful once the > connectivity comes back. > > It's not clear that the same protocol feature can/should provide both > of these properties.. > > - Bill > > From owner-ipsec@lists.tislabs.com Fri Aug 4 13:02:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21873; Fri, 4 Aug 2000 13:02:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20739 Fri, 4 Aug 2000 15:09:21 -0400 (EDT) Message-Id: <200008041753.KAA15075@gallium.network-alchemy.com> To: Vlado Zafirov cc: sommerfeld@East.Sun.COM, Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-reply-to: Your message of "Fri, 04 Aug 2000 13:29:46 EDT." <398AFD8A.7EB3B732@radware.com> Date: Fri, 04 Aug 2000 10:53:47 -0700 From: "Derrell D. Piper" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >If SGW 1 dies SGW doesn't have a clue about the SPIs that SGW 3 is >sending. How he will inform the other end? SGW2 could do a Main Mode under any Phase 1 policy that he has to SGW3 and in the process, tell him INITIAL-CONTACT. No subsequent QM's would happen until the next packet hits SGW3. You would want to rate limit this to prevent the obvious DoS attack on the receiving side. Our product implements this and it works well. (Of course, our clustered gateways have replicated IKE state, so this is a non-problem for most of our customers.) Derrell From owner-ipsec@lists.tislabs.com Sat Aug 5 22:19:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA24213; Sat, 5 Aug 2000 22:19:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA23828 Sat, 5 Aug 2000 23:43:00 -0400 (EDT) Message-Id: <200008060352.e763qKS110811@thunk.east.sun.com> From: Bill Sommerfeld To: Skip Booth cc: Bill Sommerfeld , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-reply-to: Your message of "Fri, 04 Aug 2000 14:42:10 EDT." Reply-to: sommerfeld@East.Sun.COM Date: Sat, 05 Aug 2000 23:52:20 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I would add a third reason for heartbeats/keepalives. To be able to do accurate > accounting the SG needs to know within a reasonable time that the client has > disconnected. I just re-read the ipsec and ipsra charters and saw no mention of accounting as required functionality.. - Bill From owner-ipsec@lists.tislabs.com Mon Aug 7 08:30:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27062; Mon, 7 Aug 2000 08:30:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28319 Mon, 7 Aug 2000 09:50:14 -0400 (EDT) Message-ID: From: Henry Zheng To: ipsec@lists.tislabs.com Subject: IPSec Configuration MIB Date: Sat, 5 Aug 2000 15:47:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFFF2F.138FCC00" 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_01BFFF2F.138FCC00 Content-Type: text/plain; charset="ISO-8859-1" To IPSec working group: I have been reviewing the IPSec Monitoring MIB . This document defines low level monitoring and status MIBs for IPsec security associations (SAs). It does not define MIBs that may be used for configuring IPsec implementations. I would like to ask if there is any on-going effort by IETF's IPSec working group to cover IPSec configuration MIB? Is there any draft available? Or any implementation recommendation from IPSec working group on this topic? I really appreciate your help in answering those questions. Thanks, Henry Zheng Sr. Software Engineer Campio Communications (408) 519-3817 ------_=_NextPart_001_01BFFF2F.138FCC00 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable IPSec Configuration MIB

To IPSec working group: =
I have been reviewing the IPSec = Monitoring MIB <draft-ietf-ipsec-monitor-mib-02.txt>. This document defines low level monitoring and status MIBs for = IPsec security associations (SAs). It does not define = MIBs that may be used = for configuring IPsec = implementations. I would like to ask if there is any on-going effort by = IETF's IPSec working group to cover IPSec configuration MIB? Is there = any draft available? Or any implementation recommendation from IPSec = working group on this topic?

I really appreciate your help in = answering those questions. =
Thanks,
Henry Zheng
Sr. Software = Engineer
Campio = Communications
(408) 519-3817


------_=_NextPart_001_01BFFF2F.138FCC00-- From owner-ipsec@lists.tislabs.com Mon Aug 7 09:41:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28402; Mon, 7 Aug 2000 09:41:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28791 Mon, 7 Aug 2000 11:35:34 -0400 (EDT) Message-Id: <200008071544.e77FijS111403@thunk.east.sun.com> From: Bill Sommerfeld To: "Derrell D. Piper" cc: Vlado Zafirov , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-reply-to: Your message of "Fri, 04 Aug 2000 10:53:47 PDT." <200008041753.KAA15075@gallium.network-alchemy.com> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 07 Aug 2000 11:44:45 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >If SGW 1 dies SGW doesn't have a clue about the SPIs that SGW 3 is > >sending. How he will inform the other end? > > SGW2 could do a Main Mode under any Phase 1 policy that he has to SGW3 and in > the process, tell him INITIAL-CONTACT. No subsequent QM's would happen until > the next packet hits SGW3. You would want to rate limit this to prevent the > obvious DoS attack on the receiving side. If your policies are certificate/name based rather than address-based, this might not work so well (since you could have policy allowing connections from any random address as long as it had the right cert). I'd rather see schemes which put more of the burden on the peer which both had state and had traffic to send. BTW, I think that some sort of "IKE-level ping" facility would be very useful as a diagnostic tool. however, it should not be abused as a "keepalive"/"make-dead" mechanism. - Bill From owner-ipsec@lists.tislabs.com Mon Aug 7 09:54:34 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28681; Mon, 7 Aug 2000 09:54:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28856 Mon, 7 Aug 2000 11:51:57 -0400 (EDT) Message-ID: <398EDD21.E768F182@cisco.com> Date: Mon, 07 Aug 2000 18:00:33 +0200 From: Frederic Detienne Reply-To: fd@cisco.com Organization: Cisco Systems, Inc X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Derrell D. Piper" CC: Vlado Zafirov , sommerfeld@East.Sun.COM, Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <200008041753.KAA15075@gallium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (Active) +-------+ | SGW 1 | +-------+ +-------+------- Internet -------- | SGW 3 | +-------+-------/ +-------+ | SGW 2 | +-------+ (Backup) SGW = Secure Gateway "Derrell D. Piper" wrote: > > >If SGW 1 dies SGW doesn't have a clue about the SPIs that SGW 3 is > >sending. How he will inform the other end? > > SGW2 could do a Main Mode under any Phase 1 policy that he has to SGW3 and in > the process, tell him INITIAL-CONTACT. No subsequent QM's would happen until > the next packet hits SGW3. You would want to rate limit this to prevent the > obvious DoS attack on the receiving side. Our product implements this and it > works well. (Of course, our clustered gateways have replicated IKE state, so > this is a non-problem for most of our customers.) Fine... but how does SGW3 know it has to negotiate new phase 2 SA's with SGW2 ? If the traffic is one way (from sgw3 to sgw1/2), SGW2 will never ask the right SA's to be re-created (how would SGW2 know what it could not decrypt)... frederic detienne From owner-ipsec@lists.tislabs.com Mon Aug 7 10:02:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28847; Mon, 7 Aug 2000 10:02:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28897 Mon, 7 Aug 2000 12:04:31 -0400 (EDT) Date: Mon, 7 Aug 2000 12:12:28 -0400 (EDT) From: Skip Booth To: Bill Sommerfeld cc: Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <200008060352.e763qKS110811@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Check out draft-ietf-ipsra-reqmts-01.txt. Section 2.4 has the following statements: 2.4 Accounting Accounting is used here to refer to the collection and reporting of connection status information by the IRAS. For remote access, the following accounting information is useful: o connection start time o connection end time o incoming octets (with respect to the IRAS) o outgoing octets (with respect to the IRAS) Note that the requirement for a connection-end-time attribute implies the need for a connection keep-alive mechanism of some sort so that the IRAS can accurately determine this quantity in cases where the IRAC does not explicitly terminate the connection. Also note that the keep-alive mechanism in this case is always directed from the IRAC to the IRAS. -Skip On Sat, 5 Aug 2000, Bill Sommerfeld wrote: > > I would add a third reason for heartbeats/keepalives. To be able to do accurate > > accounting the SG needs to know within a reasonable time that the client has > > disconnected. > > I just re-read the ipsec and ipsra charters and saw no mention of > accounting as required functionality.. > > - Bill > > From owner-ipsec@lists.tislabs.com Mon Aug 7 10:12:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28985; Mon, 7 Aug 2000 10:12:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28923 Mon, 7 Aug 2000 12:11:08 -0400 (EDT) Message-Id: <200008071616.JAA05563@potassium.network-alchemy.com> To: sommerfeld@East.Sun.COM cc: "Derrell D. Piper" , Vlado Zafirov , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-reply-to: Your message of "Mon, 07 Aug 2000 11:44:45 EDT." <200008071544.e77FijS111403@thunk.east.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5560.965664998.1@network-alchemy.com> Date: Mon, 07 Aug 2000 09:16:38 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 07 Aug 2000 11:44:45 EDT you wrote > > BTW, I think that some sort of "IKE-level ping" facility would be very > useful as a diagnostic tool. however, it should not be abused as a > "keepalive"/"make-dead" mechanism. I know of two different implementations that have an interoperable "IKE-level ping"-- one side sends a "LIKE_HELLO" (private notify value 30000) the other sends back "SHUT_UP" (private notify value 30002). It's very useful. Dan. From owner-ipsec@lists.tislabs.com Mon Aug 7 10:16:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29065; Mon, 7 Aug 2000 10:16:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28915 Mon, 7 Aug 2000 12:09:43 -0400 (EDT) Message-ID: <398ED3B9.3600EADC@redcreek.com> Date: Mon, 07 Aug 2000 09:20:25 -0600 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <000001bffdb3$bf70fe90$a3d0788a@andrewk3.ca.newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman wrote: > When the group was asked "how many people understand this proposal", > I saw lots of people who I would have hoped would have raised their > hands not doing so (and not voting in the next two questions, > thankfully). Sounds like we might want a *short*, concise statement > of the problem to the list before the straw poll is taken next. Maybe > start with a neutral description of the problem, followed by two > paragraphs in favor and two opposed. > > --Paul Hoffman, Director > --VPN Consortium Howdy, I'll take a stab. Dead Peer Detection. (or some have called this same concept Black Hole Detection). There are several motives for wanting to be able to detect a dead peer. Among these are: o implementing a redundancy strategy o ipsra event auditing (required) and accounting (not required) o general resourse/state recovery Argument in favor: ================== IPsec creates black holes. If an SA is built among peers SGW1 and SSGW2, and later one of those peers (SGW2) becomes unreachable, then protected traffic will be black holed from SGW1 into the (now defunct) SA with no ICMP unreachable messages being sent back to the sending hosts. At the very least, If SGW1 could learn that the SA became a black hole, then it would be able to send ICMP unreachables back to the sending hosts and the dead peer detection to do that MUST interoperate. But, more sophisticated implementations could also choose to create a new SA with a 'back up peer' as one possible redundancy strategy. Redundancy stragegies need not interoperate among vendors, but the dead peer detection mechanism does need to interoperate. Also, when a remote access client is builds an SA with an SGW, there is an unignorable liklihood that the client may be shut down in non-clean fashion (power off, kill process, unplug communications connection...) In the abesnce of a dead peer detection mechanism, the SGW would continue to believe that the client were present until it initiated a re-key event. For gateways connecting thousands of clients, this leads to very unattractive leaking of resourses. But more importantly, it destroys auditing capabilities. An audit event for client connect and client disconnect and loss of client are all deeply significant when you are trying to tack who accessed what when for either legal or technical reasons. IPSRA requires the capability to track connection start and end time (NOTE: in the current rev of the draft draft-ietf-ipsra-reqmts these are listed as Accounting requirements in section 2.4. But at the IPSRA meeting, the acounting requirements got trimed but connection start and stop survived as required audit events). Argument Against: ================== Its hard to do. We had trouble with this stuff back when we did TCP. Also, IPsec WG has lasted a long time now and needs to close, we have a steep prejudice against initiating any new work items. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Mon Aug 7 10:52:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29683; Mon, 7 Aug 2000 10:52:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29087 Mon, 7 Aug 2000 12:47:48 -0400 (EDT) Message-Id: <200008071653.JAA05694@potassium.network-alchemy.com> To: fd@cisco.com cc: "Derrell D. Piper" , Vlado Zafirov , sommerfeld@East.Sun.COM, Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-reply-to: Your message of "Mon, 07 Aug 2000 18:00:33 +0200." <398EDD21.E768F182@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5691.965667202.1@network-alchemy.com> Date: Mon, 07 Aug 2000 09:53:22 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 07 Aug 2000 18:00:33 +0200 you wrote > > "Derrell D. Piper" wrote: > > > > >If SGW 1 dies SGW doesn't have a clue about the SPIs that SGW 3 is > > >sending. How he will inform the other end? > > > > SGW2 could do a Main Mode under any Phase 1 policy that he has to SGW3 and >in > > the process, tell him INITIAL-CONTACT. No subsequent QM's would happen unt >il > > the next packet hits SGW3. You would want to rate limit this to prevent th >e > > obvious DoS attack on the receiving side. Our product implements this and >it > > works well. (Of course, our clustered gateways have replicated IKE state, >so > > this is a non-problem for most of our customers.) > > Fine... but how does SGW3 know it has to negotiate new phase 2 SA's with SGW2 > ? If the traffic is one way (from sgw3 to sgw1/2), SGW2 will never ask the ri >ght SA's to be re-created (how would SGW2 know what it could not decrypt)... That's what the INITIAL-CONTACT notification is for. Dan. From owner-ipsec@lists.tislabs.com Mon Aug 7 10:56:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA29750; Mon, 7 Aug 2000 10:56:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29119 Mon, 7 Aug 2000 12:53:12 -0400 (EDT) Message-ID: <398EDDEF.C561298E@redcreek.com> Date: Mon, 07 Aug 2000 10:03:59 -0600 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Henry Zheng CC: ipsec@lists.tislabs.com Subject: Re: IPSec Configuration MIB References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Zheng wrote: > > To IPSec working group: > I have been reviewing the IPSec Monitoring MIB > . This document defines low level > monitoring and status MIBs for IPsec security associations (SAs). It > does not define MIBs that may be used for configuring IPsec > implementations. I would like to ask if there is any on-going effort > by IETF's IPSec working group to cover IPSec configuration MIB? Is > there any draft available? Or any implementation recommendation from > IPSec working group on this topic? > > I really appreciate your help in answering those questions. > Thanks, > Henry Zheng > Sr. Software Engineer > Campio Communications > (408) 519-3817 Howdy, Work on an ipsec-cfg MIB for use with SNMP is just begining. The work will be done in the IPSP (IPsec Policy) working group. If you wish to track that discussion then you need to subscribe to the ipsec policy mailing list. To subscribe to the mailing list, send a message to ipsec-policy-request@vpnc.org with the single word subscribe in the body of the message. To unsubscribe from the list, use that same address with the single word unsubscribe in the body of the message. You may find an archive of that mailing list at http://www.vpnc.org/ipsec-policy/mail-archive/ -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Mon Aug 7 11:04:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00177; Mon, 7 Aug 2000 11:04:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29131 Mon, 7 Aug 2000 12:54:25 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 07 Aug 2000 11:03:05 -0600 From: "Hilarie Orman" To: , Subject: Re: IPSec Configuration MIB 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 MAA29128 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You might find the IPsec Security Policy WG (IPSP) drafts to be of interest. Hilarie Orman >>> Henry Zheng 08/05/00 04:47PM >>> To IPSec working group: I have been reviewing the IPSec Monitoring MIB . This document defines low level monitoring and status MIBs for IPsec security associations (SAs). It does not define MIBs that may be used for configuring IPsec implementations. I would like to ask if there is any on-going effort by IETF's IPSec working group to cover IPSec configuration MIB? Is there any draft available? Or any implementation recommendation from IPSec working group on this topic? I really appreciate your help in answering those questions. Thanks, Henry Zheng Sr. Software Engineer Campio Communications (408) 519-3817 From owner-ipsec@lists.tislabs.com Mon Aug 7 11:28:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01182; Mon, 7 Aug 2000 11:28:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29245 Mon, 7 Aug 2000 13:19:46 -0400 (EDT) Message-ID: <8E1E94178828D143B34A560A7A6F2C0B2AE84D@mailmaestro.smartpipes.com> From: "Wang, Cliff " To: "'Henry Zheng'" , ipsec@lists.tislabs.com Subject: RE: IPSec Configuration MIB Date: Mon, 7 Aug 2000 17:28:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00094.FC29CBA8" 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_01C00094.FC29CBA8 Content-Type: text/plain; charset="iso-8859-1" Yes, at the last IETF IPSP working group meeting, there is a proposal to write an IPsec config MIB. Such efforts will start soon... -----Original Message----- From: Henry Zheng [mailto:henry@campio.com] Sent: Saturday, August 05, 2000 6:47 PM To: ipsec@lists.tislabs.com Subject: IPSec Configuration MIB To IPSec working group: I have been reviewing the IPSec Monitoring MIB . This document defines low level monitoring and status MIBs for IPsec security associations (SAs). It does not define MIBs that may be used for configuring IPsec implementations. I would like to ask if there is any on-going effort by IETF's IPSec working group to cover IPSec configuration MIB? Is there any draft available? Or any implementation recommendation from IPSec working group on this topic? I really appreciate your help in answering those questions. Thanks, Henry Zheng Sr. Software Engineer Campio Communications (408) 519-3817 ------_=_NextPart_001_01C00094.FC29CBA8 Content-Type: text/html; charset="iso-8859-1" IPSec Configuration MIB
Yes, at the last IETF IPSP working group meeting, there is a proposal to write an IPsec config MIB. Such efforts will start soon...
-----Original Message-----
From: Henry Zheng [mailto:henry@campio.com]
Sent: Saturday, August 05, 2000 6:47 PM
To: ipsec@lists.tislabs.com
Subject: IPSec Configuration MIB

To IPSec working group:
I have been reviewing the IPSec Monitoring MIB <draft-ietf-ipsec-monitor-mib-02.txt>. This document defines low level monitoring and status MIBs for IPsec security associations (SAs). It does not define MIBs that may be used for configuring IPsec implementations. I would like to ask if there is any on-going effort by IETF's IPSec working group to cover IPSec configuration MIB? Is there any draft available? Or any implementation recommendation from IPSec working group on this topic?

I really appreciate your help in answering those questions.
Thanks,
Henry Zheng
Sr. Software Engineer
Campio Communications
(408) 519-3817


------_=_NextPart_001_01C00094.FC29CBA8-- From owner-ipsec@lists.tislabs.com Mon Aug 7 12:53:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03418; Mon, 7 Aug 2000 12:53:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29517 Mon, 7 Aug 2000 14:11:15 -0400 (EDT) From: Sankar Ramamoorthi Reply-To: sankar@nexsi.com To: ipsec@lists.tislabs.com Subject: Fwd: Re: Heartbeats Straw Poll Date: Mon, 7 Aug 2000 10:42:31 -0700 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <00080711234007.18742@odin> Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This leads to an interesting question. RFC 2459 does not mandate that subject-alternate-name based identities MUST be unique. Hence you have the option of creating certificates with the same IKE identity for SGW1 and SGW2 (same value in the subject-altname field). Any comments on the effects of creating two certificates with the same subject-alt-name identity and what it means to IKE authentication. Thanks, -- sankar -- ---------- Forwarded Message ---------- Subject: Re: Heartbeats Straw Poll Date: Mon, 07 Aug 2000 11:44:45 -0400 From: Bill Sommerfeld > >If SGW 1 dies SGW doesn't have a clue about the SPIs that SGW 3 is > >sending. How he will inform the other end? > > SGW2 could do a Main Mode under any Phase 1 policy that he has to SGW3 and in > the process, tell him INITIAL-CONTACT. No subsequent QM's would happen until > the next packet hits SGW3. You would want to rate limit this to prevent the > obvious DoS attack on the receiving side. If your policies are certificate/name based rather than address-based, this might not work so well (since you could have policy allowing connections from any random address as long as it had the right cert). I'd rather see schemes which put more of the burden on the peer which both had state and had traffic to send. BTW, I think that some sort of "IKE-level ping" facility would be very useful as a diagnostic tool. however, it should not be abused as a "keepalive"/"make-dead" mechanism. - Bill ------------------------------------------------------- -- sankar ramamoorthi email: sankar@nexsi.com phone: 408-579-5718 (w) From owner-ipsec@lists.tislabs.com Mon Aug 7 12:53:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03421; Mon, 7 Aug 2000 12:53:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29591 Mon, 7 Aug 2000 14:23:13 -0400 (EDT) From: Sankar Ramamoorthi Reply-To: sankar@nexsi.com To: Ricky Charlet , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll Date: Mon, 7 Aug 2000 11:24:47 -0700 X-Mailer: KMail [version 1.0.29] Content-Type: text/plain References: <000001bffdb3$bf70fe90$a3d0788a@andrewk3.ca.newbridge.com> <398ED3B9.3600EADC@redcreek.com> In-Reply-To: <398ED3B9.3600EADC@redcreek.com> MIME-Version: 1.0 Message-Id: <00080711353208.18742@odin> Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 07 Aug 2000, Ricky Charlet wrote: > Paul Hoffman wrote: > > When the group was asked "how many people understand this proposal", > > I saw lots of people who I would have hoped would have raised their > > hands not doing so (and not voting in the next two questions, > > thankfully). Sounds like we might want a *short*, concise statement > > of the problem to the list before the straw poll is taken next. Maybe > > start with a neutral description of the problem, followed by two > > paragraphs in favor and two opposed. > > > > --Paul Hoffman, Director > > --VPN Consortium > > > Howdy, > I'll take a stab. > > Dead Peer Detection. (or some have called this same concept Black Hole > Detection). > > There are several motives for wanting to be able to detect a dead peer. > Among these are: > o implementing a redundancy strategy > o ipsra event auditing (required) and accounting (not required) This seems to be best reason for a heartbeat protocol. > o general resourse/state recovery > > > Argument in favor: > ================== > IPsec creates black holes. If an SA is built among peers SGW1 and > SSGW2, and later one of those peers (SGW2) becomes unreachable, then > protected traffic will be black holed from SGW1 into the (now defunct) > SA with no ICMP unreachable messages being sent back to the sending > hosts. At the very least, If SGW1 could learn that the SA became a black > hole, then it would be able to send ICMP unreachables back to the > sending hosts and the dead peer detection to do that MUST interoperate. Agree. IMHO, error notification should be part of the base protocol (error botification, combined with the a 'ping' like mechanism) should be the way to detect dead peer detection. So for there has been no agreement on secure dead-peer-detection - inventing a heartbeat protocol for this purpose seems an overkill. > But, more sophisticated implementations could also choose to create a > new SA with a 'back up peer' as one possible redundancy strategy. > Redundancy stragegies need not interoperate among vendors, but the dead > peer detection mechanism does need to interoperate. > Also, when a remote access client is builds an SA with an SGW, there is > an unignorable liklihood that the client may be shut down in non-clean > fashion (power off, kill process, unplug communications connection...) > In the abesnce of a dead peer detection mechanism, the SGW would > continue to believe that the client were present until it initiated a > re-key event. For gateways connecting thousands of clients, this leads > to very unattractive leaking of resourses. But more importantly, it > destroys auditing capabilities. An audit event for client connect and > client disconnect and loss of client are all deeply significant when you > are trying to tack who accessed what when for either legal or technical > reasons. IPSRA requires the capability to track connection start and end > time (NOTE: in the current rev of the draft draft-ietf-ipsra-reqmts > these are listed as Accounting requirements in section 2.4. But at the > IPSRA meeting, the acounting requirements got trimed but connection > start and stop survived as required audit events). > > > > Argument Against: > ================== > Its hard to do. We had trouble with this stuff back when we did TCP. > Also, IPsec WG has lasted a long time now and needs to close, we have a > steep prejudice against initiating any new work items. > > > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 -- sankar ramamoorthi email: sankar@nexsi.com phone: 408-579-5718 (w) From owner-ipsec@lists.tislabs.com Mon Aug 7 12:53:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03425; Mon, 7 Aug 2000 12:53:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29612 Mon, 7 Aug 2000 14:26:18 -0400 (EDT) Message-Id: <200008071835.e77IZNS111659@thunk.east.sun.com> From: Bill Sommerfeld To: "Scott G. Kelly" cc: sommerfeld@East.Sun.COM, Skip Booth , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-reply-to: Your message of "Mon, 07 Aug 2000 11:28:13 PDT." <398EFFBD.CD872DF6@redcreek.com> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 07 Aug 2000 14:35:23 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Yes, it was pointed out at the ipsra meeting that accounting is not a > requirement. However, what about auditing? For purposes of security > auditing, it is necessary to know when a remote access client > disconnects. Is this a valid requirement? Wouldn't keeping track of the last time an SA was used, and logging it into your audit trail when the SA expires or is deleted, be sufficient for auditing purposes? - Bill From owner-ipsec@lists.tislabs.com Mon Aug 7 12:56:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03489; Mon, 7 Aug 2000 12:56:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29575 Mon, 7 Aug 2000 14:20:38 -0400 (EDT) Message-ID: <398EFFBD.CD872DF6@redcreek.com> Date: Mon, 07 Aug 2000 11:28:13 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: sommerfeld@East.Sun.COM CC: Skip Booth , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <200008060352.e763qKS110811@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: > > > I would add a third reason for heartbeats/keepalives. To be able to do accurate > > accounting the SG needs to know within a reasonable time that the client has > > disconnected. > > I just re-read the ipsec and ipsra charters and saw no mention of > accounting as required functionality.. > > - Bill Yes, it was pointed out at the ipsra meeting that accounting is not a requirement. However, what about auditing? For purposes of security auditing, it is necessary to know when a remote access client disconnects. Is this a valid requirement? Scott From owner-ipsec@lists.tislabs.com Mon Aug 7 13:06:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03652; Mon, 7 Aug 2000 13:06:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29714 Mon, 7 Aug 2000 14:44:03 -0400 (EDT) From: jeff@allegrosys.com Message-ID: <20000807185658.4465.qmail@pb151.postoffice.net> Date: 7 Aug 00 18:56:58 GMT To: ipsec@lists.tislabs.com Subject: IV sizes for AES candidates X-Mailer: USANET web-mailer (MaintM3.3.0.77) 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 OAA29710 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is anyone working on drafts for ESP using the AES candidates? Is there a consensus that the IV part of the payload should be a number of 32bit words? Thanks, Jeff Enderwick jeff@allegrosys.com From owner-ipsec@lists.tislabs.com Mon Aug 7 13:08:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03684; Mon, 7 Aug 2000 13:08:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29791 Mon, 7 Aug 2000 14:56:16 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: jeff@allegrosys.com Cc: ipsec@lists.tislabs.com Subject: Re: IV sizes for AES candidates Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Aug 2000 15:06:08 -0400 Message-Id: <20000807190608.4A67835DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20000807185658.4465.qmail@pb151.postoffice.net>, jeff@allegrosys.co m writes: >Is anyone working on drafts for ESP using the AES candidates? > >Is there a consensus that the IV part of the payload should >be a number of 32bit words? The IV should be the same size as the ciphertext blocksize, which for AES is 16 bytes. (One could make some argument that one could stick with 8 bytes, and somehow expand it. That would make me nervous without some good analysis.) --Steve Bellovin From owner-ipsec@lists.tislabs.com Mon Aug 7 15:07:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06407; Mon, 7 Aug 2000 15:07:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01236 Mon, 7 Aug 2000 16:58:05 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "James M. Polk" Cc: jeff@allegrosys.com, ipsec@lists.tislabs.com Subject: Re: IV sizes for AES candidates Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Aug 2000 17:07:52 -0400 Message-Id: <20000807210753.1CBC435DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <4.1.20000807155937.01ada840@diablo.cisco.com>, "James M. Polk" writ es: >--=====================_1659831==_.ALT >Content-Type: text/plain; charset="us-ascii" > > >Steve > >16 bytes for 128bit ciphertext blocksize, right? It should be 24 and 32 for >192bit and 256bit, correct? Or is it always 16 (which I don't believe is >correct)? No, it's always 16 bytes for AES. The IV acts as a block of psuedo-ciphertext for purposes of the CBC calculation; it has nothing to do with key size. AES candidates all support 128, 192, and 256-bit keys, but use with variable block sizes is not standard and isn't supported by some of the finalists. To review: in CBC, ciphertext block i is produced from plaintext block i and ciphertext block i-1: C_i = E(K, P_i ^ C_{i-1}) But how do you encrypt the first plaintext block P_i? The answer is to use the IV: C_0 = IV. --Steve Bellovin From owner-ipsec@lists.tislabs.com Mon Aug 7 15:07:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06406; Mon, 7 Aug 2000 15:07:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01218 Mon, 7 Aug 2000 16:53:58 -0400 (EDT) Message-Id: <4.1.20000807155937.01ada840@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 Aug 2000 16:03:05 -0500 To: "Steven M. Bellovin" , jeff@allegrosys.com From: "James M. Polk" Subject: Re: IV sizes for AES candidates Cc: ipsec@lists.tislabs.com In-Reply-To: <20000807190608.4A67835DC2@smb.research.att.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1659831==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_1659831==_.ALT Content-Type: text/plain; charset="us-ascii" Steve 16 bytes for 128bit ciphertext blocksize, right? It should be 24 and 32 for 192bit and 256bit, correct? Or is it always 16 (which I don't believe is correct)? At 03:06 PM 8/7/2000 -0400, Steven M. Bellovin wrote: >In message <20000807185658.4465.qmail@pb151.postoffice.net>, jeff@allegrosys.co >m writes: >>Is anyone working on drafts for ESP using the AES candidates? >> >>Is there a consensus that the IV part of the payload should >>be a number of 32bit words? > >The IV should be the same size as the ciphertext blocksize, which for >AES is 16 bytes. (One could make some argument that one could stick >with 8 bytes, and somehow expand it. That would make me nervous >without some good analysis.) > > > --Steve Bellovin > > > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1659831==_.ALT Content-Type: text/html; charset="us-ascii"
Steve

16 bytes for 128bit ciphertext blocksize, right? It should be 24 and 32 for 192bit and 256bit, correct? Or is it always 16 (which I don't believe is correct)?

At 03:06 PM 8/7/2000 -0400, Steven M. Bellovin wrote:
>In message <20000807185658.4465.qmail@pb151.postoffice.net>, jeff@allegrosys.co
>m writes:
>>Is anyone working on drafts for ESP using the AES candidates?
>>
>>Is there a consensus that the IV part of the payload should
>>be a number of 32bit words?
>
>The IV should be the same size as the ciphertext blocksize, which for
>AES is 16 bytes.  (One could make some argument that one could stick
>with 8 bytes, and somehow expand it.  That would make me nervous
>without some good analysis.)
>
>
>               --Steve Bellovin
>
>
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1659831==_.ALT-- From owner-ipsec@lists.tislabs.com Mon Aug 7 15:08:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06459; Mon, 7 Aug 2000 15:08:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA01248 Mon, 7 Aug 2000 16:59:31 -0400 (EDT) Message-ID: <398F25FB.267FB2DC@cisco.com> Date: Mon, 07 Aug 2000 14:11:23 -0700 From: Scott Fanning X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sommerfeld@East.Sun.COM CC: "Scott G. Kelly" , Skip Booth , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <200008071835.e77IZNS111659@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Thats a good idea, but from an implementation point of view, I am not sure if I like the idea of maintaining a timestamp for every packet (SA Used) through a tunnel. I guess the problem I want to address with the heartbeats is dead-peer detection, and as a result do action foo. INITIAL-CONTACT does help in SADB sync'ing but is not authenticated and there is no assured delivery. I think that Scotts point of auditing is a good side-effect of dead-peer detection, and could also be tied to accounting, but I agree this is outside the scope of the problem. Scott Bill Sommerfeld wrote: > > > Yes, it was pointed out at the ipsra meeting that accounting is not a > > requirement. However, what about auditing? For purposes of security > > auditing, it is necessary to know when a remote access client > > disconnects. Is this a valid requirement? > > Wouldn't keeping track of the last time an SA was used, and logging it > into your audit trail when the SA expires or is deleted, be sufficient > for auditing purposes? > > - Bill From owner-ipsec@lists.tislabs.com Mon Aug 7 16:19:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07295; Mon, 7 Aug 2000 16:19:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01569 Mon, 7 Aug 2000 18:16:53 -0400 (EDT) To: Scott Fanning Cc: sommerfeld@East.Sun.COM, "Scott G. Kelly" , Skip Booth , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <200008071835.e77IZNS111659@thunk.east.sun.com> <398F25FB.267FB2DC@cisco.com> From: Derek Atkins Date: 07 Aug 2000 18:26:30 -0400 In-Reply-To: Scott Fanning's message of "Mon, 07 Aug 2000 14:11:23 -0700" Message-ID: Lines: 58 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The problem with dead-peer detection is that you have no way to know how or why a peer lost contact. You don't know if they got rebooted, lost power, lost connectivity, or some other reason. Perhaps your peer's upstream provider fell off the net? Or maybe it's a laptop and the laptop got unplugged and moved. The problem is you can't tell. Worse, in the case of an intermittent lossage, you really don't want to reap the SAs, because the peer might come back. If you're really that worried about the resources for "dead" SAs, negotiate relatively short rekey times, at which point if your peer disappears, the SA will timeout in a relatively short time. As has been mentioned, 'keep-alives' really equate to 'make-dead'. If you want to see if something is still there, why not just keep track of the last time a packet has been received on a particular SA and just send an ICMP ping_request? The ping_response will tell you your peer is alive, and you can update your SA time-of-last-packet to the current time. But what's the point of that? Short key lifetimes solves this problem. -derek Scott Fanning writes: > Bill > > Thats a good idea, but from an implementation point of view, I am not > sure if I like the idea of maintaining a timestamp for every packet (SA > Used) through a tunnel. > > I guess the problem I want to address with the heartbeats is dead-peer > detection, and as a result do action foo. INITIAL-CONTACT does help in > SADB sync'ing but is not authenticated and there is no assured delivery. > I think that Scotts point of auditing is a good side-effect of dead-peer > detection, and could also be tied to accounting, but I agree this is > outside the scope of the problem. > > Scott > > > Bill Sommerfeld wrote: > > > > > Yes, it was pointed out at the ipsra meeting that accounting is not a > > > requirement. However, what about auditing? For purposes of security > > > auditing, it is necessary to know when a remote access client > > > disconnects. Is this a valid requirement? > > > > Wouldn't keeping track of the last time an SA was used, and logging it > > into your audit trail when the SA expires or is deleted, be sufficient > > for auditing purposes? > > > > - Bill -- 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 N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Aug 7 16:55:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA07988; Mon, 7 Aug 2000 16:55:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA01624 Mon, 7 Aug 2000 18:43:27 -0400 (EDT) Message-ID: <398F3E59.2DBC13D2@cisco.com> Date: Mon, 07 Aug 2000 15:55:21 -0700 From: Scott Fanning X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Derek Atkins CC: sommerfeld@East.Sun.COM, "Scott G. Kelly" , Skip Booth , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <200008071835.e77IZNS111659@thunk.east.sun.com> <398F25FB.267FB2DC@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins wrote: > > The problem with dead-peer detection is that you have no way to know > how or why a peer lost contact. You don't know if they got rebooted, > lost power, lost connectivity, or some other reason. Perhaps your > peer's upstream provider fell off the net? Or maybe it's a laptop and > the laptop got unplugged and moved. The problem is you can't tell. > Worse, in the case of an intermittent lossage, you really don't want > to reap the SAs, because the peer might come back. I do not really care WHY it is dead. The end result is some clean up of the SADB and aMaybe we need a "death certificate" CA :-) Intermittent lossage can be solved by having a window of missed "heartbeats". Idle timers could also help, but you would need to know the traffic type to configure those correctly (kind of a layer violation). > > If you're really that worried about the resources for "dead" SAs, > negotiate relatively short rekey times, at which point if your peer > disappears, the SA will timeout in a relatively short time. > > As has been mentioned, 'keep-alives' really equate to 'make-dead'. If > you want to see if something is still there, why not just keep track > of the last time a packet has been received on a particular SA and > just send an ICMP ping_request? The ping_response will tell you your > peer is alive, and you can update your SA time-of-last-packet to the > current time. But what's the point of that? Short key lifetimes > solves this problem. Short Key lifetimes do solve some of the problem, but can be expensive. During the IKE rework, maybe some of these issues can be addressed. This is quite an interesting problem to solve. > > -derek > > Scott Fanning writes: > > > Bill > > > > Thats a good idea, but from an implementation point of view, I am not > > sure if I like the idea of maintaining a timestamp for every packet (SA > > Used) through a tunnel. > > > > I guess the problem I want to address with the heartbeats is dead-peer > > detection, and as a result do action foo. INITIAL-CONTACT does help in > > SADB sync'ing but is not authenticated and there is no assured delivery. > > I think that Scotts point of auditing is a good side-effect of dead-peer > > detection, and could also be tied to accounting, but I agree this is > > outside the scope of the problem. > > > > Scott > > > > > > Bill Sommerfeld wrote: > > > > > > > Yes, it was pointed out at the ipsra meeting that accounting is not a > > > > requirement. However, what about auditing? For purposes of security > > > > auditing, it is necessary to know when a remote access client > > > > disconnects. Is this a valid requirement? > > > > > > Wouldn't keeping track of the last time an SA was used, and logging it > > > into your audit trail when the SA expires or is deleted, be sufficient > > > for auditing purposes? > > > > > > - Bill > > -- > 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 N1NWH > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Aug 7 16:57:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08074; Mon, 7 Aug 2000 16:57:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01666 Mon, 7 Aug 2000 19:00:45 -0400 (EDT) Message-Id: <200008072309.e77N9oS111935@thunk.east.sun.com> From: Bill Sommerfeld To: Scott Fanning cc: Derek Atkins , sommerfeld@East.Sun.COM, "Scott G. Kelly" , Skip Booth , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-reply-to: Your message of "Mon, 07 Aug 2000 15:55:21 PDT." <398F3E59.2DBC13D2@cisco.com> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 07 Aug 2000 19:09:50 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Maybe we need a "death certificate" CA :-) Heh. Actually, one of the ideas I'm kicking around: If we have the system sign a "birth certificate" when it reboots (including a reboot time or boot sequence number), we could include that with a "bad spi" ICMP error and in the negotiation of the IKE SA. This pushes the burden of reestablishing state to the end which already thinks it has shared state and has traffic it wants to send. The system which is receiving packets to unknown spi's merely has to respond with a simple message which involves no real-time cryptography (it should, of course, be rate limited). The system receiving the error message can discard it if it doesn't correspond to existing state or if it's "old news" (i.e., you get replay protection); if it's not old news, you can rate-limit how often you attempt to verify the signature. I *think* this is relatively resistant to replay and DoS... - Bill From owner-ipsec@lists.tislabs.com Mon Aug 7 17:35:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08656; Mon, 7 Aug 2000 17:35:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01790 Mon, 7 Aug 2000 19:38:13 -0400 (EDT) Message-Id: <200008072342.QAA22988@potassium.network-alchemy.com> To: Scott Fanning cc: Derek Atkins , sommerfeld@East.Sun.COM, "Scott G. Kelly" , Skip Booth , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-reply-to: Your message of "Mon, 07 Aug 2000 15:55:21 PDT." <398F3E59.2DBC13D2@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22985.965691775.1@network-alchemy.com> Date: Mon, 07 Aug 2000 16:42:56 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The only implementation of keepalives that I'm aware of is Cisco's and it doesn't scale. This was discussed in Adelaide by Chinna Narasimha Reddy Pellacuru. That implementation may have problems-- I wrote it after all-- but a solution to its problems has not been discussed and both drafts which address keepalives/heartbeats are essentially what I implemented in IOS: a simple request/response, "are you there?"/"yes, I'm here". Has Cisco's version been fixed to scale? If so, can you explain how so that that information can be incorporated into the drafts? If not, then perhaps we should take a step back and look at what it is we're doing since we have evidence that what is being proposed doesn't work right. It's an interesting question about addressing keepalives in the "IKE rework". But doesn't this change IKE? Come to think of it, aren't keepalives officially prohibited until the "IKE rework" is finished? Dan. On Mon, 07 Aug 2000 15:55:21 PDT you wrote > Derek Atkins wrote: > > > > The problem with dead-peer detection is that you have no way to know > > how or why a peer lost contact. You don't know if they got rebooted, > > lost power, lost connectivity, or some other reason. Perhaps your > > peer's upstream provider fell off the net? Or maybe it's a laptop and > > the laptop got unplugged and moved. The problem is you can't tell. > > Worse, in the case of an intermittent lossage, you really don't want > > to reap the SAs, because the peer might come back. > > I do not really care WHY it is dead. The end result is some clean up of > the SADB and aMaybe we need a "death certificate" CA :-) Intermittent > lossage can be solved by having a window of missed "heartbeats". Idle > timers could also help, but you would need to know the traffic type to > configure those correctly (kind of a layer violation). > > > > > If you're really that worried about the resources for "dead" SAs, > > negotiate relatively short rekey times, at which point if your peer > > disappears, the SA will timeout in a relatively short time. > > > > As has been mentioned, 'keep-alives' really equate to 'make-dead'. If > > you want to see if something is still there, why not just keep track > > of the last time a packet has been received on a particular SA and > > just send an ICMP ping_request? The ping_response will tell you your > > peer is alive, and you can update your SA time-of-last-packet to the > > current time. But what's the point of that? Short key lifetimes > > solves this problem. > > Short Key lifetimes do solve some of the problem, but can be expensive. > > During the IKE rework, maybe some of these issues can be addressed. This > is quite an interesting problem to solve. > > > > > -derek > > > > Scott Fanning writes: > > > > > Bill > > > > > > Thats a good idea, but from an implementation point of view, I am not > > > sure if I like the idea of maintaining a timestamp for every packet (SA > > > Used) through a tunnel. > > > > > > I guess the problem I want to address with the heartbeats is dead-peer > > > detection, and as a result do action foo. INITIAL-CONTACT does help in > > > SADB sync'ing but is not authenticated and there is no assured delivery. > > > I think that Scotts point of auditing is a good side-effect of dead-peer > > > detection, and could also be tied to accounting, but I agree this is > > > outside the scope of the problem. > > > > > > Scott > > > > > > > > > Bill Sommerfeld wrote: > > > > > > > > > Yes, it was pointed out at the ipsra meeting that accounting is not a > > > > > requirement. However, what about auditing? For purposes of security > > > > > auditing, it is necessary to know when a remote access client > > > > > disconnects. Is this a valid requirement? > > > > > > > > Wouldn't keeping track of the last time an SA was used, and logging it > > > > into your audit trail when the SA expires or is deleted, be sufficient > > > > for auditing purposes? > > > > > > > > - Bill > > > > -- > > 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 N1NWH > > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Aug 7 17:53:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA08879; Mon, 7 Aug 2000 17:53:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01822 Mon, 7 Aug 2000 19:46:48 -0400 (EDT) Message-ID: <398F4D4F.89D56970@cisco.com> Date: Mon, 07 Aug 2000 16:59:11 -0700 From: Scott Fanning X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: Derek Atkins , sommerfeld@East.Sun.COM, "Scott G. Kelly" , Skip Booth , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <200008072342.QAA22988@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scaling is an issue, and we are working on some ideas. We need a standards based one, and I know that we are committed towards that. I am interested in other vendors who have ideas in this area, but it sounds like Nortel has a wide ranging patent on this. Does anyone know what this patent is and the number? Scott Dan Harkins wrote: > > The only implementation of keepalives that I'm aware of is Cisco's > and it doesn't scale. This was discussed in Adelaide by Chinna > Narasimha Reddy Pellacuru. That implementation may have problems-- I > wrote it after all-- but a solution to its problems has not been > discussed and both drafts which address keepalives/heartbeats are > essentially what I implemented in IOS: a simple request/response, > "are you there?"/"yes, I'm here". Has Cisco's version been fixed to > scale? If so, can you explain how so that that information can be > incorporated into the drafts? If not, then perhaps we should take a > step back and look at what it is we're doing since we have evidence > that what is being proposed doesn't work right. > > It's an interesting question about addressing keepalives in the > "IKE rework". But doesn't this change IKE? Come to think of it, aren't > keepalives officially prohibited until the "IKE rework" is finished? > > Dan. > > On Mon, 07 Aug 2000 15:55:21 PDT you wrote > > Derek Atkins wrote: > > > > > > The problem with dead-peer detection is that you have no way to know > > > how or why a peer lost contact. You don't know if they got rebooted, > > > lost power, lost connectivity, or some other reason. Perhaps your > > > peer's upstream provider fell off the net? Or maybe it's a laptop and > > > the laptop got unplugged and moved. The problem is you can't tell. > > > Worse, in the case of an intermittent lossage, you really don't want > > > to reap the SAs, because the peer might come back. > > > > I do not really care WHY it is dead. The end result is some clean up of > > the SADB and aMaybe we need a "death certificate" CA :-) Intermittent > > lossage can be solved by having a window of missed "heartbeats". Idle > > timers could also help, but you would need to know the traffic type to > > configure those correctly (kind of a layer violation). > > > > > > > > If you're really that worried about the resources for "dead" SAs, > > > negotiate relatively short rekey times, at which point if your peer > > > disappears, the SA will timeout in a relatively short time. > > > > > > As has been mentioned, 'keep-alives' really equate to 'make-dead'. If > > > you want to see if something is still there, why not just keep track > > > of the last time a packet has been received on a particular SA and > > > just send an ICMP ping_request? The ping_response will tell you your > > > peer is alive, and you can update your SA time-of-last-packet to the > > > current time. But what's the point of that? Short key lifetimes > > > solves this problem. > > > > Short Key lifetimes do solve some of the problem, but can be expensive. > > > > During the IKE rework, maybe some of these issues can be addressed. This > > is quite an interesting problem to solve. > > > > > > > > -derek > > > > > > Scott Fanning writes: > > > > > > > Bill > > > > > > > > Thats a good idea, but from an implementation point of view, I am not > > > > sure if I like the idea of maintaining a timestamp for every packet (SA > > > > Used) through a tunnel. > > > > > > > > I guess the problem I want to address with the heartbeats is dead-peer > > > > detection, and as a result do action foo. INITIAL-CONTACT does help in > > > > SADB sync'ing but is not authenticated and there is no assured delivery. > > > > I think that Scotts point of auditing is a good side-effect of dead-peer > > > > detection, and could also be tied to accounting, but I agree this is > > > > outside the scope of the problem. > > > > > > > > Scott > > > > > > > > > > > > Bill Sommerfeld wrote: > > > > > > > > > > > Yes, it was pointed out at the ipsra meeting that accounting is not a > > > > > > requirement. However, what about auditing? For purposes of security > > > > > > auditing, it is necessary to know when a remote access client > > > > > > disconnects. Is this a valid requirement? > > > > > > > > > > Wouldn't keeping track of the last time an SA was used, and logging it > > > > > into your audit trail when the SA expires or is deleted, be sufficient > > > > > for auditing purposes? > > > > > > > > > > - Bill > > > > > > -- > > > 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 N1NWH > > > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Aug 7 18:25:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11978; Mon, 7 Aug 2000 18:25:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02044 Mon, 7 Aug 2000 20:24:37 -0400 (EDT) Date: Mon, 7 Aug 2000 17:32:08 -0700 (PDT) From: Jan Vilhuber To: Dan Harkins cc: Scott Fanning , Derek Atkins , sommerfeld@East.Sun.COM, "Scott G. Kelly" , Skip Booth , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <200008072342.QAA22988@potassium.network-alchemy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 7 Aug 2000, Dan Harkins wrote: > The only implementation of keepalives that I'm aware of is Cisco's > and it doesn't scale. This was discussed in Adelaide by Chinna > Narasimha Reddy Pellacuru. That implementation may have problems-- I > wrote it after all-- but a solution to its problems has not been > discussed and both drafts which address keepalives/heartbeats are > essentially what I implemented in IOS: a simple request/response, > "are you there?"/"yes, I'm here". Has Cisco's version been fixed to > scale? Not to my knowledge. I've rewritten it quite extensively in an attempt to make it 'better', but fundametally it's still what you wrote, and it still doesn't scale all that well. > If so, can you explain how so that that information can be > incorporated into the drafts? If not, then perhaps we should take a > step back and look at what it is we're doing since we have evidence > that what is being proposed doesn't work right. > I guess if you have a good fast hardware adapater, and more importantly a fast PATH to the HW and back, then keepalives could work better. Our implementation in some extreme cases bogs down trying to catch up with the thousands of keepalives that are being sent to it. Nevermind that the defaults (10 2) you put in place don't help ;) If a peer didn't respond in 10 seconds (possibly because he's swamped with other keepalives), sending them at a 2 second interval doesn't improve that situation. Changing this to exponential backoff may help, and treating heartbeats as a 'prioritized' packet MAY help (although I can come up with some interesting race conditions that way), but ultimately you have LOTS of tiny encrypted packets that you need to decrypt and encrypt (on reply), which bogs down the machine. My 2c.. jan > It's an interesting question about addressing keepalives in the > "IKE rework". But doesn't this change IKE? Come to think of it, aren't > keepalives officially prohibited until the "IKE rework" is finished? > > Dan. > > On Mon, 07 Aug 2000 15:55:21 PDT you wrote > > Derek Atkins wrote: > > > > > > The problem with dead-peer detection is that you have no way to know > > > how or why a peer lost contact. You don't know if they got rebooted, > > > lost power, lost connectivity, or some other reason. Perhaps your > > > peer's upstream provider fell off the net? Or maybe it's a laptop and > > > the laptop got unplugged and moved. The problem is you can't tell. > > > Worse, in the case of an intermittent lossage, you really don't want > > > to reap the SAs, because the peer might come back. > > > > I do not really care WHY it is dead. The end result is some clean up of > > the SADB and aMaybe we need a "death certificate" CA :-) Intermittent > > lossage can be solved by having a window of missed "heartbeats". Idle > > timers could also help, but you would need to know the traffic type to > > configure those correctly (kind of a layer violation). > > > > > > > > If you're really that worried about the resources for "dead" SAs, > > > negotiate relatively short rekey times, at which point if your peer > > > disappears, the SA will timeout in a relatively short time. > > > > > > As has been mentioned, 'keep-alives' really equate to 'make-dead'. If > > > you want to see if something is still there, why not just keep track > > > of the last time a packet has been received on a particular SA and > > > just send an ICMP ping_request? The ping_response will tell you your > > > peer is alive, and you can update your SA time-of-last-packet to the > > > current time. But what's the point of that? Short key lifetimes > > > solves this problem. > > > > Short Key lifetimes do solve some of the problem, but can be expensive. > > > > During the IKE rework, maybe some of these issues can be addressed. This > > is quite an interesting problem to solve. > > > > > > > > -derek > > > > > > Scott Fanning writes: > > > > > > > Bill > > > > > > > > Thats a good idea, but from an implementation point of view, I am not > > > > sure if I like the idea of maintaining a timestamp for every packet (SA > > > > Used) through a tunnel. > > > > > > > > I guess the problem I want to address with the heartbeats is dead-peer > > > > detection, and as a result do action foo. INITIAL-CONTACT does help in > > > > SADB sync'ing but is not authenticated and there is no assured delivery. > > > > I think that Scotts point of auditing is a good side-effect of dead-peer > > > > detection, and could also be tied to accounting, but I agree this is > > > > outside the scope of the problem. > > > > > > > > Scott > > > > > > > > > > > > Bill Sommerfeld wrote: > > > > > > > > > > > Yes, it was pointed out at the ipsra meeting that accounting is not a > > > > > > requirement. However, what about auditing? For purposes of security > > > > > > auditing, it is necessary to know when a remote access client > > > > > > disconnects. Is this a valid requirement? > > > > > > > > > > Wouldn't keeping track of the last time an SA was used, and logging it > > > > > into your audit trail when the SA expires or is deleted, be sufficient > > > > > for auditing purposes? > > > > > > > > > > - Bill > > > > > > -- > > > 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 N1NWH > > > warlord@MIT.EDU PGP key available > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Aug 7 18:25:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11975; Mon, 7 Aug 2000 18:25:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02053 Mon, 7 Aug 2000 20:25:20 -0400 (EDT) Date: Mon, 7 Aug 2000 17:34:44 -0700 (PDT) From: Jan Vilhuber To: Ricky Charlet cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <398ED3B9.3600EADC@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 7 Aug 2000, Ricky Charlet wrote: > Argument in favor: > ================== > IPsec creates black holes. Side question: Doesn't EVERY tunnelling mechanism have this problem? Or is it just ipsec? If just ipsec, why is that (selectors?). Why is this not solvable by routing, which, afterall, does things like HELLO messages (OSPF I think). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Aug 7 21:09:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA22994; Mon, 7 Aug 2000 21:09:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA02314 Mon, 7 Aug 2000 22:40:16 -0400 (EDT) Date: Mon, 7 Aug 2000 22:50:02 -0400 Message-Id: <200008080250.WAA03214@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: sommerfeld@East.Sun.COM CC: Scott Fanning , Derek Atkins , sommerfeld@East.Sun.COM, "Scott G. Kelly" , Skip Booth , Paul Hoffman , ipsec@lists.tislabs.com In-reply-to: Bill Sommerfeld's message of Mon, 07 Aug 2000 19:09:50 -0400, <200008072309.e77N9oS111935@thunk.east.sun.com> Subject: Re: Heartbeats Straw Poll Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: Bill Sommerfeld Date: Mon, 07 Aug 2000 19:09:50 -0400 Heh. Actually, one of the ideas I'm kicking around: If we have the system sign a "birth certificate" when it reboots (including a reboot time or boot sequence number), we could include that with a "bad spi" ICMP error and in the negotiation of the IKE SA. This pushes the burden of reestablishing state to the end which already thinks it has shared state and has traffic it wants to send. The system which is receiving packets to unknown spi's merely has to respond with a simple message which involves no real-time cryptography (it should, of course, be rate limited). The system receiving the error message can discard it if it doesn't correspond to existing state or if it's "old news" (i.e., you get replay protection); if it's not old news, you can rate-limit how often you attempt to verify the signature. (with my wg-chair hat off) I like this idea lot. It solves the problem quite nicely, without having to deal with the complexities of negotiating whether or not to do heartbeats, and it avoids the possibility that a temporary less of connectivity (perhaps caused by a lame LAN emulation over an ATM backbone :-) causes a SA to get unnecessarily flushed. The key here is that it distinguishes between temporary loss of network connectivity from a peer reboot (and loss of IPSEC state). There are other ways of getting the same result: You could double check the loss of a hearbeat by attempting an unsecured ping to the IPSEC endpoint. If the ping works, but the heartbeat doesn't, then it's likely the that communications peer has lost its state, and you need to flush all of the SA's and renegotiate them. On the other hand, if you can't ping your peer, it's probably just a random network outage, and it's better to *not* flush the SA state in that case. Still, Bill's approach is much cleaner, and much simpler. - Ted From owner-ipsec@lists.tislabs.com Mon Aug 7 22:11:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA25700; Mon, 7 Aug 2000 22:11:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02459 Mon, 7 Aug 2000 23:54:13 -0400 (EDT) Date: Tue, 8 Aug 2000 00:01:57 -0400 (EDT) From: Skip Booth To: "Theodore Y. Ts'o" cc: sommerfeld@East.Sun.COM, Scott Fanning , Derek Atkins , "Scott G. Kelly" , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <200008080250.WAA03214@tsx-prime.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 7 Aug 2000, Theodore Y. Ts'o wrote: > From: Bill Sommerfeld > Date: Mon, 07 Aug 2000 19:09:50 -0400 > > Heh. Actually, one of the ideas I'm kicking around: > > If we have the system sign a "birth certificate" when it reboots > (including a reboot time or boot sequence number), we could include > that with a "bad spi" ICMP error and in the negotiation of the IKE SA. > > This pushes the burden of reestablishing state to the end which > already thinks it has shared state and has traffic it wants to send. > > The system which is receiving packets to unknown spi's merely has to > respond with a simple message which involves no real-time cryptography > (it should, of course, be rate limited). > > The system receiving the error message can discard it if it doesn't > correspond to existing state or if it's "old news" (i.e., you get > replay protection); if it's not old news, you can rate-limit how often > you attempt to verify the signature. > > (with my wg-chair hat off) > > I like this idea lot. It solves the problem quite nicely, without > having to deal with the complexities of negotiating whether or not to do > heartbeats, and it avoids the possibility that a temporary less of > connectivity (perhaps caused by a lame LAN emulation over an ATM > backbone :-) causes a SA to get unnecessarily flushed. If I understand this proposal correctly, it depends on the SG which still has state to be transmitting data. In a client to SG scenario, most of the traffic from the SG to the client will only occur as the result of the client making some transaction request. Thus when the client disconnects, there is a high probability that no traffic will flow in the direction of the client. This mechanism doesn't seem to allow the SG to reliably determine when the peer has lost state. > > The key here is that it distinguishes between temporary loss of network > connectivity from a peer reboot (and loss of IPSEC state). There are > other ways of getting the same result: You could double check the loss > of a hearbeat by attempting an unsecured ping to the IPSEC endpoint. If > the ping works, but the heartbeat doesn't, then it's likely the that > communications peer has lost its state, and you need to flush all of the > SA's and renegotiate them. On the other hand, if you can't ping your > peer, it's probably just a random network outage, and it's better to > *not* flush the SA state in that case. A ping to an IP address which previously was your peer just doesn't work. The only thing that uniquely identifies your peer is the cryptographic information used to identify him and the keys negotiated during SA establishment. You just can't make an assumption that the IP address is still valid. In a dynamic address assignment world, after the peer disconnects the address is either going to be used by someone else (who you don't trust yet) or is going to be unused. IMO, any "ping" must be bound to the SA for it to have any value whatsoever. It seems to me that the only solution which has been proposed that has merits over any keepalive proposal is short SA lifetimes. This is obviously the easiest proposal to implement, however I am not sure I am crazy about refreshing my keys every 1 to 2 minutes, especially if I am configured for PFS and am terminating 1000's of tunnels. -Skip > > Still, Bill's approach is much cleaner, and much simpler. > > - Ted > > From owner-ipsec@lists.tislabs.com Mon Aug 7 22:16:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA25989; Mon, 7 Aug 2000 22:16:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA02509 Tue, 8 Aug 2000 00:20:00 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Skip Booth Cc: "Theodore Y. Ts'o" , sommerfeld@East.Sun.COM, Scott Fanning , Derek Atkins , "Scott G. Kelly" , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Aug 2000 00:29:49 -0400 Message-Id: <20000808042954.D4AA135DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Skip Boo th writes: >If I understand this proposal correctly, it depends on the SG which still has >state to be transmitting data. In a client to SG scenario, most of the traffi >c >from the SG to the client will only occur as the result of the client making >some transaction request. Thus when the client disconnects, there is a high >probability that no traffic will flow in the direction of the client. This >mechanism doesn't seem to allow the SG to reliably determine when the peer has >lost state. Right -- but I still don't understand why it matters that much. As you say, the client will initiate most transfers, so it will know if things are dead, and hence if renegotiation is needed. Why does the server even care? Keep-alives are most important if a dead session is consuming critical resources. What resources are these? Memory is very cheap these days, much cheaper than programmer time to hack IKE. (To say nothing of WG time to consider the changes to IKE...) Accounting? Apart from the fact that I don't even understand what resource you're accounting for, you can always record the timestamp of the last packet received on an SA. That's cheap and easy; you're already doing far more processing than that per received packet. If you really need to know if an SA is dead, use a layered solution. The IPsec endpoint can periodically send a protected ICMP ECHO to the far end. If it is acknowledged, all is well. More generally, *any* traffic received can reset the timer. If m pings in a row are lost, throw away the SA and let any new traffic from your side create a new one. The far side can run the same protocol; if your side discards its half of the SA, the far side won't receive any response to its pings, so it will tear down its side as well. The really interesting question, to me, is what should happen when a new SA is created with the same SPD data as an existing one. That is, what happens when one side thinks things are dead and tries to create a new SA, while the other side thinks things are fine. That can happen with my proposal and with keep-alives -- the condition that creates any sort of keep-alive failure is a loss of communications. Btw -- any sort of keep-alive, whether at the IKE level or not, can defeat port idle timers. This in turn can lead to overconsumption of two different resources that are in short supply: modem ports on the terminal server, and the money used to pay hotels that charge for overly-long calls. (We won't even discuss ISPs that charge by byte volume....) --Steve Bellovin From owner-ipsec@lists.tislabs.com Mon Aug 7 22:41:12 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28289; Mon, 7 Aug 2000 22:41:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA02542 Tue, 8 Aug 2000 00:40:41 -0400 (EDT) Date: Tue, 8 Aug 2000 00:48:36 -0400 (EDT) From: Skip Booth To: "Steven M. Bellovin" cc: "Theodore Y. Ts'o" , sommerfeld@East.Sun.COM, Scott Fanning , Derek Atkins , "Scott G. Kelly" , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <20000808042954.D4AA135DC2@smb.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 8 Aug 2000, Steven M. Bellovin wrote: > In message , Skip Boo > th writes: > > > >If I understand this proposal correctly, it depends on the SG which still has > >state to be transmitting data. In a client to SG scenario, most of the traffi > >c > >from the SG to the client will only occur as the result of the client making > >some transaction request. Thus when the client disconnects, there is a high > >probability that no traffic will flow in the direction of the client. This > >mechanism doesn't seem to allow the SG to reliably determine when the peer has > >lost state. > > Right -- but I still don't understand why it matters that much. As you > say, the client will initiate most transfers, so it will know if things > are dead, and hence if renegotiation is needed. Why does the server > even care? The server cares because it has to do things like stop accounting (a very important remote access function) and return IP addresses back to the DHCP server or to it's local pool. It is critical that the IP addresses are returned ASAP after the client has disconnected so they can be reused for the next client. > Keep-alives are most important if a dead session is consuming critical > resources. What resources are these? Memory is very cheap these days, > much cheaper than programmer time to hack IKE. (To say nothing of WG > time to consider the changes to IKE...) Accounting? Apart from the > fact that I don't even understand what resource you're accounting for, The same resources that we have been tracking for many years now. Duration of the call being of primary importance, bytes in/out, disconnect reason, etc. > you can always record the timestamp of the last packet received on an > SA. That's cheap and easy; you're already doing far more processing > than that per received packet. Not necessary cheap since it does effect your per-packet code path, but considering how much work goes into each packet for IPsec, I'll give you that one. However this algorithm is not accurate enough to serve the purposes of accounting or IP address management. > > If you really need to know if an SA is dead, use a layered solution. > The IPsec endpoint can periodically send a protected ICMP ECHO to the > far end. If it is acknowledged, all is well. More generally, *any* > traffic received can reset the timer. If m pings in a row are lost, > throw away the SA and let any new traffic from your side create a new > one. The far side can run the same protocol; if your side discards its > half of the SA, the far side won't receive any response to its pings, > so it will tear down its side as well. This is a fair proposal and one that has been made before if memory serves me correctly. It is simply a keepalive mechanism, albeit one that doesn't require any change to IKE which is probably a good thing. However it does double the number of SAs a box must terminate in the remote access scenario. > > The really interesting question, to me, is what should happen when a > new SA is created with the same SPD data as an existing one. That is, > what happens when one side thinks things are dead and tries to create a > new SA, while the other side thinks things are fine. That can happen > with my proposal and with keep-alives -- the condition that creates any > sort of keep-alive failure is a loss of communications. I would hope the original is destroyed. This really shouldn't be any different than a new phase 1/2 SA negotiation sequence with a peer which didn't receive the SA delete messages. > > Btw -- any sort of keep-alive, whether at the IKE level or not, can > defeat port idle timers. This in turn can lead to overconsumption of > two different resources that are in short supply: modem ports on the > terminal server, and the money used to pay hotels that charge for > overly-long calls. (We won't even discuss ISPs that charge by byte > volume....) Agreed. -Skip > > --Steve Bellovin > > > > From owner-ipsec@lists.tislabs.com Tue Aug 8 06:19:25 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25337; Tue, 8 Aug 2000 06:19:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03687 Tue, 8 Aug 2000 07:51:25 -0400 (EDT) Message-Id: <3.0.2.32.20000808075611.0072ab24@email.nist.gov> X-Sender: sfrankel@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 08 Aug 2000 07:56:11 -0400 To: jeff@allegrosys.com From: Sheila Frankel Subject: Re: IV sizes for AES candidates Cc: ipsec@lists.tislabs.com In-Reply-To: <20000807185658.4465.qmail@pb151.postoffice.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There is a draft, "The Candidate AES Cipher Algorithms and Their Use with IPsec," , that describes the AES finalists and how to fit them into AH/ESP/IKE. It mandates an IV size equal to the block size (16 bytes). The draft expires in September, so hopefully the next version will have the actual AES algorithm(s). Sheila Frankel sheila.frankel@nist.gov At 06:56 PM 8/7/00 GMT, you wrote: >Is anyone working on drafts for ESP using the AES candidates? > >Is there a consensus that the IV part of the payload should >be a number of 32bit words? > >Thanks, > >Jeff Enderwick >jeff@allegrosys.com > > > From owner-ipsec@lists.tislabs.com Tue Aug 8 08:42:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09052; Tue, 8 Aug 2000 08:42:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA04405 Tue, 8 Aug 2000 10:30:08 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Sheila Frankel Cc: jeff@allegrosys.com, ipsec@lists.tislabs.com Subject: Re: IV sizes for AES candidates Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Aug 2000 10:39:57 -0400 Message-Id: <20000808143958.3AA8F35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3.0.2.32.20000808075611.0072ab24@email.nist.gov>, Sheila Frankel wr ites: >There is a draft, "The Candidate AES Cipher Algorithms and Their Use with >IPsec," , that describes the AES >finalists and how to fit them into AH/ESP/IKE. It mandates an IV size equal >to the block size (16 bytes). The draft expires in September, so hopefully >the next version will have the actual AES algorithm(s). The draft makes several points that deserve discussion on this list. For one, it asks about different modes of operation instead of DES. I suspect that the same pressures that are pushing NIST to hold a modes of operation workshop in October (http://csrc.nist.gov/encryption/aes/modes/), but I think that that question is (almost) orthogonal to the choice of underlying block cipher. There are a fair number of subtle issues in mode of operation design, and I don't think that the IETF is the right issue to explore ost of them. (Practical or implementation aspects are, of course, something we're good at.) The modulus sizes suggested for different key lengths are quite high, and I wonder if they're realistic. I mean, a 15430 bit modulus for Diffie-Hellman is just not going to happen. I'm particularly concerned by this sentence: Implementations are encouraged to use the largest key sizes they can when taking into account performance considerations for their partic- ular hardware and software configuration. It isn't clear to me that there is any real security gain from using a 256-bit symmetric key instead of a 128-bit key, and I don't know that we should be encouraging it. After all, the expense is borne by two systems, not just one. --Steve Bellovin From owner-ipsec@lists.tislabs.com Tue Aug 8 09:08:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09927; Tue, 8 Aug 2000 09:08:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04574 Tue, 8 Aug 2000 11:01:55 -0400 (EDT) Message-Id: <3.0.2.32.20000808110644.007346a0@email.nist.gov> X-Sender: sfrankel@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 08 Aug 2000 11:06:44 -0400 To: "Steven M. Bellovin" From: Sheila Frankel Subject: Re: IV sizes for AES candidates Cc: ipsec@lists.tislabs.com In-Reply-To: <20000808143958.3AA8F35DC2@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >For one, it asks about different modes of operation instead of DES. I >suspect that the same pressures that are pushing NIST to hold a modes >of operation workshop in October (http://csrc.nist.gov/encryption/aes/modes/), >but I think that that question is (almost) orthogonal to the choice of >underlying block cipher. There are a fair number of subtle issues in >mode of operation design, and I don't think that the IETF is the right >issue to explore ost of them. (Practical or implementation aspects >are, of course, something we're good at.) If the consensus of the group is that we should stick with the tried-and-true CBC mode, that's fine with us, and the next version of the draft will reflect that. > >The modulus sizes suggested for different key lengths are quite high, >and I wonder if they're realistic. I mean, a 15430 bit modulus for >Diffie-Hellman is just not going to happen. I'm particularly concerned >by this sentence: > > Implementations are encouraged to use the largest key sizes they can > when taking into account performance considerations for their partic- > ular hardware and software configuration. > >It isn't clear to me that there is any real security gain from using a >256-bit symmetric key instead of a 128-bit key, and I don't know that >we should be encouraging it. After all, the expense is borne by two >systems, not just one. > > --Steve Bellovin > I guess that statement should be toned down - out of context it does sound like overkill. The only keysize required by the draft is 128 bits; the others are optional. We are interested in comments from the list - should the other key sizes be mentioned at all? any other comments on the "IKE Interactions" section? By the way, has anyone else implemented any of the AES candidates in IPsec and/or IKE? Sheila Frankel sheila.frankel@nist.gov From owner-ipsec@lists.tislabs.com Tue Aug 8 09:17:04 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10650; Tue, 8 Aug 2000 09:17:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04655 Tue, 8 Aug 2000 11:14:39 -0400 (EDT) Message-Id: <200008081524.LAA08525@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: Your message of "Mon, 07 Aug 2000 14:11:23 PDT." <398F25FB.267FB2DC@cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 08 Aug 2000 11:24:13 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Scott" == Scott Fanning writes: Scott> Thats a good idea, but from an implementation point of view, I am Scott> not sure if I like the idea of maintaining a timestamp for every Scott> packet (SA Used) through a tunnel. I can see that if you have a hardware forwarding plane, that this might be a pain. Scott> I guess the problem I want to address with the heartbeats is Scott> dead-peer detection, and as a result do action Scott> foo. INITIAL-CONTACT does help in SADB sync'ing but is not You still have to maintain a timestamp for each heartbeat! If you have hardware forwarding plane, and it does LRU, then you can just keep a stamp of the last time you had to load that SA. If you don't have enough active connections to actually cause your hardware to cause cache misses, you can push SAs out of your hardware on a roundrobin fashion to see if this causes a miss. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Tue Aug 8 09:24:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11033; Tue, 8 Aug 2000 09:24:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04702 Tue, 8 Aug 2000 11:20:17 -0400 (EDT) Message-Id: <200008081530.LAA08656@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: Your message of "Mon, 07 Aug 2000 19:09:50 EDT." <200008072309.e77N9oS111935@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 08 Aug 2000 11:30:09 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Bill" == Bill Sommerfeld writes: Bill> If we have the system sign a "birth certificate" when it reboots Bill> (including a reboot time or boot sequence number), we could include Bill> that with a "bad spi" ICMP error and in the negotiation of the IKE Bill> SA. This is a really good idea. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Tue Aug 8 09:25:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11055; Tue, 8 Aug 2000 09:25:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04738 Tue, 8 Aug 2000 11:29:15 -0400 (EDT) Message-Id: <200008081539.LAA11332@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: Your message of "Tue, 08 Aug 2000 00:48:36 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 08 Aug 2000 11:39:07 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Skip" == Skip Booth writes: Skip> This is a fair proposal and one that has been made before if memory Skip> serves me correctly. It is simply a keepalive mechanism, albeit Skip> one that doesn't require any change to IKE which is probably a good Skip> thing. However it does double the number of SAs a box must Skip> terminate in the remote access scenario. The source address of the ICMP ping that the gateway sends can be whatever is necessary to fit into the existing SA. If the existing SA is a protocol specific, or port-specific SA that does not permit ICMP, then you can't use this. I do not believe that there are any currently deployed situations where people are using such policies, and I have long argued that certain ICMP should permitted by such a policy in any case. >> The really interesting question, to me, is what should happen when a >> new SA is created with the same SPD data as an existing one. That is, >> what happens when one side thinks things are dead and tries to create >> a new SA, while the other side thinks things are fine. That can >> happen with my proposal and with keep-alives -- the condition that >> creates any sort of keep-alive failure is a loss of communications. Skip> I would hope the original is destroyed. This really shouldn't be Skip> any different than a new phase 1/2 SA negotiation sequence with a Skip> peer which didn't receive the SA delete messages. This is partly the problem that the birth certificate solves. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Tue Aug 8 09:32:27 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11244; Tue, 8 Aug 2000 09:32:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04693 Tue, 8 Aug 2000 11:18:50 -0400 (EDT) Message-Id: <200008081528.LAA08630@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: Your message of "07 Aug 2000 18:26:30 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 08 Aug 2000 11:28:42 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Derek" == Derek Atkins writes: Derek> The problem with dead-peer detection is that you have no way to Derek> know how or why a peer lost contact. You don't know if they got Derek> rebooted, lost power, lost connectivity, or some other reason. Derek> Perhaps your peer's upstream provider fell off the net? Or maybe Yes, those are all good arguments for why heartbeats/keep alives/make-deads should be optional, and why one should be able to turn them off, or why you might want to have your client refuse to accept to negotiate them. Derek> If you're really that worried about the resources for "dead" SAs, Derek> negotiate relatively short rekey times, at which point if your Derek> peer disappears, the SA will timeout in a relatively short time. This has a detrimental effect on the live SAs. Derek> As has been mentioned, 'keep-alives' really equate to 'make-dead'. Agreed, which why the facility that should be negotiated is called a "heart beat", not a "keep alive". Derek> If you want to see if something is still there, why not just keep Derek> track of the last time a packet has been received on a particular Derek> SA and just send an ICMP ping_request? The ping_response will Derek> tell you your peer is alive, and you can update your SA Derek> time-of-last-packet to the current time. But what's the point of Derek> that? Short key lifetimes solves this problem. In my opinion, IPsec heartbeats should just be ICMP ping requests, and the fact that any traffic is received is the "response". There is really no negotiation required in this context. Only a phase I heartbeat requires some kind of negotiation as you have to agree to keep the phase I SA alive. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Tue Aug 8 10:59:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13181; Tue, 8 Aug 2000 10:59:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05208 Tue, 8 Aug 2000 12:35:06 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Tue, 08 Aug 2000 10:44:10 -0600 From: "Hilarie Orman" To: , Cc: , Subject: Re: IV sizes for AES candidates 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 MAA05204 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk That 15K bit DH modulus for deriving large symmetric keys is exactly why elliptic curve groups are so important. The computation cost is exponential in the size of the modulus and the EC modulus for equivalent strength is much smaller. Palatable, even. Whether or not 256 bits of symmetric key buys you more than 128 bits is determined by the requirements for the duration of secrecy and predictions of future technology. We lose somewhere between 2/3 and 1 bit per year, so 128 bits might just not last for the amount of time between DES and AES. At this moment, 256 bits looks good for 50 years, even assuming a radical breakthrough in computing devices. Hilarie From owner-ipsec@lists.tislabs.com Tue Aug 8 10:59:41 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13183; Tue, 8 Aug 2000 10:59:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05249 Tue, 8 Aug 2000 12:38:12 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A79B@hhdata3.cdsemea.baltimore.com> From: Chris Trobridge To: Michael Richardson , ipsec@lists.tislabs.com Subject: RE: Heartbeats Straw Poll Date: Tue, 8 Aug 2000 17:47:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >>>>> "Skip" == Skip Booth writes: > Skip> This is a fair proposal and one that has been made > before if memory > Skip> serves me correctly. It is simply a keepalive > mechanism, albeit > Skip> one that doesn't require any change to IKE which is > probably a good > Skip> thing. However it does double the number of SAs a box must > Skip> terminate in the remote access scenario. > > The source address of the ICMP ping that the gateway sends > can be whatever > is necessary to fit into the existing SA. > If the existing SA is a protocol specific, or port-specific > SA that does > not permit ICMP, then you can't use this. I do not believe > that there are any > currently deployed situations where people are using such > policies, and I > have long argued that certain ICMP should permitted by such a > policy in any > case. The problem is that you have to maintain a separation between client traffic and gateway traffic. If you pick arbitrary addresses from the SAs then you could pick up genuine client addresses. If one or other of these clients attempts to ping the other then this traffic will be effectively filtered out by the gateways. This problem may be largely theoretical but it's still not good practice. In many cases the 'red' ports of the gateways will be covered by the SA and hence these addresses can be safely used but this isn't universal and you still need a way to determine the safe remote address. Chris From owner-ipsec@lists.tislabs.com Tue Aug 8 11:06:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13323; Tue, 8 Aug 2000 11:06:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05519 Tue, 8 Aug 2000 13:07:23 -0400 (EDT) Message-Id: <200008081717.NAA16583@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: Your message of "Tue, 08 Aug 2000 10:10:57 PDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 08 Aug 2000 13:17:15 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Jan" == Jan Vilhuber writes: Jan> On Tue, 8 Aug 2000, Michael Richardson wrote: >> In my opinion, IPsec heartbeats should just be ICMP ping requests, >> and the fact that any traffic is received is the "response". Jan> But remember that there are customers that want to bill based on Jan> traffic. Having a heartbeat in the form of a ping through the SA Red-herring. That is called "Overhead". a) Does the customer pay for the ESP and IP outer frames? If so, then the cost of the ICMP ping will never show. b) Does the customer pay for IKE frames? If so, then the cost of the ICMP will never show. c) If the customer still has a problem, then turn off heart beats for that SA, and charge them extra for an "AlwaysOn" connection. Jan> artificially drives up the packet/bytes counts. Now all of a sudden Jan> you have to put more logic in to potentially not count these pings, Jan> but you probably do want to count pings that the customer sends. Jan> It's not QUITE as simple as merely sending pings... I disagree. It is. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Tue Aug 8 11:08:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13368; Tue, 8 Aug 2000 11:08:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA05415 Tue, 8 Aug 2000 12:56:53 -0400 (EDT) Message-Id: <200008081706.NAA16366@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: Your message of "Tue, 08 Aug 2000 17:47:34 BST." <1FD60AE4DB6CD2118C420008C74C27B854A79B@hhdata3.cdsemea.baltimore.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 08 Aug 2000 13:06:44 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Chris" == Chris Trobridge writes: >> The source address of the ICMP ping that the gateway sends can be >> whatever is necessary to fit into the existing SA. If the existing SA >> is a protocol specific, or port-specific SA that does not permit ICMP, Chris> The problem is that you have to maintain a separation between Chris> client traffic and gateway traffic. If you pick arbitrary For a single ping every 2-10 minutes, I hardly think that any accounting rules matter in this regard. Chris> addresses from the SAs then you could pick up genuine client Chris> addresses. If one or other of these clients attempts to ping the You mean a genuine address that belongs to the server that the client is talking to. So what? the server sees a gratuitous ICMP Echo Response now and then. Chris> other then this traffic will be effectively filtered out by the Chris> gateways. This problem may be largely theoretical but it's still Chris> not good practice. Making a new SA which may be routed in an entirely different fashion, due to QoS isn't much of a better solution. Chris> In many cases the 'red' ports of the gateways will be covered by Chris> the SA and hence these addresses can be safely used but this isn't Chris> universal and you still need a way to determine the safe remote Chris> address. No need. The SA tells you. You just don't care if you see the ICMP Echo Response. You see *traffic* that is that is enough to know that things are alive. If you see no traffic for awhile, then you must force some to see if the SA is alive. The only thing that this screws up is some NAS/client PPP idle timer, but all heartbeat/make-dead protocols screw that up. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Tue Aug 8 11:13:53 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA13478; Tue, 8 Aug 2000 11:13:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05484 Tue, 8 Aug 2000 13:01:33 -0400 (EDT) Date: Tue, 8 Aug 2000 10:10:57 -0700 (PDT) From: Jan Vilhuber To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <200008081528.LAA08630@solidum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 8 Aug 2000, Michael Richardson wrote: > > In my opinion, IPsec heartbeats should just be ICMP ping requests, and the > fact that any traffic is received is the "response". But remember that there are customers that want to bill based on traffic. Having a heartbeat in the form of a ping through the SA artificially drives up the packet/bytes counts. Now all of a sudden you have to put more logic in to potentially not count these pings, but you probably do want to count pings that the customer sends. It's not QUITE as simple as merely sending pings... jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Aug 8 11:53:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14159; Tue, 8 Aug 2000 11:53:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05810 Tue, 8 Aug 2000 13:45:56 -0400 (EDT) Message-Id: <200008081746.e78HkTS112303@thunk.east.sun.com> From: Bill Sommerfeld To: Skip Booth cc: "Steven M. Bellovin" , "Theodore Y. Ts'o" , sommerfeld@East.Sun.COM, Scott Fanning , Derek Atkins , "Scott G. Kelly" , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-reply-to: Your message of "Tue, 08 Aug 2000 00:48:36 EDT." Reply-to: sommerfeld@East.Sun.COM Date: Tue, 08 Aug 2000 13:46:29 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > It is critical that the IP addresses are returned ASAP after the > client has disconnected so they can be reused for the next client. Is this "critical" as a consequence of excessively tight address allocation policies? If you're billing by "connect time" (a silly concept in a connectionless network), bill the client until they either explicitly delete the SA or DHCPRELEASE a leased address or until the SA/lease expires. That will give clients an incentive to do a clean disconnect.. :-) > > Keep-alives are most important if a dead session is consuming critical > > resources. What resources are these? Memory is very cheap these days, > > much cheaper than programmer time to hack IKE. (To say nothing of WG > > time to consider the changes to IKE...) Accounting? Apart from the > > fact that I don't even understand what resource you're accounting for, > > The same resources that we have been tracking for many years now. > Duration of the call being of primary importance, That's not a "resource". The memory used by the SA's is a resource; so are any the IP addresses (but if you're allocating ip addresses, you must be using some other protocol besides ipsec so that other protocol could handle it). As Steve said, memory is cheap... > bytes in/out, well, if i disappeared, i'm not sending any bytes.. > disconnect reason, etc. again, that's not a "resource."; it may be interesting to know for diagnostic reasons, but it's not a "resource". > > you can always record the timestamp of the last packet received on an > > SA. That's cheap and easy; you're already doing far more processing > > than that per received packet. > > Not necessary cheap since it does effect your per-packet code path, but > considering how much work goes into each packet for IPsec, I'll give you that > one. However this algorithm is not accurate enough to serve the purposes of > accounting or IP address management. "not accurate enough"? It lets you know exactly when the client last used its SA... more accurately than missed heartbeats would.. > I would hope the original is destroyed. This really shouldn't be > any different than a new phase 1/2 SA negotiation sequence with a > peer which didn't receive the SA delete messages. Well, certainly you should send using the newest SA which matches your policy. with respect to reception, at a minimum, I would hope that there's a grace period there around rekey time to accept packets sent to the old SA which were delayed in transit. I don't see the harm in letting the SA's live until they expire unless a DELETE or INITIAL-CONTACT or other affirmative indication that they're gone on the other end comes in.. - Bill From owner-ipsec@lists.tislabs.com Tue Aug 8 12:08:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14392; Tue, 8 Aug 2000 12:08:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05901 Tue, 8 Aug 2000 14:02:58 -0400 (EDT) Date: Tue, 8 Aug 2000 14:10:36 -0400 (EDT) From: Skip Booth To: Bill Sommerfeld cc: "Steven M. Bellovin" , "Theodore Y. Ts'o" , Scott Fanning , Derek Atkins , "Scott G. Kelly" , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <200008081746.e78HkTS112303@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 8 Aug 2000, Bill Sommerfeld wrote: > > It is critical that the IP addresses are returned ASAP after the > > client has disconnected so they can be reused for the next client. > > Is this "critical" as a consequence of excessively tight address > allocation policies? Yes. > > If you're billing by "connect time" (a silly concept in a > connectionless network), bill the client until they either explicitly > delete the SA or DHCPRELEASE a leased address or until the SA/lease > expires. That will give clients an incentive to do a clean > disconnect.. :-) I know that there are still times when I don't gracefully disconnect my dial-in session and I'm pretty savvy about this stuff. There are alot of people which are not. Although, I do agree that money has a funny way of training people much more quickly. Regardless, there will be customers that want to bill for these services and the clients are going to demand accurate accounting since it will cost them money. It is no different than the traditional dial-up infrastructure except as you have noted there isn't the concept of a hardware connection. That is why keepalives are important. In the absence of a "loss of carrier" mechanism, the protocol must be able to detect a dead peer. > > > > Keep-alives are most important if a dead session is consuming critical > > > resources. What resources are these? Memory is very cheap these days, > > > much cheaper than programmer time to hack IKE. (To say nothing of WG > > > time to consider the changes to IKE...) Accounting? Apart from the > > > fact that I don't even understand what resource you're accounting for, > > > > The same resources that we have been tracking for many years now. > > Duration of the call being of primary importance, > > That's not a "resource". The memory used by the SA's is a resource; > so are any the IP addresses (but if you're allocating ip addresses, > you must be using some other protocol besides ipsec so that other > protocol could handle it). As Steve said, memory is cheap... IP addresses are not necessarily cheap. Filters are also not necessary cheap since they almost always decrease your pps numbers as more are added. > > > bytes in/out, > > well, if i disappeared, i'm not sending any bytes.. Yes, but just because you are not sending any bytes doesn't mean you are disconnected. > > > disconnect reason, etc. > > again, that's not a "resource."; it may be interesting to know for > diagnostic reasons, but it's not a "resource". I obviously used the wrong word. My point is that each of these items are importart information which our customers have come to expect from their well deployed dial-up networks. The model really hasn't changed except that they don't have to manage modems and ISDN resources anymore (now they have to manage certs :)). They still will need to be able to troubleshoot failures and determine whether resources need to be added for bandwidth, IP addresses, etc. The IT department is still going to want to bill back the departments for their remote access charges. > > > > you can always record the timestamp of the last packet received on an > > > SA. That's cheap and easy; you're already doing far more processing > > > than that per received packet. > > > > Not necessary cheap since it does effect your per-packet code path, but > > considering how much work goes into each packet for IPsec, I'll give you that > > one. However this algorithm is not accurate enough to serve the purposes of > > accounting or IP address management. > > "not accurate enough"? It lets you know exactly when the client last > used its SA... more accurately than missed heartbeats would.. This doesn't give you any information on whether it's viable to teardown the SA though and relinquish resources back to the system. > > > I would hope the original is destroyed. This really shouldn't be > > any different than a new phase 1/2 SA negotiation sequence with a > > peer which didn't receive the SA delete messages. > > Well, certainly you should send using the newest SA which matches your > policy. with respect to reception, at a minimum, I would hope that > there's a grace period there around rekey time to accept packets sent > to the old SA which were delayed in transit. > > I don't see the harm in letting the SA's live until they expire unless > a DELETE or INITIAL-CONTACT or other affirmative indication that > they're gone on the other end comes in.. I think the reasons I have listed above make a case for why deleting them before they expire might be a good thing. I don't think this should be mandatory behavior, however I do think a standardized solution which allows this behavior is worthwhile. -Skip > > - Bill > > From owner-ipsec@lists.tislabs.com Tue Aug 8 13:57:37 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16117; Tue, 8 Aug 2000 13:57:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06609 Tue, 8 Aug 2000 15:51:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Tue, 8 Aug 2000 13:01:16 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Heartbeats Straw Poll Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [long Cc list trimmed since everyone is already on the mailing list] At 2:10 PM -0400 8/8/00, Skip Booth wrote: >Regardless, there will be customers that want to bill >for these services and the clients are going to demand accurate >accounting since >it will cost them money. This is not a requirement for heartbeats, I believe. This is a requirement for accounting. Heartbeats, as being discussed here, have the sole purpose of freeing up gateway resources as quickly as possible while not becoming "makedeads". So far, the two gateway resources that have been best identified are state memory and IP addresses. Despite memory being cheap, we might want to conserve it if the process for conserving it is not too onerous. As for IP addresses, we don't need to be any more aggressive about them than the current protocol that uses them, namely DHCP. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Aug 8 14:41:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17038; Tue, 8 Aug 2000 14:41:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06702 Tue, 8 Aug 2000 16:26:53 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Aug 2000 16:36:43 -0400 Message-Id: <20000808203644.302DE35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Paul Hoffman / VPNC writes : > >So far, the two gateway resources that have been best identified are >state memory and IP addresses. Despite memory being cheap, we might >want to conserve it if the process for conserving it is not too >onerous. As for IP addresses, we don't need to be any more aggressive >about them than the current protocol that uses them, namely DHCP. Precisely. In ipsra, it was pointed out that we need some sort of identifier to pass to DHCP in lieu of a MAC address. If we use, say, the cert-id, someone who dials in anew and negotiates a new SA will get the same DHCP address, which is exactly what you want to preserve ongoing application connections. Furthermore, by DHCP semantics you can't reuse an address until its lease is up, which again means that you don't need a heartbeat to tell you that you've lost touch. As for memory -- pulling out a random catalog that's sitting on my desk right now, it seems that desktop memory costs ~$2/meg. How many SAs can I fit in 1 meg? Easily worth the $2, especially when I think of what the programmer time would be to implement something complex. --Steve Bellovin From owner-ipsec@lists.tislabs.com Tue Aug 8 15:01:21 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17373; Tue, 8 Aug 2000 15:01:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06754 Tue, 8 Aug 2000 16:42:38 -0400 (EDT) Date: Tue, 8 Aug 2000 13:51:13 -0700 (PDT) From: Jan Vilhuber To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <200008081717.NAA16583@solidum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We must agree to disagree then. it's far from 'overhead'. Hwo would YOU feel if you got charged for something that you didn't do? jan On Tue, 8 Aug 2000, Michael Richardson wrote: > > >>>>> "Jan" == Jan Vilhuber writes: > Jan> On Tue, 8 Aug 2000, Michael Richardson wrote: > >> In my opinion, IPsec heartbeats should just be ICMP ping requests, > >> and the fact that any traffic is received is the "response". > > Jan> But remember that there are customers that want to bill based on > Jan> traffic. Having a heartbeat in the form of a ping through the SA > > Red-herring. That is called "Overhead". > > a) Does the customer pay for the ESP and IP outer frames? If so, then > the cost of the ICMP ping will never show. > > b) Does the customer pay for IKE frames? If so, then the cost of the ICMP > will never show. > > c) If the customer still has a problem, then turn off heart beats for that > SA, and charge them extra for an "AlwaysOn" connection. > > Jan> artificially drives up the packet/bytes counts. Now all of a sudden > Jan> you have to put more logic in to potentially not count these pings, > Jan> but you probably do want to count pings that the customer sends. > > Jan> It's not QUITE as simple as merely sending pings... > > I disagree. It is. > > :!mcr!: | Solidum Systems Corporation, http://www.solidum.com > Michael Richardson |For a better connected world,where data flows faster > Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html > mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Aug 8 15:01:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17372; Tue, 8 Aug 2000 15:01:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06732 Tue, 8 Aug 2000 16:36:04 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Skip Booth Cc: Bill Sommerfeld , "Theodore Y. Ts'o" , Scott Fanning , Derek Atkins , "Scott G. Kelly" , Paul Hoffman , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Aug 2000 16:45:41 -0400 Message-Id: <20000808204550.4E32F35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Skip Bo oth writes: > >I obviously used the wrong word. My point is that each of these items are >importart information which our customers have come to expect from their well >deployed dial-up networks. The model really hasn't changed except that they >don't have to manage modems and ISDN resources anymore (now they have to manag >e >certs :)). They still will need to be able to troubleshoot failures and >determine whether resources need to be added for bandwidth, IP addresses, etc. > >The IT department is still going to want to bill back the departments for thei >r >remote access charges. Many customers "expect" things because their old charge forms from their modem pools have blanks for them. It doesn't mean that they're real. (I used to have to pay for cards punched...) Bandwidth is a resource, as are IP addresses, and I agree that some folks will want (and maybe even need, though that's more debatable) to charge back for them. For bandwidth, though, one can count the bytes coming in; if they stop, they stop, regardless of whether or not there's an SA. For addresses, why not just use DHCP lease time? > >> >> > > you can always record the timestamp of the last packet received on an >> > > SA. That's cheap and easy; you're already doing far more processing >> > > than that per received packet. >> > >> > Not necessary cheap since it does effect your per-packet code path, but >> > considering how much work goes into each packet for IPsec, I'll give you t >hat >> > one. However this algorithm is not accurate enough to serve the purposes >of >> > accounting or IP address management. >> >> "not accurate enough"? It lets you know exactly when the client last >> used its SA... more accurately than missed heartbeats would.. > >This doesn't give you any information on whether it's viable to teardown the S >A >though and relinquish resources back to the system. How is it any different? If I can get through to the remote site at all, I can't give back the resources. Doing something at the IKE level says the same thing. *Maybe* something is wedged with IKE, and I can get payload through but the IKE process isn't responding. But to me, that sounds like a great reason to keep the connection up; after all, useful stuff is getting through. --Steve Bellovin From owner-ipsec@lists.tislabs.com Tue Aug 8 15:01:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17391; Tue, 8 Aug 2000 15:01:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06768 Tue, 8 Aug 2000 16:46:01 -0400 (EDT) Date: Tue, 8 Aug 2000 13:54:39 -0700 (PDT) From: Jan Vilhuber To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <200008081706.NAA16366@solidum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 8 Aug 2000, Michael Richardson wrote: > > No need. The SA tells you. > You just don't care if you see the ICMP Echo Response. You see *traffic* > that is that is enough to know that things are alive. If you see no traffic > for awhile, then you must force some to see if the SA is alive. The only > thing that this screws up is some NAS/client PPP idle timer, but all > heartbeat/make-dead protocols screw that up. > I also don't remember seeing that all hosts MUST answer to icmp echo requests. Lots of hosts don't. Lots of firewalls don't. Your policy may exclude them. This is not a good general purpose solution. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Aug 8 15:10:28 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17530; Tue, 8 Aug 2000 15:10:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06879 Tue, 8 Aug 2000 17:05:28 -0400 (EDT) Message-Id: <200008082115.e78LFFZ11934@nyarlathotep.cis.upenn.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Michael Richardson Cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-reply-to: Your message of "Tue, 08 Aug 2000 11:39:07 EDT." <200008081539.LAA11332@solidum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Aug 2000 17:15:15 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200008081539.LAA11332@solidum.com>, Michael Richardson writes: > > The source address of the ICMP ping that the gateway sends can be whatever >is necessary to fit into the existing SA. > If the existing SA is a protocol specific, or port-specific SA that does >not permit ICMP, then you can't use this. I do not believe that there are any >currently deployed situations where people are using such policies, and I >have long argued that certain ICMP should permitted by such a policy in any >case. >From my experience, a number of commercial firewalls with IPsec support make that assumption implicitly (that an SA negotiated for traffic between two nets can also be used for traffic between the two gateways). -Angelos From owner-ipsec@lists.tislabs.com Tue Aug 8 15:12:10 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17561; Tue, 8 Aug 2000 15:12:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06816 Tue, 8 Aug 2000 16:59:43 -0400 (EDT) Date: Tue, 8 Aug 2000 14:09:03 -0700 (PDT) From: Jan Vilhuber To: "Steven M. Bellovin" cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <20000808210659.1BD7F35DC2@smb.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I stand corrected. jan On Tue, 8 Aug 2000, Steven M. Bellovin wrote: > In message , Jan > Vilhuber writes: > >On Tue, 8 Aug 2000, Michael Richardson wrote: > >> > >> No need. The SA tells you. > >> You just don't care if you see the ICMP Echo Response. You see *traffic* > >> that is that is enough to know that things are alive. If you see no traffic > >> for awhile, then you must force some to see if the SA is alive. The only > >> thing that this screws up is some NAS/client PPP idle timer, but all > >> heartbeat/make-dead protocols screw that up. > >> > >I also don't remember seeing that all hosts MUST answer to icmp echo > >requests. Lots of hosts don't. Lots of firewalls don't. Your policy may > >exclude them. > > Section 3.2.2.6 of RFC 1122: > > Every host MUST implement an ICMP Echo server function that > receives Echo Requests and sends corresponding Echo Replies. > > As for policy issues -- they're connecting to *your* gateway, so you > define the service requirements. > > > --Steve Bellovin > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Aug 8 15:13:47 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17590; Tue, 8 Aug 2000 15:13:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06891 Tue, 8 Aug 2000 17:07:06 -0400 (EDT) Message-Id: <200008082117.RAA20886@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: Your message of "Tue, 08 Aug 2000 13:51:13 PDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 08 Aug 2000 17:17:01 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Jan" == Jan Vilhuber writes: Jan> We must agree to disagree then. it's far from 'overhead'. Hwo would Jan> YOU feel if you got charged for something that you didn't do? How will you explain: a) ESP+IP overhead b) IKE overhead c) banner ads on yahoo.com :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Tue Aug 8 15:13:52 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17608; Tue, 8 Aug 2000 15:13:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06911 Tue, 8 Aug 2000 17:08:31 -0400 (EDT) Message-Id: <200008082118.RAA20903@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: Your message of "Tue, 08 Aug 2000 13:54:39 PDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 08 Aug 2000 17:18:25 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Jan" == Jan Vilhuber writes: Jan> I also don't remember seeing that all hosts MUST answer to icmp echo Jan> requests. Lots of hosts don't. Lots of firewalls don't. Your policy Jan> may exclude them. PARAPHRASE: I also don't remember seeing that all hosts MUST answer to IPsec ESP packets. 99% of hosts don't. Lots of firewalls don't. Your policy may exclude them. From owner-ipsec@lists.tislabs.com Tue Aug 8 15:28:46 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17822; Tue, 8 Aug 2000 15:28:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA06801 Tue, 8 Aug 2000 16:57:07 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Jan Vilhuber Cc: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Aug 2000 17:06:55 -0400 Message-Id: <20000808210659.1BD7F35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: >On Tue, 8 Aug 2000, Michael Richardson wrote: >> >> No need. The SA tells you. >> You just don't care if you see the ICMP Echo Response. You see *traffic* >> that is that is enough to know that things are alive. If you see no traffic >> for awhile, then you must force some to see if the SA is alive. The only >> thing that this screws up is some NAS/client PPP idle timer, but all >> heartbeat/make-dead protocols screw that up. >> >I also don't remember seeing that all hosts MUST answer to icmp echo >requests. Lots of hosts don't. Lots of firewalls don't. Your policy may >exclude them. Section 3.2.2.6 of RFC 1122: Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies. As for policy issues -- they're connecting to *your* gateway, so you define the service requirements. --Steve Bellovin From owner-ipsec@lists.tislabs.com Tue Aug 8 15:45:05 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA18030; Tue, 8 Aug 2000 15:45:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA07313 Tue, 8 Aug 2000 17:44:03 -0400 (EDT) Date: Tue, 8 Aug 2000 17:50:38 -0400 (EDT) From: Henry Spencer To: Jan Vilhuber cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll 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, 8 Aug 2000, Jan Vilhuber wrote: > I also don't remember seeing that all hosts MUST answer to icmp echo > requests... RFC 1122 (Host Requirements, part 1) says MUST for hosts. RFC 1812 (Router Requirements) says MUST for routers too, although it may be configurable (but must default to ON). > This is not a good general purpose solution. There is no requirement that we devise a solution which will work even on arbitrarily defective implementations. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Aug 8 20:03:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA04041; Tue, 8 Aug 2000 20:03:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07967 Tue, 8 Aug 2000 21:32:13 -0400 (EDT) Date: Tue, 8 Aug 2000 18:41:37 -0700 (PDT) From: Jan Vilhuber To: Michael Richardson cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <200008082117.RAA20886@solidum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 8 Aug 2000, Michael Richardson wrote: > > >>>>> "Jan" == Jan Vilhuber writes: > Jan> We must agree to disagree then. it's far from 'overhead'. Hwo would > Jan> YOU feel if you got charged for something that you didn't do? > > How will you explain: > > a) ESP+IP overhead > b) IKE overhead > c) banner ads on yahoo.com > That's all part of the traffic originated by the user. If they don't like paying for yahoo banner ads, don't go to yahoo, or get an ad-blocker. IKE overhead isn't part of the ipsec SA, and wouldn't be counted anyway. ESP+IP is also part of a packet on behalf of the user. But of course it's easy enough to count only the data part of the ESP+IP packet. Way easier than filtering out pings (which are NOT on the user's behalf; although arguably it's a service that a user would pay for, if they really wanted it), which can and do add up (I know customers who really really want to run our keepalives at some absurd interval; I just know the next thing they'd ask for is to NOT count things like the pings they'd send every second). I don't have a STRONG opposition to pings, BTW (as long as they don't get a separate SA like one proposal proposed). Afterall, if you're using routing to do this whole link-state assessment, then that would be network traffic counted against the volume of the SA as well (OSPF HELLO's versus pings.. no real difference for the SA). I'm just pointing out that it's not QUITE as straightforward as you claim (at least in the minds of some overly penny-pinching customers; I point to the radius accounting attribute pre-authen-bytes or whatever it was called as evidence). I've seen some pretty nice ideas so far, which may work as well. Let's keep up the discussion of alternative means to keepalives... jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Aug 8 20:11:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA04646; Tue, 8 Aug 2000 20:11:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA07995 Tue, 8 Aug 2000 21:57:08 -0400 (EDT) Message-ID: <20000809020704.22366.qmail@web906.mail.yahoo.com> Date: Tue, 8 Aug 2000 19:07:04 -0700 (PDT) From: Wen-Chi Wang Subject: IPsec tunnel and WIndows 2000 Terminal server To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all: My client got an interesting IPSec and WIndows 2000 terminal problem. Their client could connect to windows 2000 terminal server through LAN connection and PPTP tunnel. While connecting to the WIndows 2000 terminal server through IPSec tunnel, the client get disconnected from server and server has event log saying terminal server failed to issue a license to client. I am not pretty sure what IPSec implementation my client has in this case because I am not in the security group in this project. I just wonder if anyone in IPSec group ever heard about any thing about connecting to Windows 2000 terminal server through IPSec tunnel. Any successful or failed story? By my rough guess, routing and IPsec policy did matter in this case. Again, I did not have the chance to check client's gateway to gateway IPSec configuration. So I end up with bring this topic with rough description and hope get reply from other about their deployment of IPsec and any kind of compatibility with windows 2000 terminal server ( running windows 2000 advanced server in application terminal server mode.) Wen-Chi (Alex) Wang Lucent Technologies, Networkcare NPS __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ From owner-ipsec@lists.tislabs.com Tue Aug 8 20:46:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA07180; Tue, 8 Aug 2000 20:46:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA08140 Tue, 8 Aug 2000 22:38:37 -0400 (EDT) Date: Tue, 8 Aug 2000 22:48:25 -0400 From: "Theodore Ts'o" Message-Id: <200008090248.WAA09563@trampoline.thunk.org> To: ebooth@cisco.com CC: smb@research.att.com, sommerfeld@East.Sun.COM, sfanning@cisco.com, warlord@mit.edu, skelly@redcreek.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com In-reply-to: (message from Skip Booth on Tue, 8 Aug 2000 00:48:36 -0400 (EDT)) Subject: Re: Heartbeats Straw Poll Phone: (781) 391-3464 References: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Date: Tue, 8 Aug 2000 00:48:36 -0400 (EDT) From: Skip Booth The server cares because it has to do things like stop accounting (a very important remote access function) and return IP addresses back to the DHCP server or to it's local pool. It is critical that the IP addresses are returned ASAP after the client has disconnected so they can be reused for the next client. Neither of these (accounting and returning IP addresses to a DHCP pool) are IPSEC issues. This is stuff you have to deal with even if you're not using IPSEC. Hence, solving it with an IPSEC-specific solution seems like we're barking up the wrong tree. - Ted From owner-ipsec@lists.tislabs.com Tue Aug 8 22:18:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA11474; Tue, 8 Aug 2000 22:18:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA08376 Wed, 9 Aug 2000 00:14:58 -0400 (EDT) Date: Wed, 9 Aug 2000 00:22:10 -0400 (EDT) From: Skip Booth To: "Theodore Ts'o" cc: smb@research.att.com, sommerfeld@East.Sun.COM, sfanning@cisco.com, warlord@mit.edu, skelly@redcreek.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <200008090248.WAA09563@trampoline.thunk.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 8 Aug 2000, Theodore Ts'o wrote: > Date: Tue, 8 Aug 2000 00:48:36 -0400 (EDT) > From: Skip Booth > > The server cares because it has to do things like stop accounting (a > very important remote access function) and return IP addresses back > to the DHCP server or to it's local pool. It is critical that the IP > addresses are returned ASAP after the client has disconnected so they > can be reused for the next client. > > Neither of these (accounting and returning IP addresses to a DHCP pool) > are IPSEC issues. This is stuff you have to deal with even if you're > not using IPSEC. Hence, solving it with an IPSEC-specific solution > seems like we're barking up the wrong tree. I think if the IPSRA WG states that IP address assignment will only be done with DHCP, using the method described in draft-ietf-ipsec-dhcp-06.txt, I would agree with you. However, if you try to use local IP address pools and something like IKECFG to hand out IP address to the clients, then I would argue that you need keepalives. Even though it appears that accounting has been deemed to not be a requirement, it will be an issue in customer networks. So I guess my question is, if IPsec doesn't send the start and stop accounting records, then who does and how do they know when to send the stop accounting record? -Skip > > - Ted > > From owner-ipsec@lists.tislabs.com Wed Aug 9 02:50:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29844; Wed, 9 Aug 2000 02:50:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA09207 Wed, 9 Aug 2000 04:30:52 -0400 (EDT) Message-ID: <1FD60AE4DB6CD2118C420008C74C27B854A7A1@hhdata3.cdsemea.baltimore.com> From: Chris Trobridge To: Michael Richardson , ipsec@lists.tislabs.com Subject: RE: Heartbeats Straw Poll Date: Wed, 9 Aug 2000 09:40:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Chris> The problem is that you have to maintain a separation between > Chris> client traffic and gateway traffic. If you pick arbitrary > > For a single ping every 2-10 minutes, I hardly think that > any accounting rules matter in this regard. > > Chris> addresses from the SAs then you could pick up > genuine client > Chris> addresses. If one or other of these clients > attempts to ping the > > You mean a genuine address that belongs to the server that > the client is talking to. So what? the server sees a gratuitous ICMP > Echo Response now and then. I mean VPN clients - not as in client-server. In this case you can't assume that any particular address maps to anything (the subnet/range probably isn't fully populated). > > Chris> other then this traffic will be effectively > filtered out by the > Chris> gateways. This problem may be largely theoretical > but it's still > Chris> not good practice. > > Making a new SA which may be routed in an entirely > different fashion, due to QoS isn't much of a better solution. I'm not sure what you mean here - all I've said is that if you mark certain SA addresses/protocol for heart beats then these are effectively removed from use by the (VPN) clients. > Chris> In many cases the 'red' ports of the gateways will > be covered by > Chris> the SA and hence these addresses can be safely > used but this isn't > Chris> universal and you still need a way to determine > the safe remote > Chris> address. > > No need. The SA tells you. The SA does not tell you whether it includes an address that is owned by either gateway, nor whether any address is actually populated. > You just don't care if you see the ICMP Echo Response. You > see *traffic* > that is that is enough to know that things are alive. If you > see no traffic > for awhile, then you must force some to see if the SA is > alive. The only > thing that this screws up is some NAS/client PPP idle timer, but all > heartbeat/make-dead protocols screw that up. This I agree with - you just need to see some valid traffic on an SA to know that the other end is still alive. I don't think this needs an echo though. As long as each side ensures it transmits sufficient traffic to confirm that it's still up there's no need for boths sides to send and receive pings. Chris From owner-ipsec@lists.tislabs.com Wed Aug 9 03:51:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05021; Wed, 9 Aug 2000 03:51:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA09414 Wed, 9 Aug 2000 05:50:47 -0400 (EDT) Message-ID: <094b01c001e8$67b99570$d909e2c2@debugger> From: "Alexei V. Vopilov" To: "Wen-Chi Wang" , References: <20000809020704.22366.qmail@web906.mail.yahoo.com> Subject: Re: IPsec tunnel and WIndows 2000 Terminal server Date: Wed, 9 Aug 2000 13:58:43 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think this is not an issue of IPsec. Rather, this is obviously the Windows 2000 licensing question. Windows 2000 once installed employs following algorithm (or a like) to accept clients on it's terminal services: - Sets the start of 90-days evaluation period - When a client is requesting connection on terminal service, the attempt is made to locate Terminal Service License Server on the network - If failed, then just issue dummy certificate and accept connection. - Once 90 days is over, server rejects any clients under above case. The License Server can be found as additional Windows 2000 component Once installed it uses similar approach but with respect of real license that must be requested from Microsoft within 90 days once License Server is installed. While this (additional) evaluation period is not expired, the license server issues temporary certificates (licenses) upon request, but sets the expiration date of those according to happened evaluation period. After this, second 90-days, period is over your got to activate the license server by requesting a license from Microsoft the way similar to one used by Sun Microsystems for its products. --Alexei ----- Original Message ----- From: "Wen-Chi Wang" To: Sent: Wednesday, August 09, 2000 6:07 AM Subject: IPsec tunnel and WIndows 2000 Terminal server > Hi all: > My client got an interesting IPSec and WIndows 2000 > terminal problem. Their client could connect to > windows 2000 terminal server through LAN connection > and PPTP tunnel. While connecting to the WIndows 2000 > terminal server through IPSec tunnel, the client get > disconnected from server and server has event log > saying terminal server failed to issue a license to > client. > I am not pretty sure what IPSec implementation my > client has in this case because I am not in the > security group in this project. > I just wonder if anyone in IPSec group ever heard > about any thing about connecting to Windows 2000 > terminal server through IPSec tunnel. Any successful > or failed story? > By my rough guess, routing and IPsec policy did matter > in this case. Again, I did not have the chance to > check client's gateway to gateway IPSec configuration. > So I end up with bring this topic with rough > description and hope get reply from other about their > deployment of IPsec and any kind of compatibility with > windows 2000 terminal server ( running windows 2000 > advanced server in application terminal server mode.) > > > Wen-Chi (Alex) Wang > Lucent Technologies, Networkcare NPS > > > __________________________________________________ > Do You Yahoo!? > Kick off your party with Yahoo! Invites. > http://invites.yahoo.com/ > > From owner-ipsec@lists.tislabs.com Wed Aug 9 05:02:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA08850; Wed, 9 Aug 2000 05:02:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA09669 Wed, 9 Aug 2000 07:02:37 -0400 (EDT) Message-ID: <39913CB2.88AF2F47@F-Secure.com> Date: Wed, 09 Aug 2000 14:12:50 +0300 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: Michael Richardson , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > > On Tue, 8 Aug 2000, Michael Richardson wrote: > > > > > >>>>> "Jan" == Jan Vilhuber writes: > > Jan> We must agree to disagree then. it's far from 'overhead'. Hwo would > > Jan> YOU feel if you got charged for something that you didn't do? > > > > How will you explain: > > > > a) ESP+IP overhead > > b) IKE overhead > > c) banner ads on yahoo.com > > > That's all part of the traffic originated by the user. If they don't like > paying for yahoo banner ads, don't go to yahoo, or get an ad-blocker. > > IKE overhead isn't part of the ipsec SA, and wouldn't be counted anyway. Could we trash that red herring, please? If I go to a grocery store to buy oranges, I also have to pay for the peels, even though I have no intention of actually eating them. Having PINGS through phase II SAs would suit us quite fine, since we already do it that way. The only problem with that is that some SAs won't let the PINGS through. So, we'd like to see either always allowing PINGS from one endpoint of the IPsec SA to the other endpoint, or some other simple mechanism. -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Wed Aug 9 06:06:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12427; Wed, 9 Aug 2000 06:06:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09936 Wed, 9 Aug 2000 08:09:48 -0400 (EDT) Date: Wed, 9 Aug 2000 08:16:26 -0400 Message-Id: <200008091216.IAA03331@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: Skip Booth CC: "Theodore Ts'o" , smb@research.att.com, sommerfeld@East.Sun.COM, sfanning@cisco.com, warlord@mit.edu, skelly@redcreek.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com In-reply-to: Skip Booth's message of Wed, 9 Aug 2000 00:22:10 -0400 (EDT), Subject: Re: Heartbeats Straw Poll Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Date: Wed, 9 Aug 2000 00:22:10 -0400 (EDT) From: Skip Booth > Neither of these (accounting and returning IP addresses to a DHCP pool) > are IPSEC issues. This is stuff you have to deal with even if you're > not using IPSEC. Hence, solving it with an IPSEC-specific solution > seems like we're barking up the wrong tree. I think if the IPSRA WG states that IP address assignment will only be done with DHCP, using the method described in draft-ietf-ipsec-dhcp-06.txt, I would agree with you. However, if you try to use local IP address pools and something like IKECFG to hand out IP address to the clients, then I would argue that you need keepalives. How IP address assignment is done is a matter of the IPSRA working group to decide; however, the use of "hacks to IKE", such as those proposed by IKECFG were explicitly ruled out of scope according to the IPSRA charter, which was approved by the IESG (who insisted on that restriction). The idea here is that we need to simplify and fix IKE, and we can't do that if people want to keep wanting to add hacks to it. - Ted From owner-ipsec@lists.tislabs.com Wed Aug 9 07:48:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20914; Wed, 9 Aug 2000 07:48:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10189 Wed, 9 Aug 2000 09:29:27 -0400 (EDT) Message-ID: <39915CCA.85C2A78F@indusriver.com> Date: Wed, 09 Aug 2000 09:29:47 -0400 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Theodore Ts'o" CC: "ipsec@lists.tislabs.com" Subject: Re: Heartbeats Straw Poll References: <200008090248.WAA09563@trampoline.thunk.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ CC list trimmed ] Theodore Ts'o wrote: > > Date: Tue, 8 Aug 2000 00:48:36 -0400 (EDT) > From: Skip Booth > > The server cares because it has to do things like stop accounting (a > very important remote access function) and return IP addresses back > to the DHCP server or to it's local pool. It is critical that the IP > addresses are returned ASAP after the client has disconnected so they > can be reused for the next client. > > Neither of these (accounting and returning IP addresses to a DHCP pool) > are IPSEC issues. This is stuff you have to deal with even if you're > not using IPSEC. Hence, solving it with an IPSEC-specific solution > seems like we're barking up the wrong tree. > > - Ted I disagree. We have another object layer on top of Phase 1 and 2 SA's that defines sessions. A session persists across multiple Phase 1 and Phase 2 rekeying events and only dies shortly after all Phase 1 and Phase 2 SA's expire and/or are deleted. I'm sure many other vendors, especially in the remote access market, have a similar kind of object in their implementation. The point of keep-alive/make-dead/heartbeat proposals is to notify this session layer that the underlying IPSEC 'connection' is dead. The session layer can then generate accounting records, free IP addresses, and possibly establish new SA's via a backup security gateway. How would you have us know that a 'session' is dead without the use of an IPSEC specific (or at least sanctioned) solution? The only standards based solution today (that I'm aware of) is to run L2TP with PPP echos over IPSEC. There has to be a lighter weight solution than L2TP to notify a session management layer that the peer is gone. IMHO, a heartbeat protocol should run over a dedicated transport mode Phase 2 SA whose selector is specific to the heartbeat mechanism. I would allocate a new UDP port number specifically for the heartbeat mechanism just so it can distinguished from all other user data. An IPSEC peer that wants keepalives just has to create this SA using a standard quick mode exchange. A peer that _doesn't_ want to accept the heart-beat protocol can deny the quick mode request via its SPD. If both peers agree to create this SA then its presence triggers the heartbeat protocol to periodically send and/or request/reply heartbeat packets. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Wed Aug 9 07:49:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20929; Wed, 9 Aug 2000 07:49:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10214 Wed, 9 Aug 2000 09:41:07 -0400 (EDT) Date: Wed, 9 Aug 2000 16:17:21 +0300 (EET DST) Message-Id: <200008091317.QAA19824@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Theodore Ts'o" Cc: ebooth@cisco.com, smb@research.att.com, sommerfeld@East.Sun.COM, sfanning@cisco.com, warlord@mit.edu, skelly@redcreek.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <200008090248.WAA09563@trampoline.thunk.org> References: <200008090248.WAA09563@trampoline.thunk.org> X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 32 min X-Total-Time: 34 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Ts'o writes: > Neither of these (accounting and returning IP addresses to a DHCP pool) > are IPSEC issues. This is stuff you have to deal with even if you're > not using IPSEC. Hence, solving it with an IPSEC-specific solution > seems like we're barking up the wrong tree. Most of the NAT traversal proposal that encapsulate IPsec inside UDP packets needs some kind of keepalive protocol to keep the NAT from deleting the UDP "connection". In that cases it doesn't matter if it is phase 1 or phase 2 "ping". Also a comment for those who complain about keepalives being make-deads, that is NOT TRUE for the ipsec traffic. Your TCP/IP session is not dead even if the IPsec SA is removed. The SA will be recreated immediately when you send your next packet to that connection. On the other hand if you do not detect black holes then your TCP/IP session will be dead, because it will be sending packets to deleted SA and the other end will just ignore them. After a TCP/IP timeouts the connection is dropped. I think the heart beats are needed to get information when to start renegotiating the SAs with the other end and when to use existing ones. And I would really like to get that information on as soon as possible. It does not mean that when the hearbeat stop coming in, I immedately have to delete all SAs with that host. It means that I will mark that SA as uncertain state, and if I run out of resources I will delete that SA. If there was only temporary network connectivity loss I will starts seeing the heart beats again later, so I can move the SA back to active SAs list. Also if there is traffic coming to the SA that is in uncertain state, I will first try to create new SA for that, just in case the other end was really rebooted. If the other end was rebooted, it will send me INITIAL-CONTACT notification so I know that I can remove the old SA. If it wasn't rebooted, but there was temporary network problem that happened to get fixed just in time to get the SA renegotiated, but before the other ends heart beats start coming in, then I now have two valid SAs with the other end and I can delete one of them to save resources, or I can just leave them there. It is very annoying to know that remote gw was rebooted and your local gw still thinks that it has SAs with the remote gw and sends stuff to black hole. There are currently three easy ways to recover from the problem: 1) Reboot the local gw (== remove all SAs) (I think this is the option that will be selected by most of the people, it is easy, fast and after that everything works fine for them. Of course if you had multiple VPN connections the rest of the connections are now in the same situation, the remote gw was rebooted, and if you are not sending data to them, they have to do same thing :-) 2) Manually delete all SAs from the local gw to the remote gw 3) Call somebody in the remote office and ask them to send some packet to you so that when the remote gw starts negotiation with our local gw, it will include INITIAL-CONTACT notification, which will then clear out SAs in your local gw. Most of the products have some kind of crash-recovery algorithm, that will do some heuristic stuff based on the unknown SPIs etc to get over this problem. That code is quite complicated and usually they don't work that well... How often have you heard this in the IPsec interop meetings: "Lets clear all SAs and try again, I think there was some old SAs left from the previous test still laying around...". So, I think we do need some kind of black hole detection, and probably also need some kind of keep alive for the NAT traversal case. Heartbeat in phase 1 is fine for both cases. Pings in phase 2 are fine also, but not that simple, as people are trying to claim (also we don't want one ping per SA we need one ping per GW/HOST pair, there might be thousands of SAs between two machines). Birthday certificate with INVALID-SPI notification would be excellent for the black hole detection, but we still propably need something else for the NAT traversal case. -- 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 Wed Aug 9 08:13:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24331; Wed, 9 Aug 2000 08:13:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10288 Wed, 9 Aug 2000 10:08:21 -0400 (EDT) Message-ID: <39916839.A42B45C1@F-Secure.com> Date: Wed, 09 Aug 2000 17:18:33 +0300 From: Ari Huttunen Organization: F-Secure Oyj X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tero Kivinen CC: "Theodore Ts'o" , ebooth@cisco.com, smb@research.att.com, sommerfeld@East.Sun.COM, sfanning@cisco.com, warlord@mit.edu, skelly@redcreek.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <200008090248.WAA09563@trampoline.thunk.org> <200008091317.QAA19824@torni.hel.fi.ssh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero Kivinen wrote: > > Theodore Ts'o writes: > > Neither of these (accounting and returning IP addresses to a DHCP pool) > > are IPSEC issues. This is stuff you have to deal with even if you're > > not using IPSEC. Hence, solving it with an IPSEC-specific solution > > seems like we're barking up the wrong tree. > > Most of the NAT traversal proposal that encapsulate IPsec inside UDP > packets needs some kind of keepalive protocol to keep the NAT from > deleting the UDP "connection". > > In that cases it doesn't matter if it is phase 1 or phase 2 "ping". I think it does matter if the UDP traffic is sent to a different port than 500. -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Wed Aug 9 09:43:15 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA03638; Wed, 9 Aug 2000 09:43:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA10544 Wed, 9 Aug 2000 11:09:43 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Tero Kivinen Cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Aug 2000 11:19:28 -0400 Message-Id: <20000809151929.80AA135DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200008091317.QAA19824@torni.hel.fi.ssh.com>, Tero Kivinen writes: > >Also a comment for those who complain about keepalives being >make-deads, that is NOT TRUE for the ipsec traffic. Your TCP/IP >session is not dead even if the IPsec SA is removed. The SA will be >recreated immediately when you send your next packet to that >connection. But the proponents of this scheme keep saying that they need to free up the (inner) IP addresses, which will indeed cause the TCP sessions to die the true death. If it's not IP addresses we're concerned with, what resource are we trying to conserve? Your other points -- about the possible operational necessity for this scheme -- are far more important, and deserve a lot more scrutiny and thought. While I'm far from convinced that heartbeats (especially IKE-level heartbeats) are the right way to deal with the issue, black hole routes have historically been a problem on the net, and we need to ensure that we are not creating more of them. --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Aug 9 12:12:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07761; Wed, 9 Aug 2000 12:12:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11084 Wed, 9 Aug 2000 13:37:27 -0400 (EDT) Message-Id: <200008091747.NAA07500@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: Your message of "Wed, 09 Aug 2000 11:19:28 EDT." <20000809151929.80AA135DC2@smb.research.att.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 09 Aug 2000 13:47:20 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Steven" == Steven M Bellovin writes: Steven> In message <200008091317.QAA19824@torni.hel.fi.ssh.com>, Tero Steven> Kivinen writes: >> Also a comment for those who complain about keepalives being >> make-deads, that is NOT TRUE for the ipsec traffic. Your TCP/IP >> session is not dead even if the IPsec SA is removed. The SA will be >> recreated immediately when you send your next packet to that >> connection. Steven> But the proponents of this scheme keep saying that they need to Steven> free up the (inner) IP addresses, which will indeed cause the TCP Steven> sessions to die the true death. If it's not IP addresses we're Steven> concerned with, what resource are we trying to conserve? Those who need to free up the inner IP address can do so. That does not change the heartbeat protocol itself. The question is: "how do I detect that the SA is no longer valid?" not: "what should I do when the SA dies?" Steven> Your other points -- about the possible operational necessity for Steven> this scheme -- are far more important, and deserve a lot more Steven> scrutiny and thought. While I'm far from convinced that Steven> heartbeats (especially IKE-level heartbeats) are the right way to Steven> deal with the issue, black hole routes have historically been a Steven> problem on the net, and we need to ensure that we are not Steven> creating more of them. Left for emphasis. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Wed Aug 9 12:13:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07775; Wed, 9 Aug 2000 12:12:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11036 Wed, 9 Aug 2000 13:26:12 -0400 (EDT) Message-ID: <399195F6.C21F3863@redcreek.com> Date: Wed, 09 Aug 2000 10:33:42 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <20000808203644.302DE35DC2@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" wrote: > > In message , Paul Hoffman / VPNC writes > : > > > > >So far, the two gateway resources that have been best identified are > >state memory and IP addresses. Despite memory being cheap, we might > >want to conserve it if the process for conserving it is not too > >onerous. As for IP addresses, we don't need to be any more aggressive > >about them than the current protocol that uses them, namely DHCP. > > Precisely. In ipsra, it was pointed out that we need some sort of > identifier to pass to DHCP in lieu of a MAC address. If we use, say, > the cert-id, someone who dials in anew and negotiates a new SA will get > the same DHCP address, which is exactly what you want to preserve > ongoing application connections. Furthermore, by DHCP semantics you > can't reuse an address until its lease is up, which again means that > you don't need a heartbeat to tell you that you've lost touch. > Maybe I'm misunderstanding you. If you require dhcp to associate a specific cert-id with a specific address, you lose scaling capability, meaning you may as well statically assign the address. What seems more reasonable is to associate a pattern (which the cert-id or whatever you use matches) with an address *pool*, but in this case you have no guarantee that the same address is reassigned in subsequent attempts, and in fact, this is somewhat unlikely. This in turn implies that there may be a window during which addresses become unavailable, but the window size may be reduced by shortening the dhcp lease duration. Scott > As for memory -- pulling out a random catalog that's sitting on my desk > right now, it seems that desktop memory costs ~$2/meg. How many SAs > can I fit in 1 meg? Easily worth the $2, especially when I think of > what the programmer time would be to implement something complex. > > --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Aug 9 12:33:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08337; Wed, 9 Aug 2000 12:33:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA11138 Wed, 9 Aug 2000 13:59:06 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Scott G. Kelly" Cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Aug 2000 14:08:51 -0400 Message-Id: <20000809180851.7E3BA35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <399195F6.C21F3863@redcreek.com>, "Scott G. Kelly" writes: >"Steven M. Bellovin" wrote: >> > >> Precisely. In ipsra, it was pointed out that we need some sort of >> identifier to pass to DHCP in lieu of a MAC address. If we use, say, >> the cert-id, someone who dials in anew and negotiates a new SA will get >> the same DHCP address, which is exactly what you want to preserve >> ongoing application connections. Furthermore, by DHCP semantics you >> can't reuse an address until its lease is up, which again means that >> you don't need a heartbeat to tell you that you've lost touch. >> > >Maybe I'm misunderstanding you. If you require dhcp to associate a >specific cert-id with a specific address, you lose scaling capability, >meaning you may as well statically assign the address. What seems more >reasonable is to associate a pattern (which the cert-id or whatever you >use matches) with an address *pool*, but in this case you have no >guarantee that the same address is reassigned in subsequent attempts, >and in fact, this is somewhat unlikely. This in turn implies that there >may be a window during which addresses become unavailable, but the >window size may be reduced by shortening the dhcp lease duration. > It's the behavior of DHCP server I'm referring to; see section 4.3.1 of RFC 2131. Briefly, DHCP servers have a pool of addresses that they hand out. If a client with a valid lease requests an address, the old one SHOULD be handed back. If the client had had an address, but it has expired, it SHOULD be given back to that same client if still available. Or, if the client remembers its old address, it can request it specifically; again, it SHOULD be given that address if possible. But no, there is no one-to-one, static mapping of clients to addresses. And clients can do explicit DHCP Release operations to surrender an address if they're done with it. --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Aug 9 12:54:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08657; Wed, 9 Aug 2000 12:54:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11184 Wed, 9 Aug 2000 14:11:32 -0400 (EDT) Message-Id: <200008091820.e79IKBk100765@thunk.east.sun.com> From: Bill Sommerfeld To: "Scott G. Kelly" cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-reply-to: Your message of "Wed, 09 Aug 2000 10:33:42 PDT." <399195F6.C21F3863@redcreek.com> Reply-to: sommerfeld@East.Sun.COM Date: Wed, 09 Aug 2000 14:20:11 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [this conversation really belongs on ipsra, not here..] > Maybe I'm misunderstanding you. If you require dhcp to associate a > specific cert-id with a specific address, you lose scaling capability, > meaning you may as well statically assign the address. No, it's not quite that bad. The way good dhcp servers work is that if the address you last used hasn't been recycled when you come back, then you get it back, otherwise you get a different free address from the pool. (DHCP over ethernet uses either the DHCP client id or the client's MAC address for this) The addresses are really free and available for reallocation to someone else when you release them or when the lease expires, but the server still retains the metadata about the last user of a freed address so you might be able to get you your old one back. Ideally you do LRU recycling of the free address pool, so that, even if, on average, an address is recycled many times a day, you're still likely to get the same address back if you're only disconnected for a few minutes.. - Bill From owner-ipsec@lists.tislabs.com Thu Aug 10 04:26:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA05714; Thu, 10 Aug 2000 04:26:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA13924 Thu, 10 Aug 2000 05:44:44 -0400 (EDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D2839E@new-exc1.ctron.com> From: "Waters, Stephen" To: "Steven M. Bellovin" Cc: ipsec@lists.tislabs.com Subject: RE: Heartbeats Straw Poll Date: Thu, 10 Aug 2000 10:54:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I haven't been following these notes, but here is a view anyway: LAN-LAN VPN - for these, it is very important to know if the link is up or not. To solve this one at the 'virtual data-link' level, we used a ping as a keepalive. The tunnel is an IPIP tunnel which uses a 'socket' interface to IPSEC to request transport mode protection. One the exchange of polls, the interface is marked 'up'. If n polls are missing, it is marked down (with routing and fail-over links taking the appropriate action). Client - the same ping method could be used for used tunnels. The objections to this is the past have been that this would mandate the client being allowed (through IPSEC policy) to ping the security gateways. I don't see why this is such a big deal. Using this, the security gateway can run an idle time on the IPSEC SAs - to allow DHCP addresses and 'crypto-session' resources to be recycled. If the client wants to check if the security gateway is still 'connected', just use the ping - no need for the security gateway generate them, just reply. Having said that, we have implemented the IKE-based keepalive as supported by a well know IPSEC client. Steve. -----Original Message----- From: Steven M. Bellovin [mailto:smb@research.att.com] Sent: Wednesday, August 09, 2000 4:19 PM To: Tero Kivinen Cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In message <200008091317.QAA19824@torni.hel.fi.ssh.com>, Tero Kivinen writes: > >Also a comment for those who complain about keepalives being >make-deads, that is NOT TRUE for the ipsec traffic. Your TCP/IP >session is not dead even if the IPsec SA is removed. The SA will be >recreated immediately when you send your next packet to that >connection. But the proponents of this scheme keep saying that they need to free up the (inner) IP addresses, which will indeed cause the TCP sessions to die the true death. If it's not IP addresses we're concerned with, what resource are we trying to conserve? Your other points -- about the possible operational necessity for this scheme -- are far more important, and deserve a lot more scrutiny and thought. While I'm far from convinced that heartbeats (especially IKE-level heartbeats) are the right way to deal with the issue, black hole routes have historically been a problem on the net, and we need to ensure that we are not creating more of them. --Steve Bellovin From owner-ipsec@lists.tislabs.com Thu Aug 10 10:08:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02908; Thu, 10 Aug 2000 10:08:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15325 Thu, 10 Aug 2000 11:48:08 -0400 (EDT) Date: Thu, 10 Aug 2000 08:56:57 -0700 (PDT) From: "Chinna N.R. Pellacuru" To: "Theodore Y. Ts'o" cc: Skip Booth , smb@research.att.com, sommerfeld@East.Sun.COM, sfanning@cisco.com, warlord@mit.edu, skelly@redcreek.com, paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: <200008091216.IAA03331@tsx-prime.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 9 Aug 2000, Theodore Y. Ts'o wrote: > > The idea here is that we need to simplify and fix IKE, and we can't do > that if people want to keep wanting to add hacks to it. > > - Ted > I vote for this approach. If there is a problem in IKE we should try and fix it, instead of hacking, or working around the base problems. I guess, it would be important to list out what problems the proposed keepalives are trying to solve. I feel that the problems that it is trying to solve has come a full circle from helping to see if the server is dead, to now saying that it helps to know when the client is dead, for accounting and resource cleanup. I would like to reiterate that from our experience with implementing and deploying keepalives, they scale very poorly, and the performance hit is not worth the benefits. chinna chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Aug 10 10:10:13 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03005; Thu, 10 Aug 2000 10:10:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15252 Thu, 10 Aug 2000 11:38:18 -0400 (EDT) Message-ID: <3992CE2A.99CDB05@redcreek.com> Date: Thu, 10 Aug 2000 08:45:46 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: ipsec@lists.tislabs.com, "Sommerfeld, Bill" Subject: Re: Heartbeats Straw Poll References: <20000809180851.7E3BA35DC2@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" wrote: > >Maybe I'm misunderstanding you. If you require dhcp to associate a > >specific cert-id with a specific address, you lose scaling capability, > >meaning you may as well statically assign the address. What seems more > >reasonable is to associate a pattern (which the cert-id or whatever you > >use matches) with an address *pool*, but in this case you have no > >guarantee that the same address is reassigned in subsequent attempts, > >and in fact, this is somewhat unlikely. This in turn implies that there > >may be a window during which addresses become unavailable, but the > >window size may be reduced by shortening the dhcp lease duration. > > > > It's the behavior of DHCP server I'm referring to; see section 4.3.1 > of RFC 2131. Briefly, DHCP servers have a pool of addresses that they > hand out. If a client with a valid lease requests an address, the old > one SHOULD be handed back. If the client had had an address, but it > has expired, it SHOULD be given back to that same client if still > available. Or, if the client remembers its old address, it can request > it specifically; again, it SHOULD be given that address if possible. > > But no, there is no one-to-one, static mapping of clients to addresses. > And clients can do explicit DHCP Release operations to surrender an > address if they're done with it. > > --Steve Bellovin Boy, do I feel stupid... Thanks for the enlightenment, sorry for the misunderstanding. Scott From owner-ipsec@lists.tislabs.com Thu Aug 10 10:56:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05288; Thu, 10 Aug 2000 10:56:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15969 Thu, 10 Aug 2000 12:49:29 -0400 (EDT) X-Authentication-Warning: tml-gw.tml.hut.fi: smap set sender to using -f Date: Thu, 10 Aug 2000 17:31:48 +0300 (EET DST) From: Helger Lipmaa To: Sheila Frankel cc: "Steven M. Bellovin" , ipsec@lists.tislabs.com Subject: Re: IV sizes for AES candidates In-Reply-To: <3.0.2.32.20000808110644.007346a0@email.nist.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 8 Aug 2000, Sheila Frankel wrote: > If the consensus of the group is that we should stick with the > tried-and-true CBC mode, that's fine with us, and the next version of the > draft will reflect that. No!!! This is NOT the consensus. At least the counter mode should also being reconsidered as a standard. [Somewhere in spring I announced that a draft, coauthored by me and Phil Rogaway, on counter mode was in works. Unfortunately, by many obstacles it is still in works, but it will be ready during this month!] > The only keysize required by the draft is 128 bits; the others are > optional. We are interested in comments from the list - should the other > key sizes be mentioned at all? any other comments on the "IKE Interactions" > section? Other key sizes have no practical benefit at this moment. > > By the way, has anyone else implemented any of the AES candidates in IPsec > and/or IKE? I've implemented all AES candidates, but not in context of IPSec. Helger From owner-ipsec@lists.tislabs.com Thu Aug 10 11:00:38 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05630; Thu, 10 Aug 2000 11:00:37 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15981 Thu, 10 Aug 2000 12:51:29 -0400 (EDT) Message-Id: <3.0.32.20000810114450.00bfe680@zbl6c000.corpeast.baynetworks.com> X-Sender: smamros@zbl6c000.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 10 Aug 2000 11:44:51 -0400 To: Ben McCann X-Sybari-Space: 00000000 00000000 00000000 From: "Shawn Mamros" Subject: Re: Heartbeats Straw Poll Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >IMHO, a heartbeat protocol should run over a dedicated transport mode >Phase 2 SA whose selector is specific to the heartbeat mechanism. I >would allocate a new UDP port number specifically for the heartbeat >mechanism just so it can distinguished from all other user data. An >IPSEC peer that wants keepalives just has to create this SA using a >standard quick mode exchange. A peer that _doesn't_ want to accept >the heart-beat protocol can deny the quick mode request via its SPD. Why reinvent the wheel? We have a protocol that already does this: ICMP. IPsec transport mode SA, negotiated specifically for ICMP, between the two endpoint addresses. No changes to IKE necessary, just a matter of policy on both sides. Don't want heartbeats? Don't set up the SA. Either side can initiate a ping anytime they want. No need to negotiate intervals, or retry counts, or any of that. Each side decides their own policy in this regard. If the other side doesn't answer, delete the SA and any other SAs considered to be related. Since it's a separate SA, those who don't want to add the ping packets to their accounting records can choose not to do so. Rekey interval for the ICMP SA can be set as appropriate, if one wants to check on the health of the IKE SA on the other side. Simple. Clean. Effective. Not covered by any patents I know of. Works. Right? -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Thu Aug 10 11:09:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06300; Thu, 10 Aug 2000 11:09:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16113 Thu, 10 Aug 2000 13:02:53 -0400 (EDT) Message-ID: <3992E025.E5E74FF6@indusriver.com> Date: Thu, 10 Aug 2000 13:02:30 -0400 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Shawn Mamros CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <3.0.32.20000810114450.00bfe680@zbl6c000.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Shawn Mamros wrote: > > >IMHO, a heartbeat protocol should run over a dedicated transport mode > >Phase 2 SA whose selector is specific to the heartbeat mechanism. I > >would allocate a new UDP port number specifically for the heartbeat > >mechanism just so it can distinguished from all other user data. An > >IPSEC peer that wants keepalives just has to create this SA using a > >standard quick mode exchange. A peer that _doesn't_ want to accept > >the heart-beat protocol can deny the quick mode request via its SPD. > > Why reinvent the wheel? We have a protocol that already does this: > ICMP. I originally thought ICMP was OK too, but several people have argued against it. For example: 1. ICMP may not be passed or acknowledged due to security policy. 2. ICMP may be counted against usage statistics thus adding bytes the user didn't send. 3. ICMP "heartbeat" packets can't be dropped by the SPD (if that is your policy) without dropping all other legitimate ICMP packets. I suggested a separate UDP protocol port just to make it unambiguous so heartbeats can be omitted easily from statistics and so they can be controlled via the SPD without affecting other ICMP traffic. If these arguments aren't sufficiently strong then I agree with you that ICMP is a very viable heartbeat mechanism. > > IPsec transport mode SA, negotiated specifically for ICMP, between > the two endpoint addresses. No changes to IKE necessary, just a > matter of policy on both sides. Don't want heartbeats? Don't set > up the SA. > > Either side can initiate a ping anytime they want. No need to > negotiate intervals, or retry counts, or any of that. Each side > decides their own policy in this regard. If the other side doesn't > answer, delete the SA and any other SAs considered to be related. > > Since it's a separate SA, those who don't want to add the ping > packets to their accounting records can choose not to do so. > > Rekey interval for the ICMP SA can be set as appropriate, if one > wants to check on the health of the IKE SA on the other side. > > Simple. Clean. Effective. Not covered by any patents I know of. > Works. Right? I agree that anything that uses a separate SA is simple and clean. It has overhead that some people find objectionable. But, I think any heartbeat protocol will have overhead. I'd rather have another SA between two IPSEC peers instead of additional protocol complexity withn IKE itself. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 From owner-ipsec@lists.tislabs.com Thu Aug 10 11:38:03 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08225; Thu, 10 Aug 2000 11:38:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16264 Thu, 10 Aug 2000 13:29:42 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE990F@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: ipsec@lists.tislabs.com Subject: RE: IV sizes for AES candidates Date: Thu, 10 Aug 2000 10:39:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I share Helger's desire to at least consider counter mode for AES. Counter mode is an opportunity to gain better data privacy than CBC mode offers and perhaps better performance as well. The WG can fall back to CBC mode if scrutiny reveals counter mode is somehow inapplicable within ESP. -- Jesse -----Original Message----- From: Helger Lipmaa [mailto:helger@tml.hut.fi] Sent: Thursday, August 10, 2000 7:32 AM To: Sheila Frankel Cc: Steven M. Bellovin; ipsec@lists.tislabs.com Subject: Re: IV sizes for AES candidates On Tue, 8 Aug 2000, Sheila Frankel wrote: > If the consensus of the group is that we should stick with the > tried-and-true CBC mode, that's fine with us, and the next version of the > draft will reflect that. No!!! This is NOT the consensus. At least the counter mode should also being reconsidered as a standard. [Somewhere in spring I announced that a draft, coauthored by me and Phil Rogaway, on counter mode was in works. Unfortunately, by many obstacles it is still in works, but it will be ready during this month!] > The only keysize required by the draft is 128 bits; the others are > optional. We are interested in comments from the list - should the other > key sizes be mentioned at all? any other comments on the "IKE Interactions" > section? Other key sizes have no practical benefit at this moment. > > By the way, has anyone else implemented any of the AES candidates in IPsec > and/or IKE? I've implemented all AES candidates, but not in context of IPSec. Helger From owner-ipsec@lists.tislabs.com Thu Aug 10 12:31:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09726; Thu, 10 Aug 2000 12:31:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16541 Thu, 10 Aug 2000 14:19:16 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Walker, Jesse" Cc: ipsec@lists.tislabs.com Subject: Re: IV sizes for AES candidates Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Aug 2000 14:29:13 -0400 Message-Id: <20000810182913.D7F8535DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <392A357CE6FFD111AC3E00A0C99848B002FE990F@hdsmsx31.hd.intel.com>, "W alker, Jesse" writes: >I share Helger's desire to at least consider counter mode for AES. Counter >mode is an opportunity to gain better data privacy than CBC mode offers and >perhaps better performance as well. The WG can fall back to CBC mode if >scrutiny reveals counter mode is somehow inapplicable within ESP. Counter mode appears to be one instance of a "seekable stream cipher", per draft-mcgrew-ipsec-scesp-00.txt. As was discussed in Pittsburgh, there are a number of limitations, including the very strong requirement for authentication and the need for a flat-out ban on using it with manual keying -- if you don't use IKE, there's just too much risk of seeing two streams encrypted with the same key and counter. --Steve Bellovin From owner-ipsec@lists.tislabs.com Thu Aug 10 12:53:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10870; Thu, 10 Aug 2000 12:53:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16735 Thu, 10 Aug 2000 14:51:30 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE9912@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Steven M. Bellovin'" Cc: ipsec@lists.tislabs.com Subject: RE: IV sizes for AES candidates Date: Thu, 10 Aug 2000 12:01:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, No disagreement on the points you raise. It still seems like something worth considering. -- Jesse -----Original Message----- From: Steven M. Bellovin [mailto:smb@research.att.com] Sent: Thursday, August 10, 2000 11:29 AM To: Walker, Jesse Cc: ipsec@lists.tislabs.com Subject: Re: IV sizes for AES candidates In message <392A357CE6FFD111AC3E00A0C99848B002FE990F@hdsmsx31.hd.intel.com>, "W alker, Jesse" writes: >I share Helger's desire to at least consider counter mode for AES. Counter >mode is an opportunity to gain better data privacy than CBC mode offers and >perhaps better performance as well. The WG can fall back to CBC mode if >scrutiny reveals counter mode is somehow inapplicable within ESP. Counter mode appears to be one instance of a "seekable stream cipher", per draft-mcgrew-ipsec-scesp-00.txt. As was discussed in Pittsburgh, there are a number of limitations, including the very strong requirement for authentication and the need for a flat-out ban on using it with manual keying -- if you don't use IKE, there's just too much risk of seeing two streams encrypted with the same key and counter. --Steve Bellovin From owner-ipsec@lists.tislabs.com Thu Aug 10 13:01:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11667; Thu, 10 Aug 2000 13:01:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16825 Thu, 10 Aug 2000 14:59:36 -0400 (EDT) Message-Id: <200008101909.PAA03848@solidum.com> To: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll In-Reply-To: Your message of "Thu, 10 Aug 2000 11:44:51 EDT." <3.0.32.20000810114450.00bfe680@zbl6c000.corpeast.baynetworks.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 10 Aug 2000 15:09:34 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Shawn" == Shawn Mamros writes: Shawn> Why reinvent the wheel? We have a protocol that already does Shawn> this: ICMP. Shawn> IPsec transport mode SA, negotiated specifically for ICMP, between Shawn> the two endpoint addresses. No changes to IKE necessary, just a Shawn> matter of policy on both sides. Don't want heartbeats? Don't set Shawn> up the SA. Shawn> Either side can initiate a ping anytime they want. No need to Shawn> negotiate intervals, or retry counts, or any of that. Each side Shawn> decides their own policy in this regard. If the other side Shawn> doesn't answer, delete the SA and any other SAs considered to be Shawn> related. a) this may not be entirely clear Shawn> Since it's a separate SA, those who don't want to add the ping b) since it is a seperate SA, it really tells you nothing about the SAs that you want to use c) hardware devices have typically a limited number of slots for SAs, so one would prefer not to double the number of them and cause thrashing. d) I think that ICMP should always fit into all SAs anyway. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-ipsec@lists.tislabs.com Thu Aug 10 15:29:19 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17680; Thu, 10 Aug 2000 15:29:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17237 Thu, 10 Aug 2000 16:54:09 -0400 (EDT) Date: Thu, 10 Aug 2000 14:00:11 -0700 From: Waleed Alrawi Subject: IPsec FreesWan and win2k workstation To: ipsec@lists.tislabs.com Reply-to: htcengrs@pacbell.net Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Priority: 3 (Normal) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk is there a way to connect win2k workstation (road warrior) to VPN Linux box running FreesWan any input would be appreciated. From owner-ipsec@lists.tislabs.com Thu Aug 10 16:52:24 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA21573; Thu, 10 Aug 2000 16:52:23 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17476 Thu, 10 Aug 2000 18:42:09 -0400 (EDT) Message-ID: <008a01c0031d$623c5570$7e2645ab@cisco.com> From: "Scott Fanning" To: "Shawn Mamros" Cc: References: <3.0.32.20000810114450.00bfe680@zbl6c000.corpeast.baynetworks.com> Subject: Re: Heartbeats Straw Poll Date: Thu, 10 Aug 2000 15:50:30 -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 Shawn Speaking of patents, you spoke of the one Nortel has on Keepalives. Could you point us to the patent you were referring to? Thanks Scott ----- Original Message ----- From: "Shawn Mamros" To: "Ben McCann" Cc: Sent: Thursday, August 10, 2000 8:44 AM Subject: Re: Heartbeats Straw Poll > >IMHO, a heartbeat protocol should run over a dedicated transport mode > >Phase 2 SA whose selector is specific to the heartbeat mechanism. I > >would allocate a new UDP port number specifically for the heartbeat > >mechanism just so it can distinguished from all other user data. An > >IPSEC peer that wants keepalives just has to create this SA using a > >standard quick mode exchange. A peer that _doesn't_ want to accept > >the heart-beat protocol can deny the quick mode request via its SPD. > > Why reinvent the wheel? We have a protocol that already does this: > ICMP. > > IPsec transport mode SA, negotiated specifically for ICMP, between > the two endpoint addresses. No changes to IKE necessary, just a > matter of policy on both sides. Don't want heartbeats? Don't set > up the SA. > > Either side can initiate a ping anytime they want. No need to > negotiate intervals, or retry counts, or any of that. Each side > decides their own policy in this regard. If the other side doesn't > answer, delete the SA and any other SAs considered to be related. > > Since it's a separate SA, those who don't want to add the ping > packets to their accounting records can choose not to do so. > > Rekey interval for the ICMP SA can be set as appropriate, if one > wants to check on the health of the IKE SA on the other side. > > Simple. Clean. Effective. Not covered by any patents I know of. > Works. Right? > > -Shawn Mamros > E-mail to: smamros@nortelnetworks.com > > From owner-ipsec@lists.tislabs.com Thu Aug 10 22:56:51 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA18460; Thu, 10 Aug 2000 22:56:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA18095 Fri, 11 Aug 2000 00:31:20 -0400 (EDT) Date: Fri, 11 Aug 2000 00:41:13 -0400 Message-Id: <200008110441.AAA03479@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: "Steven M. Bellovin" CC: "Walker, Jesse" , ipsec@lists.tislabs.com In-reply-to: Steven M. Bellovin's message of Thu, 10 Aug 2000 14:29:13 -0400, <20000810182913.D7F8535DC2@smb.research.att.com> Subject: Re: IV sizes for AES candidates Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: "Steven M. Bellovin" Date: Thu, 10 Aug 2000 14:29:13 -0400 In message <392A357CE6FFD111AC3E00A0C99848B002FE990F@hdsmsx31.hd.intel.com>, "W alker, Jesse" writes: >I share Helger's desire to at least consider counter mode for AES. Counter >mode is an opportunity to gain better data privacy than CBC mode offers and >perhaps better performance as well. The WG can fall back to CBC mode if >scrutiny reveals counter mode is somehow inapplicable within ESP. Counter mode appears to be one instance of a "seekable stream cipher", per draft-mcgrew-ipsec-scesp-00.txt. As was discussed in Pittsburgh, there are a number of limitations, including the very strong requirement for authentication and the need for a flat-out ban on using it with manual keying -- if you don't use IKE, there's just too much risk of seeing two streams encrypted with the same key and counter. When we talked how IV's for CBC mode, we were told that using a counter for the IV was a bad idea, because if the first eight bytes were known and fixed (as they commonly were), you could end up with known plaintext/ciphertext pairs that were a low hamming distance apart, and this could be used as a wedge to attack a cipher. If you use counter mode, doesn't this guarantee that in the face of known plaintext, you'll have a *lot* of known plaintext/cipgertext that have a low haming distance, and so would be subject to the same attacks as mentioned in the previous paragraph, right? So wouldn't the argument that says that we shouldn't use a counter to generate IV's also mean that using counter mode would also be a bad idea? (This is in addition to all of the issues of an absolute requirement for using a MAC if you care about message integrity at all, and the dangers of resusing a keystream if you're not careful.) - Ted From owner-ipsec@lists.tislabs.com Fri Aug 11 05:08:08 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10888; Fri, 11 Aug 2000 05:08:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA19157 Fri, 11 Aug 2000 06:51:05 -0400 (EDT) Message-Id: <200008111100.HAA08631@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-hybrid-auth-05.txt Date: Fri, 11 Aug 2000 07:00:54 -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 Hybrid Authentication Mode for IKE Author(s) : M. Litvin, R. Shamir, T. Zegman Filename : draft-ietf-ipsec-isakmp-hybrid-auth-05.txt Pages : 10 Date : 10-Aug-00 This document describes a set of new authentication methods to be used within Phase 1 of the Internet Key Exchange (IKE). The proposed methods assume an asymmetry between the authenticating entities. One entity, typically an Edge Device (e.g. firewall), authenticates using standard public key techniques (in signature mode), while the other entity, typically a remote User, authenticates using challenge response techniques. These authentication methods are used to establish, at the end of Phase 1, an IKE SA which is unidirectionally authenticated. To make this IKE bi-directionally authenticated, this Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The X-Auth Exchange is used to authenticate the remote User. The use of these authentication methods is referred to as Hybrid Authentication mode. This proposal is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-05.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-hybrid-auth-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000810140008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-hybrid-auth-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000810140008.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Aug 11 06:04:36 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14784; Fri, 11 Aug 2000 06:04:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19410 Fri, 11 Aug 2000 08:07:27 -0400 (EDT) Message-Id: <200008111100.HAA08631@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-hybrid-auth-05.txt Date: Fri, 11 Aug 2000 07:00:54 -0400 X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 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 Hybrid Authentication Mode for IKE Author(s) : M. Litvin, R. Shamir, T. Zegman Filename : draft-ietf-ipsec-isakmp-hybrid-auth-05.txt Pages : 10 Date : 10-Aug-00 This document describes a set of new authentication methods to be used within Phase 1 of the Internet Key Exchange (IKE). The proposed methods assume an asymmetry between the authenticating entities. One entity, typically an Edge Device (e.g. firewall), authenticates using standard public key techniques (in signature mode), while the other entity, typically a remote User, authenticates using challenge response techniques. These authentication methods are used to establish, at the end of Phase 1, an IKE SA which is unidirectionally authenticated. To make this IKE bi-directionally authenticated, this Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The X-Auth Exchange is used to authenticate the remote User. The use of these authentication methods is referred to as Hybrid Authentication mode. This proposal is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-05.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-hybrid-auth-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000810140008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-hybrid-auth-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-hybrid-auth-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000810140008.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Aug 11 08:06:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21026; Fri, 11 Aug 2000 08:06:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA19841 Fri, 11 Aug 2000 10:06:15 -0400 (EDT) Message-ID: <39940A40.BBE481F0@helios.iihe.ac.be> Date: Fri, 11 Aug 2000 16:14:25 +0200 From: Alain Jourez X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IKE key derivation. 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 KAA19837 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a question about key derivation in IKE. When you generate the keying material as explained in RFC2409 (§5.5) after a quick mode you get: KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b, Nr_b) or KEYMAT = prf(SKEYID_d, g(qm) ^xy | protocol | SPI | Ni_b, Nr_b) -- if pfs is used. Then a bit further : RFC2409>> It is up to the service to define how keys are derived from the keying material. For AH this is straightforward since you just have to derive one key. But my problem is how to use that keying material to derive the ciphering key and the authentication key for ESP (using both authentication and confidentiality services) ? Should I select the first bits for the ciphering key or for the authentication key ? I did'nt manage to find the answers in the RFCs. Thanks for your help. Regards. Alain. -- Alain Jourez Service Télématique et Communication Université Libre de Bruxelles Tél. +32 (0) 2 650 57 04 Boulevard du Triomphe, CP 230 Fax +32 (0) 2 629 38 16 B-1050 Bruxelles - Belgium mailto:alain.jourez@helios.iihe.ac.be From owner-ipsec@lists.tislabs.com Fri Aug 11 09:46:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00658; Fri, 11 Aug 2000 09:46:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20063 Fri, 11 Aug 2000 11:28:22 -0400 (EDT) Message-ID: <392A357CE6FFD111AC3E00A0C99848B002FE991C@hdsmsx31.hd.intel.com> From: "Walker, Jesse" To: "'Theodore Y. Ts'o'" Cc: ipsec@lists.tislabs.com Subject: RE: IV sizes for AES candidates Date: Fri, 11 Aug 2000 08:38:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted: Maybe I'm just slow, but I don't follow your point about the known plaintext. Bellare, Killian, and Rogaway's proof of the security of counter and CBC modes starts with the assumption that ALL the encrypted data is chosen plaintext, not just known plaintext. It seems to me their theorem says if you don't trust your block cipher and key in counter mode, you shouldn't trust them to any greater extent in CBC mode, and you have plausible grounds to trust them even less. What am I missing? You seem to be implying there is a proof of some other theorem saying CBC mode is at least as secure as counter mode when the plaintext is only known and not chosen, or when used with "real" instead of ideal block ciphers, or ...? My belief is that Steve's reservations about counter mode are the sorts of concerns that a counter mode proposal has to address. I don't understand the problem you raise. -- Jesse -----Original Message----- From: Theodore Y. Ts'o [mailto:tytso@MIT.EDU] Sent: Thursday, August 10, 2000 9:41 PM To: Steven M. Bellovin Cc: Walker, Jesse; ipsec@lists.tislabs.com Subject: Re: IV sizes for AES candidates From: "Steven M. Bellovin" Date: Thu, 10 Aug 2000 14:29:13 -0400 In message <392A357CE6FFD111AC3E00A0C99848B002FE990F@hdsmsx31.hd.intel.com>, "W alker, Jesse" writes: >I share Helger's desire to at least consider counter mode for AES. Counter >mode is an opportunity to gain better data privacy than CBC mode offers and >perhaps better performance as well. The WG can fall back to CBC mode if >scrutiny reveals counter mode is somehow inapplicable within ESP. Counter mode appears to be one instance of a "seekable stream cipher", per draft-mcgrew-ipsec-scesp-00.txt. As was discussed in Pittsburgh, there are a number of limitations, including the very strong requirement for authentication and the need for a flat-out ban on using it with manual keying -- if you don't use IKE, there's just too much risk of seeing two streams encrypted with the same key and counter. When we talked how IV's for CBC mode, we were told that using a counter for the IV was a bad idea, because if the first eight bytes were known and fixed (as they commonly were), you could end up with known plaintext/ciphertext pairs that were a low hamming distance apart, and this could be used as a wedge to attack a cipher. If you use counter mode, doesn't this guarantee that in the face of known plaintext, you'll have a *lot* of known plaintext/cipgertext that have a low haming distance, and so would be subject to the same attacks as mentioned in the previous paragraph, right? So wouldn't the argument that says that we shouldn't use a counter to generate IV's also mean that using counter mode would also be a bad idea? (This is in addition to all of the issues of an absolute requirement for using a MAC if you care about message integrity at all, and the dangers of resusing a keystream if you're not careful.) - Ted From owner-ipsec@lists.tislabs.com Fri Aug 11 10:42:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04762; Fri, 11 Aug 2000 10:42:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20267 Fri, 11 Aug 2000 12:31:42 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Walker, Jesse" Cc: "'Theodore Y. Ts'o'" , ipsec@lists.tislabs.com Subject: Re: IV sizes for AES candidates Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Aug 2000 12:41:29 -0400 Message-Id: <20000811164129.B2CBA35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <392A357CE6FFD111AC3E00A0C99848B002FE991C@hdsmsx31.hd.intel.com>, "W alker, Jesse" writes: >Ted: > >Maybe I'm just slow, but I don't follow your point about the known >plaintext. Bellare, Killian, and Rogaway's proof of the security of counter >and CBC modes starts with the assumption that ALL the encrypted data is >chosen plaintext, not just known plaintext. It seems to me their theorem >says if you don't trust your block cipher and key in counter mode, you >shouldn't trust them to any greater extent in CBC mode, and you have >plausible grounds to trust them even less. What am I missing? You seem to be >implying there is a proof of some other theorem saying CBC mode is at least >as secure as counter mode when the plaintext is only known and not chosen, >or when used with "real" instead of ideal block ciphers, or ...? > >My belief is that Steve's reservations about counter mode are the sorts of >concerns that a counter mode proposal has to address. I don't understand the >problem you raise. I haven't seen the proof, but a lot depends on the assumptions about the underlying block cipher. In particular, one needs to know if the cipher is vulnerable to an attack that resembles differential cryptanalysis. CBC mode, even with chosen plaintexts, is quite strong against such attacks if cipher produces random-looking output from encryptions. The reason is that this random block is XORed with the next block of chosen plaintext before encryption, thus destroying the benefit of the choice. The exception, of course, is the first block, where the IV is XORed with your chosen plaintext. If the IV is in some sense weak, there may be a threat -- again, if the underlying block cipher is weak under certain kinds of attacks. See Biryokov and Kushilevitz's paper from CRYPTO '98 for more discussion -- it specifically mentions RFC 1829 as bad, and commends the current scheme for IV selection. Counter mode is, as Ted pointed out, much more suspectible to these attacks. But -- and it's an important "but" -- there is only a problem if the underlying cipher is weak. None of the AES candidates are weak; even DES isn't weak in this sense. But that's against today's variants of differential cryptanalysis -- and new ones seem to pop up regularly. You will find find many prominent cryptographers who aren't worried about such attacks, and feel that counter mode is perfectly adequate. They feel that the proper defense is and should be in the cipher design. You will find others who disagree. In my experience, many of the latter, though they don't wear trenchcoats and pulled-down hats themselves, tend to hang out with folks who do. I don't know if this is significant or not. Personally, I'm looking forward to the NIST workshop on modes of operation in October. I'll certainly report back to this list on the sense of the meeting. --Steve Bellovin From owner-ipsec@lists.tislabs.com Fri Aug 11 11:25:39 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06601; Fri, 11 Aug 2000 11:25:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20455 Fri, 11 Aug 2000 13:21:26 -0400 (EDT) Message-ID: <009c01c003c2$465b9640$4f81003e@checkpoint.com> From: "Tamir Zegman" To: "Theodore Y. Ts'o" , "Steven M. Bellovin" Cc: "Walker, Jesse" , References: <200008110441.AAA03479@tsx-prime.MIT.EDU> Subject: Re: IV sizes for AES candidates Date: Fri, 11 Aug 2000 20:30:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No, the low Hamming distance attack would not work here. The attack goes as follows: Denote a XOR operation by '+' Assume you have 2 messages that differ only on one bit - M and M+1. If you choose their two respective IV's as X and X+1 (that is X and X+1 differ only on the same bit as M and M+1), the two cleartexts will encrypt to the same cipher text. C1 = AES(M+X) C2 = AES(M+1+X+1) = AES(M+X) = C1 In counter mode, if you have two counters with a low Hamming distance you'll get: C1 = AES(X) + M C2 = AES(X+1) + M + 1 Since chances are that E(X) and E(X+1) have a high Hamming distance this attack does not work in counter mode. ----- Original Message ----- From: Theodore Y. Ts'o To: Steven M. Bellovin Cc: Walker, Jesse ; Sent: Friday, August 11, 2000 6:41 AM Subject: Re: IV sizes for AES candidates > From: "Steven M. Bellovin" > Date: Thu, 10 Aug 2000 14:29:13 -0400 > > In message <392A357CE6FFD111AC3E00A0C99848B002FE990F@hdsmsx31.hd.intel.com>, "W > alker, Jesse" writes: > >I share Helger's desire to at least consider counter mode for AES. Counter > >mode is an opportunity to gain better data privacy than CBC mode offers and > >perhaps better performance as well. The WG can fall back to CBC mode if > >scrutiny reveals counter mode is somehow inapplicable within ESP. > > Counter mode appears to be one instance of a "seekable stream cipher", > per draft-mcgrew-ipsec-scesp-00.txt. As was discussed in Pittsburgh, > there are a number of limitations, including the very strong > requirement for authentication and the need for a flat-out ban on using > it with manual keying -- if you don't use IKE, there's just too much > risk of seeing two streams encrypted with the same key and counter. > > When we talked how IV's for CBC mode, we were told that using a counter > for the IV was a bad idea, because if the first eight bytes were known > and fixed (as they commonly were), you could end up with known > plaintext/ciphertext pairs that were a low hamming distance apart, and > this could be used as a wedge to attack a cipher. > > If you use counter mode, doesn't this guarantee that in the face of > known plaintext, you'll have a *lot* of known plaintext/cipgertext that > have a low haming distance, and so would be subject to the same attacks > as mentioned in the previous paragraph, right? > > So wouldn't the argument that says that we shouldn't use a counter to > generate IV's also mean that using counter mode would also be a bad > idea? (This is in addition to all of the issues of an absolute > requirement for using a MAC if you care about message integrity at > all, and the dangers of resusing a keystream if you're not careful.) > > - Ted > > From owner-ipsec@lists.tislabs.com Fri Aug 11 13:16:33 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11708; Fri, 11 Aug 2000 13:16:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20797 Fri, 11 Aug 2000 15:00:39 -0400 (EDT) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Tamir Zegman" Cc: "Theodore Y. Ts'o" , "Walker, Jesse" , ipsec@lists.tislabs.com Subject: Re: IV sizes for AES candidates Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Aug 2000 15:10:32 -0400 Message-Id: <20000811191032.5319E35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <009c01c003c2$465b9640$4f81003e@checkpoint.com>, "Tamir Zegman" writ es: >No, the low Hamming distance attack would not work here. >The attack goes as follows: >Denote a XOR operation by '+' >Assume you have 2 messages that differ only on one bit - M and M+1. >If you choose their two respective IV's as X and X+1 (that is X and X+1 >differ only on the same bit as M and M+1), the two cleartexts will encrypt >to the same cipher text. >C1 = AES(M+X) >C2 = AES(M+1+X+1) = AES(M+X) = C1 > >In counter mode, if you have two counters with a low Hamming distance you'll >get: >C1 = AES(X) + M >C2 = AES(X+1) + M + 1 >Since chances are that E(X) and E(X+1) have a high Hamming distance this >attack does not work in counter mode. That's not the threat model we're concerned about. In fact, all your threat shows is that C1=C2 if the plaintexts are close, and that isn't that important. Let + = addition, ^ = XOR, and assume that there are two plaintext messages from the same stream M1 and M2. Assume further that M1 is k cipherblocks long, and that k is small. (That is reasonable, since 40-50% of packets are ~40 bytes.) I showed in a 1997 paper that (a) if you add a small number to a counter, the old value and the new still agree in most bit positions, and (b) corresponding blocks of adjacent packets from the same stream are likely to be very similar, i.e., have a low Hamming distance between them. Consider the first block of ciphertext from M1 and M2 (I'll forgo writing M1[1] and C1[1]): C1 = AES(X) ^ M1 C2 = AES(X+k) ^ M2 Per my 1997 analysis, M1^M2 != 0, but M1^M2 ~= 0. But C1 ^ C2 = AES(X) ^ M1 ^ AES(X+k) ^ M2 = (AES(X) ^ AES(X+k)) ^ (M1 ^ M2) ~= AES(X) ^ AES(X+k) Also note that the attacker will know X and k -- X, because it's sent in the clear as an "IV", and k from the length of C1. What is then known is X^(X+k) and (approximately) AES(X)^AES(X+k). The first pair has a low Hamming distance, so we have an approximatation to the input pairs and output pairs used for differential cryptanalysis and its relatives. Furthermore, we can do this for each plaintext block in a packet known to be similar to the corresponding block in an adjacent packet. Is this a threat? I think that that question is really the same as "do we know that AES is immune to all current and future variants of differential cryptanalysis?" --Steve Bellovin From owner-ipsec@lists.tislabs.com Fri Aug 11 13:45:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12098; Fri, 11 Aug 2000 13:44:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20985 Fri, 11 Aug 2000 15:40:49 -0400 (EDT) Message-Id: <3.0.32.20000811120719.00c07d20@zbl6c000.corpeast.baynetworks.com> X-Sender: smamros@zbl6c000.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 11 Aug 2000 12:07:19 -0400 To: Scott Fanning X-Sybari-Space: 00000000 00000000 00000000 From: "Shawn Mamros" Subject: Re: Heartbeats Straw Poll Cc: ipsec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:50 PM 8/10/2000 -0700, Scott Fanning wrote: >Shawn > >Speaking of patents, you spoke of the one Nortel has on Keepalives. Could >you point us to the patent you were referring to? I'm trying to track that information down. I'll let you all know as soon as I have it in hand. -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Fri Aug 11 13:46:56 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12093; Fri, 11 Aug 2000 13:44:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA20971 Fri, 11 Aug 2000 15:39:51 -0400 (EDT) Message-Id: <3.0.32.20000810140300.00c00660@zbl6c000.corpeast.baynetworks.com> X-Sender: smamros@zbl6c000.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 10 Aug 2000 14:03:01 -0400 To: Ben McCann X-Sybari-Space: 00000000 00000000 00000000 From: "Shawn Mamros" Subject: Re: Heartbeats Straw Poll Cc: ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I originally thought ICMP was OK too, but several people have >argued against it. For example: > >1. ICMP may not be passed or acknowledged due to security policy. It doesn't have to be "passed" - it's transport mode. One host to another. If you're going through the bother of setting up the SA, then it should flow from that that you're going to process the ICMP echo requests - at least within that SA, if not elsewhere. >2. ICMP may be counted against usage statistics thus adding bytes > the user didn't send. The ICMP traffic is passing through its own transport mode SA. A different SA from any tunnel mode traffic the user may be choosing to send. Thus, there is no confusion between the two. As long as you're doing the counting within the context of the SA (and how else would you count it?), then you just don't count the traffic within the transport mode SA for ICMP. The tunnel mode SA traffic - ICMP or otherwise - still counts. >3. ICMP "heartbeat" packets can't be dropped by the SPD (if that is > your policy) without dropping all other legitimate ICMP packets. Again, separate SA. What happens for ICMP inside of any tunnel mode SA is another matter. The transport mode SA for ICMP - specifically for heartbeats, in the form of ICMP echo aka ping - follows its own SPD rules, tailored for the purpose. >I suggested a separate UDP protocol port just to make it unambiguous >so heartbeats can be omitted easily from statistics and so they can >be controlled via the SPD without affecting other ICMP traffic. If >these arguments aren't sufficiently strong then I agree with you that >ICMP is a very viable heartbeat mechanism. ICMP traffic within its own transport mode SA is just as easy to distinguish as UDP traffic within its own transport mode SA. >I agree that anything that uses a separate SA is simple and clean. >It has overhead that some people find objectionable. But, I think any >heartbeat protocol will have overhead. I'd rather have another SA >between two IPSEC peers instead of additional protocol complexity >withn IKE itself. Makes sense to me... -Shawn Mamros E-mail to: smamros@nortelnetworks.com From owner-ipsec@lists.tislabs.com Fri Aug 11 18:44:44 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA21184; Fri, 11 Aug 2000 18:44:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA21569 Fri, 11 Aug 2000 20:27:25 -0400 (EDT) To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@cs.berkeley.edu (David A. Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: IV sizes for AES candidates Date: 11 Aug 2000 16:44:58 -0700 Organization: A poorly-installed InterNetNews site Lines: 36 Distribution: isaac Message-ID: <8n235q$om$1@blowfish.isaac.cs.berkeley.edu> References: <20000810182913.D7F8535DC2@smb.research.att.com> <200008110441.AAA03479@tsx-prime.MIT.EDU> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Theodore Y. Ts'o wrote: > When we talked how IV's for CBC mode, we were told that using a counter > for the IV was a bad idea, because if the first eight bytes were known > and fixed (as they commonly were), you could end up with known > plaintext/ciphertext pairs that were a low hamming distance apart, and > this could be used as a wedge to attack a cipher. IMHO, the similarity of the inputs to the cipher shouldn't be more than a minor consideration. If your cipher can't resist differential cryptanalysis, you might as well throw it away and replace it with a modern one that can. :-) A bigger worry -- for CBC mode -- with using a counter for your IV is that it can leak information about the plaintext. This vulnerability is specific to CBC mode, and does not occur with OFB mode or counter mode. Technical details may be found below. So, I wouldn't be worried about using a counter for OFB or counter mode. Here are the technical details. To quote from Phil Rogaway's comments to the IPSEC working group back in 1996, ``As an example, it is not true that CBC encryption can use an arbitrary nonce initialization vector: it is essential that the IV be unpredictable by the adversary. (To see this, suppose the IV is a sequence number: 0, 1, 2, ... . Then a (first) encryp- tion of 0x0000000000000000 followed by an encryption of 0x0000000000000001 is recognizably distinct from a (first) encryption of 0x0000000000000000 followed by an encryption of 0x0000000000000000. Clearly this violates violates the notion of a secure encryption sketched in Section 2.'' http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt This illustrates why the problem with using a counter for your IV is specific to CBC mode, and is not problematic for OFB or counter mode. From owner-ipsec@lists.tislabs.com Fri Aug 11 19:33:59 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25688; Fri, 11 Aug 2000 19:33:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21759 Fri, 11 Aug 2000 21:41:46 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: Subject: RE: Heartbeats Straw Poll (part 2) Date: Fri, 11 Aug 2000 21:45:02 -0400 Message-Id: <000201c003fe$ef304b30$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200008041753.KAA15075@gallium.network-alchemy.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Part 2: alternate proposals Derrell: > SGW2 could do a Main Mode under any Phase 1 policy that he > has to SGW3 and in > the process, tell him INITIAL-CONTACT. No subsequent QM's > would happen until > the next packet hits SGW3. You would want to rate limit this > to prevent the > obvious DoS attack on the receiving side. Our product > implements this and it > works well. (Of course, our clustered gateways have > replicated IKE state, so > this is a non-problem for most of our customers.) Well, yes we do this too, and we also have clustering capabilities, but I don't think this is necessarily the correct solution. The rate limiting approach has too many loopholes, and I don't think it would stand up against a concerted attack. I also think it is better if the side which has the state initiates the recovery SA. As for clustering, maybe that is the correct business case. Normally, clustering only prevents service interruptions during a reboot, but I suppose it could also prevent synchronization problems from happening. It still bugs me to not have self-stablization properties in a protocol which allows many divergent implementations and which does not make an effort to avoid synchronization problems. Maybe if we went back and required continuous channel mode, re-introduced acknowledged notifies, and mandated the use of redundant clusters, then we could get away with a protocol that isn't self-stabilizing. As a note about clusters, I do believe there are some customers who have the requirement that a sgw must never divulge a key, not even to another cluster member. (That was one of the motivations for Vlado's draft, BTW.) Dan: > I know of two different implementations that have an > interoperable "IKE-level > ping"-- one side sends a "LIKE_HELLO" (private notify value > 30000) the other > sends back "SHUT_UP" (private notify value 30002). It's very useful. Ah yes, the famous code segment: // results of richardson NOTIFY_LIKE_HELLO = 30001, NOTIFY_WHEN_IS_THAT_EVER_RIGHT, NOTIFY_LIKE_SHUT_UP, which has been in our code for years but no one ever knew what it meant (not even Roy, who wrote it). Legend has it this was developed in a bar amongst much drunken hilarity?!? BTW, it seems that our magic numbers are wrong, which is strange... Derek: > If you're really that worried about the resources for "dead" SAs, > negotiate relatively short rekey times, at which point if your peer > disappears, the SA will timeout in a relatively short time. In which case the QM negotiation is effectively acting as a heartbeat. A REALLY EXPENSIVE heartbeat! Bill: > If we have the system sign a "birth certificate" when it reboots > (including a reboot time or boot sequence number), we could include > that with a "bad spi" ICMP error and in the negotiation of the IKE SA. That is not a bad idea at all. Again, it only solves one problem -- the rebooting problem -- but it solves it well. This could be be used in conjunction with other techniques as part of a comprehensive solution. Steve: > If you really need to know if an SA is dead, use a layered solution. > The IPsec endpoint can periodically send a protected ICMP ECHO to the > far end. If it is acknowledged, all is well. More generally, *any* > traffic received can reset the timer. If m pings in a row are lost, > throw away the SA and let any new traffic from your side create a new > one. The far side can run the same protocol; if your side > discards its > half of the SA, the far side won't receive any response to its pings, > so it will tear down its side as well. This is just a different heartbeat mechanism which uses phase 2 instead of phase 1. The reason we didn't go this way is that there is no standardized mechanism for sending management traffic across a phase 2 SA. If there was such a standard (e.g. all traffic between the public IPs of the gateways is managment traffic; the normal filtering rules do not apply; icmp echo replies MUST be enabled; byte counts for accounting should not be updated; idle timeouts should not be circumvented, etc.) then we probably would have come out with an IPsec heartbeat draft instead of an Isakmp one. But as you can see, the very mention of adding special rules to IPsec SAs invokes the ire of many people in this WG, which is why we decided to take what we thought was the easier approach. Bill: > > I would hope the original is destroyed. This really shouldn't be > > any different than a new phase 1/2 SA negotiation sequence with a > > peer which didn't receive the SA delete messages. > > Well, certainly you should send using the newest SA which matches your > policy. with respect to reception, at a minimum, I would hope that > there's a grace period there around rekey time to accept packets sent > to the old SA which were delayed in transit. > > I don't see the harm in letting the SA's live until they expire unless > a DELETE or INITIAL-CONTACT or other affirmative indication that > they're gone on the other end comes in.. The harm is that you are now consuming memory for an SA that is not being used. While this may not seem like a huge problem (memory is cheap, yadayadayada), it is a problem if an adversary can coax you into negotiating multiple redundant SAs. Angelos: > From my experience, a number of commercial firewalls with > IPsec support make > that assumption implicitly (that an SA negotiated for traffic > between two > nets can also be used for traffic between the two gateways). Maybe that should be allowed, but if so then it should be documented. I don't think this is implicitly allowed by the spec; IMHO you shouldn't do anything controversial like this without enabling it via negotiation. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Fri Aug 11 19:34:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25749; Fri, 11 Aug 2000 19:34:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21751 Fri, 11 Aug 2000 21:41:34 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'IP Security List'" Subject: RE: Heartbeats Straw Poll (part 1) Date: Fri, 11 Aug 2000 21:44:57 -0400 Message-Id: <000101c003fe$ec5f29d0$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, My apologies for starting this thread and then not participating in the discussion, but I've been having mail server problems all week and I've only just fixed the problem now. And since this thread has generated over 2^6 replies ;-) , I'm going to batch up all my responses into a couple of messages. Part 1: outline of the problem Part 2: alternate proposals Part 3: conclusions Henry: > Speaking as a free-software developer (technical lead of > FreeS/WAN), our > current analysis says that an IKE-level heartbeat is > necessary and important. I was going by what Hugh Daniel said at the meeting. You don't appear to have an internal consensus on the issue. Paul: > When the group was asked "how many people understand this proposal", > I saw lots of people who I would have hoped would have raised their > hands not doing so (and not voting in the next two questions, > thankfully). I was a bit surprised at this as well. Certainly, I did not try to explain the proposal from scratch at the meeting; I only went over a few points of interest. However, I thought more people had read and understood the drafts and subsequent discussions on the list. Andrew (me): > To those who voted against the idea of a keep-alive protocol, > how do you > propose that we ensure high availablilty IPsec for our > customers who demand > it? Bill: > As several people brought up in the meeting, "keepalives" under the > wrong circumstances tend to turn into "make-deads". IKE and IPSEC > implementations should not delete SA's prior to their normal > expiration merely because they haven't heard from the other end in a > while. There's certainly a case for and against keep-alives, which is why I phrased the question that way. We have a specific problem to solve, which is ensuring that IPsec hosts can recover from black holes in a secure and timely manner. If there is a better solution which meets these requirements, I'm open to standardizing that. Bill: > There appear to be two different properties people are looking for > from heartbeats/keepalives: > > First, rapid recovery from loss of state on one end of a security > association (due to power loss/reboot/reset), so a new IKE SA can be > initiated on one end or the other. Once this happens, the half-dead > state on one end can be garbage collected as a result of an > affirmative indication (IKE INITIAL-CONTACT) that the other side lost > state. > > Second, detection of loss of connectivity between two security > gateways so that traffic can be rerouted through an alternate gateway. > This is really a dynamic routing problem and could (and probably > should) be done without prematurely tearing down IKE SA's and IPSEC > SA's which may still exist and may still be useful once the > connectivity comes back. As far as I'm concerned, the real problem is correcting the black hole. Other people mentioned other requirements, so we tried to accomodate those as well. Why not... after all, as in any 12 step recovery program, the first step is admitting you have a problem. Once you detect the problem, you can take whatever other corrective action you want (stop accounting, return dhcp address to pool, throw your arms up in despair, etc.) If we can distinguish between the two cases you mentioned in a sensible manner (e.g. by also sending clear pings to the public IP) then that would be a good idea as well. BTW, I think it's also important to include the problem of loss of synchronization due to lost deletes. Note that this problem is compounded due to case 2 above. If deletes get sent during the temporary connection loss then there is the problem of resynchronizing the phase 1 & 2 SADBs when the connection comes back up. Paul: > Sounds like we might want a *short*, concise statement > of the problem to the list before the straw poll is taken next. Maybe > start with a neutral description of the problem, followed by two > paragraphs in favor and two opposed. I am proposing that we need to solve the problem of state desynchronization (due primarily to reboots, but also due to lost deletes) in a manner that can't be exploited by an adversary. Feature requirements: - The detection should occur within a predictable (and tweakable) time interval. - We don't want to defeat idle timers, thus forcing SAs up indefinitely (and rekeying indefinitely). The vulnerability to exploitation should be limited as follows: An unprivileged adversary: - should not be able to spoof that the connection is still up. - should not be able to take the connection down. - should not be able to force a greater than O(n) response to spoofed packets. - and the coefficient of the O(n) response should be reasonable. An intermediate router: - should not be able to spoof that the connection is still up. - should be able to take the connection down (because you can't prevent that). - but the effects of this attack should be rate-limited. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Fri Aug 11 19:36:01 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA25936; Fri, 11 Aug 2000 19:36:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21739 Fri, 11 Aug 2000 21:39:17 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Tero Kivinen'" , Subject: RE: Heartbeats Straw Poll Date: Fri, 11 Aug 2000 21:42:30 -0400 Message-Id: <000001c003fe$95023420$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200008091317.QAA19824@torni.hel.fi.ssh.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes. All good points, Tero. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Tero Kivinen > Sent: Wednesday, August 09, 2000 9:17 AM > To: Theodore Ts'o > Cc: ebooth@cisco.com; smb@research.att.com; sommerfeld@East.Sun.COM; > sfanning@cisco.com; warlord@mit.edu; skelly@redcreek.com; > paul.hoffman@vpnc.org; ipsec@lists.tislabs.com > Subject: Re: Heartbeats Straw Poll > > > Theodore Ts'o writes: > > Neither of these (accounting and returning IP addresses to > a DHCP pool) > > are IPSEC issues. This is stuff you have to deal with even > if you're > > not using IPSEC. Hence, solving it with an IPSEC-specific solution > > seems like we're barking up the wrong tree. > > Most of the NAT traversal proposal that encapsulate IPsec inside UDP > packets needs some kind of keepalive protocol to keep the NAT from > deleting the UDP "connection". > > In that cases it doesn't matter if it is phase 1 or phase 2 "ping". > > Also a comment for those who complain about keepalives being > make-deads, that is NOT TRUE for the ipsec traffic. Your TCP/IP > session is not dead even if the IPsec SA is removed. The SA will be > recreated immediately when you send your next packet to that > connection. On the other hand if you do not detect black holes then > your TCP/IP session will be dead, because it will be sending packets > to deleted SA and the other end will just ignore them. After a TCP/IP > timeouts the connection is dropped. > > I think the heart beats are needed to get information when to start > renegotiating the SAs with the other end and when to use existing > ones. And I would really like to get that information on as soon as > possible. > > It does not mean that when the hearbeat stop coming in, I immedately > have to delete all SAs with that host. It means that I will mark that > SA as uncertain state, and if I run out of resources I will delete > that SA. > > If there was only temporary network connectivity loss I will starts > seeing the heart beats again later, so I can move the SA back to > active SAs list. > > Also if there is traffic coming to the SA that is in uncertain state, > I will first try to create new SA for that, just in case the other end > was really rebooted. If the other end was rebooted, it will send me > INITIAL-CONTACT notification so I know that I can remove the old SA. > If it wasn't rebooted, but there was temporary network problem that > happened to get fixed just in time to get the SA renegotiated, but > before the other ends heart beats start coming in, then I now have two > valid SAs with the other end and I can delete one of them to save > resources, or I can just leave them there. > > It is very annoying to know that remote gw was rebooted and your local > gw still thinks that it has SAs with the remote gw and sends stuff to > black hole. There are currently three easy ways to recover from the > problem: > > 1) Reboot the local gw (== remove all SAs) (I think this is > the option that will be selected by most of the people, it > is easy, fast and after that everything works fine for > them. Of course if you had multiple VPN connections the > rest of the connections are now in the same situation, the > remote gw was rebooted, and if you are not sending data to > them, they have to do same thing :-) > 2) Manually delete all SAs from the local gw to the remote gw > 3) Call somebody in the remote office and ask them to send > some packet to you so that when the remote gw starts > negotiation with our local gw, it will include > INITIAL-CONTACT notification, which will then clear out > SAs in your local gw. > > Most of the products have some kind of crash-recovery algorithm, that > will do some heuristic stuff based on the unknown SPIs etc to get over > this problem. That code is quite complicated and usually they don't > work that well... > > How often have you heard this in the IPsec interop meetings: "Lets > clear all SAs and try again, I think there was some old SAs left from > the previous test still laying around...". > > So, I think we do need some kind of black hole detection, and probably > also need some kind of keep alive for the NAT traversal case. > > Heartbeat in phase 1 is fine for both cases. Pings in phase 2 are fine > also, but not that simple, as people are trying to claim (also we > don't want one ping per SA we need one ping per GW/HOST pair, there > might be thousands of SAs between two machines). Birthday certificate > with INVALID-SPI notification would be excellent for the black hole > detection, but we still propably need something else for the NAT > traversal case. > -- > 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 Fri Aug 11 19:54:30 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA27824; Fri, 11 Aug 2000 19:54:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21781 Fri, 11 Aug 2000 21:48:56 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: Subject: RE: Heartbeats Straw Poll (part 3) Date: Fri, 11 Aug 2000 21:52:26 -0400 Message-Id: <000301c003ff$f8090b60$d23e788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200008091317.QAA19824@torni.hel.fi.ssh.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Part 3: conclusions I might ask where some of these comments were during the last two discussions on this topic, but it goes to show what I've said before, which is that you can't always get people to do a good requirements analysis until you propose something specific. The Isakmp Heartbeat Protocol provides a comprehensive solution to the problem I'm as I've described it (see message "RE: Heartbeats Straw Poll (part 1)"). By themselves, none of the alternate suggestions I've seen here provide a comprehensive solution. Could we in fact construct a different comprehensive solution from the ideas we've been discussing, without requiring regular heartbeats. Yes, I think so: - Require continuous channel mode. - Require that deletes are sent using the acknowledged informational exchange. - In the absence of traffic, send regular clear pings to test the availability of the route. - If the route goes down, keep the SAs up for 'awhile'. If the route comes back up before you delete the phase 1, use a phase 1 ping (with a few retries) to see if the peer is still there. If that succeeds, then send a SPI list to resynchronize the phase 2s. - Use a birth certificate to recover from atomic failures. - Require that redundant clusters share key material *OR* at the very least share SPIs and cookies so these can't be spoofed after a failure. This is a comprehensive solution to the problem I've described. I don't think this solution will have the same predictable-recovery properties of the Isakmp Heartbeat protocol, but it's not bad. Of course it requires changes to IKE, but these changes fall within the spirit of making IKE simpler. Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Tue Aug 15 11:21:58 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10254; Tue, 15 Aug 2000 11:21:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02434 Tue, 15 Aug 2000 12:36:22 -0400 (EDT) Message-ID: <399965F9.229804BC@redcreek.com> Date: Tue, 15 Aug 2000 09:47:05 -0600 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Heartbeats Straw Poll References: <3.0.32.20000810114450.00bfe680@zbl6c000.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Shawn Mamros wrote: > > >IMHO, a heartbeat protocol should run over a dedicated transport mode > >Phase 2 SA whose selector is specific to the heartbeat mechanism. I > >would allocate a new UDP port number specifically for the heartbeat > >mechanism just so it can distinguished from all other user data. An > >IPSEC peer that wants keepalives just has to create this SA using a > >standard quick mode exchange. A peer that _doesn't_ want to accept > >the heart-beat protocol can deny the quick mode request via its SPD. > > Why reinvent the wheel? We have a protocol that already does this: > ICMP. > > IPsec transport mode SA, negotiated specifically for ICMP, between > the two endpoint addresses. No changes to IKE necessary, just a > matter of policy on both sides. Don't want heartbeats? Don't set > up the SA. > > Either side can initiate a ping anytime they want. No need to > negotiate intervals, or retry counts, or any of that. Each side > decides their own policy in this regard. If the other side doesn't > answer, delete the SA and any other SAs considered to be related. > > Since it's a separate SA, those who don't want to add the ping > packets to their accounting records can choose not to do so. > > Rekey interval for the ICMP SA can be set as appropriate, if one > wants to check on the health of the IKE SA on the other side. > > Simple. Clean. Effective. Not covered by any patents I know of. > Works. Right? > > -Shawn Mamros > E-mail to: smamros@nortelnetworks.com Howdy, This was my favorite idea (out-of-band-pahse2) for a while too. But the downside is this: A gateway doing keepalives with large numbers of clients will basically be handeling twice the number of SAs it would have otherwise. By doing keepalives in phase 1, you are utalizing an existing secure channel. The worst part about using phase 1 seems to be that it flys in the face of the goal of simplifying IKE. However, keep in mind that keep alive parameters in phase 1 could be configured, they do not HAVE to be negotiated. By defining a new notify message and a few number of config parameters (on/off, frequency) phase 1 keepalives could be done very simply. The concept of carrying a notify message is not new. The other possible mechanism is doing keepalives in phase 2 inband (inside of the established SA). This requires creating specialize packets which will fit within the confines of the policy of the SA,and the ability to recognize these special packets at the recieving end. This approach does seem overly complex to me. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Wed Aug 16 05:16:11 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA15735; Wed, 16 Aug 2000 05:16:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA05105 Wed, 16 Aug 2000 06:39:47 -0400 (EDT) Message-Id: <200008161049.GAA21536@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-gkmframework-03.txt Date: Wed, 16 Aug 2000 06:49:34 -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 Framework for Group Key Management for Multicast Security Author(s) : T. Hardjono, B. Cain, N. Doraswamy Filename : draft-ietf-ipsec-gkmframework-03.txt Pages : 23 Date : 15-Aug-00 This document provides a framework for group key management for multicast security, motivated by three main considerations, namely the multicast application, scalability and trust-relationships among entities. It introduces two planes corresponding to the network entities and functions important to multicasting and to security. The key management plane consists of two hierarchy-levels in the form of a single 'trunk region' (inter-region) and one or more 'leaf regions' (intra-region). The advantages of the framework among others are that it is scalable, it has reduced complexity and allows the independence in regions of group key management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-gkmframework-03.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-gkmframework-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-gkmframework-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000815100256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-gkmframework-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-gkmframework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000815100256.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Aug 16 06:20:42 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18811; Wed, 16 Aug 2000 06:20:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05395 Wed, 16 Aug 2000 08:07:12 -0400 (EDT) Message-Id: <200008161049.GAA21536@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-gkmframework-03.txt Date: Wed, 16 Aug 2000 06:49:34 -0400 X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2 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 Framework for Group Key Management for Multicast Security Author(s) : T. Hardjono, B. Cain, N. Doraswamy Filename : draft-ietf-ipsec-gkmframework-03.txt Pages : 23 Date : 15-Aug-00 This document provides a framework for group key management for multicast security, motivated by three main considerations, namely the multicast application, scalability and trust-relationships among entities. It introduces two planes corresponding to the network entities and functions important to multicasting and to security. The key management plane consists of two hierarchy-levels in the form of a single 'trunk region' (inter-region) and one or more 'leaf regions' (intra-region). The advantages of the framework among others are that it is scalable, it has reduced complexity and allows the independence in regions of group key management. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-gkmframework-03.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-gkmframework-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-gkmframework-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000815100256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-gkmframework-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-gkmframework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000815100256.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Aug 16 12:54:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14036; Wed, 16 Aug 2000 12:54:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06461 Wed, 16 Aug 2000 13:28:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Wed, 16 Aug 2000 10:38:16 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Minutes from Pittsburgh? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Who took minutes for the IPsec WG at the Pittsburgh meeting? It would be useful to have them posted so the folks who were not there know what kind of fun they missed. FWIW, the minutes from the Adelaide meeting never got posted, and there were some very interesting discussions about IKE there as well. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Aug 16 13:23:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14432; Wed, 16 Aug 2000 13:23:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06779 Wed, 16 Aug 2000 14:52:55 -0400 (EDT) Date: Wed, 16 Aug 2000 15:01:34 -0400 From: "Theodore Ts'o" Message-Id: <200008161901.PAA02706@trampoline.thunk.org> To: paul.hoffman@vpnc.org CC: ipsec@lists.tislabs.com In-reply-to: (message from Paul Hoffman / VPNC on Wed, 16 Aug 2000 10:38:16 -0700) Subject: Re: Minutes from Pittsburgh? Phone: (781) 391-3464 References: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Date: Wed, 16 Aug 2000 10:38:16 -0700 From: Paul Hoffman / VPNC Who took minutes for the IPsec WG at the Pittsburgh meeting? It would be useful to have them posted so the folks who were not there know what kind of fun they missed. I took the minutes for the Pittsbugh meeting. I'm currently on the road, but I'll try to get them done within the next few days. I'm not sure what the situation is over the Adelaide meeting minutes; I'll look into that. - Ted From owner-ipsec@lists.tislabs.com Thu Aug 17 12:08:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29433; Thu, 17 Aug 2000 12:08:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10719 Thu, 17 Aug 2000 13:14:40 -0400 (EDT) Message-Id: <01C0089E.09C786E0.sridharj@future.futsoft.com> From: Sridhar J Reply-To: "sridharj@future.futsoft.com" To: "Ipsec (E-mail)" Subject: IKE proposal formation Date: Thu, 17 Aug 2000 22:54:01 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Subject ; IKE proposal formation As we all know that in IKE phase II if two proposals have same number then both proposals have to be selected . Suppose in a implementation IPSEC wants AH-MD5 and ESP-DES SA to be negotiated using IKE . The problem I am facing now is how to form an SADB_AQUIRE ( PF_KEY )message indicating IKE that AH-MD5 and ESP-DES have to be put in the same SA payload And both proposals should have same number Thanks in Advance From owner-ipsec@lists.tislabs.com Thu Aug 17 14:25:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02367; Thu, 17 Aug 2000 14:25:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11213 Thu, 17 Aug 2000 16:12:32 -0400 (EDT) Message-ID: <000601c00888$d8ad89c0$8a1b6e0a@jariws1.arenanet.fi> From: "Jari Arkko" To: , "Ipsec (E-mail)" Subject: Re: IKE proposal formation Date: Thu, 17 Aug 2000 23:22:20 +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 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Suppose in a implementation IPSEC wants AH-MD5 and ESP-DES SA to >be negotiated using IKE . >The problem I am facing now is how to form an SADB_AQUIRE ( PF_KEY )message >indicating IKE that AH-MD5 and ESP-DES have to be put in the same SA payload >And both proposals should have same number You can't. PF_KEY does not support bundles. Oh, there's been discussion about fixing that on the PF_KEY list but right now it does not exist. For one of the ideas on how to do it, see http://search.ietf.org/internet-drafts/draft-arkko-pfkey-reference-00.txt. Other ideas have been discussed on the list, too. Jari From owner-ipsec@lists.tislabs.com Fri Aug 18 01:49:32 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA11423; Fri, 18 Aug 2000 01:49:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA12484 Fri, 18 Aug 2000 03:00:12 -0400 (EDT) From: "Markku Savela" To: Subject: RE: IKE proposal formation Date: Fri, 18 Aug 2000 10:10:03 +0300 Message-ID: <000001c008e3$559a0710$e82815ac@hews0169nrc.research.nokia.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.2377.0 Importance: Normal In-Reply-To: <000601c00888$d8ad89c0$8a1b6e0a@jariws1.arenanet.fi> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > You can't. PF_KEY does not support bundles. Oh, there's been > discussion about > fixing that on the PF_KEY list but right now it does not > exist. For one of the ideas on > how to do it, see Also, I wish to point out (again) that IPSEC (as per RFC-2401) works 100% fine without any support for bundles from the the key management. The need to add "bundles" into PFKEY is a pure IKE artifact, not required by the IPSEC itself. (As I have tried to say several times on this mailing list, key management should just negotiate keys, it does not need to concern itself with the policy and bundles at all). From owner-ipsec@lists.tislabs.com Fri Aug 18 08:15:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09922; Fri, 18 Aug 2000 08:15:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13673 Fri, 18 Aug 2000 09:27:13 -0400 (EDT) Message-Id: <01C00947.6A24D2A0.sridharj@future.futsoft.com> From: Sridhar J Reply-To: "sridharj@future.futsoft.com" To: "'Markku Savela'" , "ipsec@lists.tislabs.com" Subject: RE: IKE proposal formation Date: Fri, 18 Aug 2000 19:06:26 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk No sir Key Management ( IKE ) has to concern with SA bundles because IKE has to set the proposal number accordingly .Hope you agree the function of proposal number as stated in ISAKMP 2408.By the way what is mailing list for PF_KEY :Markku.Savela@research.nokia.com] wrote : > You can't. PF_KEY does not support bundles. Oh, there's been > discussion about > fixing that on the PF_KEY list but right now it does not > exist. For one of the ideas on > how to do it, see Also, I wish to point out (again) that IPSEC (as per RFC-2401) works 100% fine without any support for bundles from the the key management. The need to add "bundles" into PFKEY is a pure IKE artifact, not required by the IPSEC itself. (As I have tried to say several times on this mailing list, key management should just negotiate keys, it does not need to concern itself with the policy and bundles at all). From owner-ipsec@lists.tislabs.com Fri Aug 18 11:32:40 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA26388; Fri, 18 Aug 2000 11:32:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA14305 Fri, 18 Aug 2000 13:05:24 -0400 (EDT) Message-ID: <005701c00937$cdb33920$8a1b6e0a@jariws1.arenanet.fi> From: "Jari Arkko" To: Cc: , Subject: Re: IKE proposal formation Date: Fri, 18 Aug 2000 20:14:43 +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 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sridhar wrote: >By the way what is mailing list for PF_KEY RFC 2367 says: >This specification and implementations of it are discussed on the PF_KEY >mailing list. If you would like to be added to this list, send a note >to . Jari From owner-ipsec@lists.tislabs.com Mon Aug 21 05:54:48 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07174; Mon, 21 Aug 2000 05:54:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA21008 Mon, 21 Aug 2000 06:53:08 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E37749@eseis06nok> To: ipsec@lists.tislabs.com Subject: Mobile IKE/IPSEC Date: Mon, 21 Aug 2000 14:02:39 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is there any draft/RFC discussing possiblilities to use IPSEC/IKE for devices with dinamic addresses (eg: Dial-up)? The problem arises because a device with a variable address that wants to acces a intranet through a SG. How can I configure the SG IPSEC/IKE for this situation? The idea would be use in some way the ID used in IKE to transmit some kind of info to do that. Is there any IKE mode which fit best to this case? dial-up device - DD Security gateway - SG Intennal host n - Hn DD ========== SG ------------ H1 H2 ... Hn Sorry if the subject has been discussed before (Just give a pointer to some releveant message if that's the case) Toni From owner-ipsec@lists.tislabs.com Mon Aug 21 08:04:26 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10399; Mon, 21 Aug 2000 08:04:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA21527 Mon, 21 Aug 2000 09:33:45 -0400 (EDT) Message-ID: <7BAE92530D4BD3118A3600508B1224D0FB08D3@ISIS2> From: "Lewis, Rafe" To: "'Tamir Zegman'" , "Theodore Y. Ts'o" , "Steven M. Bellovin" Cc: "Walker, Jesse" , ipsec@lists.tislabs.com Subject: RE: IV sizes for AES candidates Date: Mon, 21 Aug 2000 09:43:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk please forward instructions on how to be removed from this mailing list group. Thanks, RL > -----Original Message----- > From: Tamir Zegman [SMTP:zegman@checkpoint.com] > Sent: Friday, August 11, 2000 1:31 PM > To: Theodore Y. Ts'o; Steven M. Bellovin > Cc: Walker, Jesse; ipsec@lists.tislabs.com > Subject: Re: IV sizes for AES candidates > > No, the low Hamming distance attack would not work here. > The attack goes as follows: > Denote a XOR operation by '+' > Assume you have 2 messages that differ only on one bit - M and M+1. > If you choose their two respective IV's as X and X+1 (that is X and X+1 > differ only on the same bit as M and M+1), the two cleartexts will encrypt > to the same cipher text. > C1 = AES(M+X) > C2 = AES(M+1+X+1) = AES(M+X) = C1 > > In counter mode, if you have two counters with a low Hamming distance > you'll > get: > C1 = AES(X) + M > C2 = AES(X+1) + M + 1 > Since chances are that E(X) and E(X+1) have a high Hamming distance this > attack does not work in counter mode. > > > ----- Original Message ----- > From: Theodore Y. Ts'o > To: Steven M. Bellovin > Cc: Walker, Jesse ; > Sent: Friday, August 11, 2000 6:41 AM > Subject: Re: IV sizes for AES candidates > > > > From: "Steven M. Bellovin" > > Date: Thu, 10 Aug 2000 14:29:13 -0400 > > > > In message > <392A357CE6FFD111AC3E00A0C99848B002FE990F@hdsmsx31.hd.intel.com>, "W > > alker, Jesse" writes: > > >I share Helger's desire to at least consider counter mode for AES. > Counter > > >mode is an opportunity to gain better data privacy than CBC mode > offers and > > >perhaps better performance as well. The WG can fall back to CBC mode > if > > >scrutiny reveals counter mode is somehow inapplicable within ESP. > > > > Counter mode appears to be one instance of a "seekable stream > cipher", > > per draft-mcgrew-ipsec-scesp-00.txt. As was discussed in Pittsburgh, > > there are a number of limitations, including the very strong > > requirement for authentication and the need for a flat-out ban on > using > > it with manual keying -- if you don't use IKE, there's just too much > > risk of seeing two streams encrypted with the same key and counter. > > > > When we talked how IV's for CBC mode, we were told that using a counter > > for the IV was a bad idea, because if the first eight bytes were known > > and fixed (as they commonly were), you could end up with known > > plaintext/ciphertext pairs that were a low hamming distance apart, and > > this could be used as a wedge to attack a cipher. > > > > If you use counter mode, doesn't this guarantee that in the face of > > known plaintext, you'll have a *lot* of known plaintext/cipgertext that > > have a low haming distance, and so would be subject to the same attacks > > as mentioned in the previous paragraph, right? > > > > So wouldn't the argument that says that we shouldn't use a counter to > > generate IV's also mean that using counter mode would also be a bad > > idea? (This is in addition to all of the issues of an absolute > > requirement for using a MAC if you care about message integrity at > > all, and the dangers of resusing a keystream if you're not careful.) > > > > - Ted > > > > From owner-ipsec@lists.tislabs.com Mon Aug 21 13:53:43 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23332; Mon, 21 Aug 2000 13:53:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA22748 Mon, 21 Aug 2000 15:00:10 -0400 (EDT) Message-Id: <3.0.5.32.20000821193404.00bbf8a0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 21 Aug 2000 19:34:04 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Mobile IKE/IPSEC In-Reply-To: <0B3F42CA1FB6D2118FE50008C7894B0A02E37749@eseis06nok> 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 NAA22393 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 14:02 21.8.2000 +0300, you wrote: > Is there any draft/RFC discussing possiblilities to use IPSEC/IKE >for devices with dinamic addresses (eg: Dial-up)? >The problem arises because a device with a variable address that wants to >acces a intranet through a SG. How can I configure the SG IPSEC/IKE for this >situation? > The idea would be use in some way the ID used in IKE to transmit >some kind of info to do that. > Is there any IKE mode which fit best to this case? > > dial-up device - DD > Security gateway - SG > Intennal host n - Hn > > DD ========== SG ------------ H1 > H2 > ... > Hn > > Sorry if the subject has been discussed before (Just give a pointer >to some releveant message if that's the case) > >Toni > First of all, this might be helpful: >typedef enum { > /* IPSEC_ID_RESERVED = 0, */ > IPSEC_ID_IPV4_ADDR = 1, > IPSEC_ID_FQDN = 2, > IPSEC_ID_USER_FQDN = 3, > IPSEC_ID_IPV4_ADDR_SUBNET = 4, > IPSEC_ID_IPV6_ADDR = 5, > IPSEC_ID_IPV6_ADDR_SUBNET = 6, > IPSEC_ID_IPV4_ADDR_RANGE = 7, > IPSEC_ID_IPV6_ADDR_RANGE = 8, > IPSEC_ID_DER_ASN1_DN = 9, > IPSEC_ID_DER_ASN1_GN = 10, > IPSEC_ID_KEY_ID = 11 >} IkeIpsecIdentificationType; > >PHASE 1 using preshared keys >============================ > >The ID types IPV4_ADDR, IPV6_ADDR, FQDN, USER_FQDN and KEY_ID are >recommended in a phase 1 exchange using preshared keys. >In agressive mode, the values can be used for an immediate >policy lookup. In main mode, the responder >must retrieve the secret from the spd before it receives the ID, thus >only IPV4_ADDR is useful in main mode. > >Is the responder has a "group" policy to allow several hosts >with volatile IP addresses to connect, the use of aggressive mode >and ID types USER_FQDN and KEY_ID is recommended. > >DER_ASN1_DN and DER_ASN1_GN are meaningful IDs as well, if an >implementation chooses to store policy data indexed by these IDs. > >Address ranges and subnets are not allowed in Phase 1. > >An IKE implementation MUST at least implement IPV4_ADDR. >However, USER_FQDN is a very useful ID because end users >are able to understand and remember them. > >PHASE 1 using pk signatures >=========================== > >The ID types IPV4_ADDR, IPV6_ADDR, FQDN, USER_FQDN and DER_ASN1_DN are >recommended in a phase 1 exchange using signatures. >In agressive mode, the values can be used for an immediate policy lookup. >In main mode, only the initiator's IP address is available for the >initial policy lookup of the responder. Therefore, the policy must >contain (IP address, ID) or (IP address range, ID range) pairs. >After receiving the 5th packet of MM, the responder has to do >a second policy check. >The responder must reject a MM where the IDV4_ADDR ID and the >IP address does not match. > >Is the responder has a "group" policy to allow several hosts >with volatile IP addresses to connect, the use of aggressive mode >and ID types USER_FQDN and DER_ASN1_DN is recommended. >It should be noted that these IDs, especially DER_ASN1_DN may >contain valuable information which is not suitable to be transmitted >in cleartext. In this case, I recommend public key encrytion. The >alternative is having one policy entry (0.0.0.0/0, (list of all IDs)). > >The ID must show up in the certificate! E.g., if the ID is USER_FQDN, >the subjectAltName must contain an email address. > >DER_ASN1_GN is may be used as an alternative to IPV4_ADDR, IPV6_ADDR, FQDN >and USER_FQDN. >The subjectAltNames in certificates are encoded as general names, so >DER_ASN1_GN is a generic pointer to a subjectAltName. >One could even argue that USER_FQDN is not a valid ID and that email addresses >must be encoded using DER_ASN1_GN. I don't think so. > >Address ranges and subnets are not allowed in Phase 1. >IPSEC_ID_KEY_ID is not useful. > >An IKE implementation MUST at least implement IPV4_ADDR and DER_ASN1_DN. > >PHASE 1 using pk encryption >=========================== > >Same as signatures, but the ID is safe in agressive mode. > >Quick Mode >========== > >QM IDs act as selectors for packets. src and dst addresses of IP packets >transmitted through the SA must match the negotiated IDs. >While it is possible to not send IDs in QM, it is not recommended. > >IPV4_ADDR, IPV4_ADDR_SUBNET, IPV4_ADDR_RANGE, IPV6_ADDR, IPV6_ADDR_SUBNET, >IPV6_ADDR_RANGE >may be used in QM. IPv4 and IPv6 may not be mixed. ADDR, RANGE and SUBNET >may be mixed. > Well, it seems that there is no "perfect" solution. Don't use pre-shared keys, they're crap. Some people just go with Main Mode, with DER_ASN1_DN as IKE ID. Other people use Aggressive Mode, with IPSEC_ID_USER_FQDN. Then there are the people who go "Use the latest draft!". Have a nice day. J–rn From owner-ipsec@lists.tislabs.com Tue Aug 22 05:33:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17945; Tue, 22 Aug 2000 05:33:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25717 Tue, 22 Aug 2000 06:57:59 -0400 (EDT) Message-Id: <200008221108.HAA00941@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-lordello-ipsec-vpn-doi-00.txt Date: Tue, 22 Aug 2000 07:08:16 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : VPN-ID-Enhanced IPSec-VPN DOI for ISAKMP Author(s) : C. Lordello, U. Neustadter Filename : draft-lordello-ipsec-vpn-doi-00.txt Pages : 15 Date : 21-Aug-00 The IPSec DOI for ISAKMP defines identities for phase 2 exchanges that are suitable for a flat, unique address space. On the other hand, different VPN's cannot guarantee a non-overlapping address space among them. Therefore when security gateways on an ISP network negotiate IPSec SA's in the context of multiple VPN's, identifying traffic flows for this multiplicity of VPN's become an issue. Of course, an alternative would be to have multiple contexts of security gateways, one for each VPN. Unfortunately that would impose severe administrative challenges to an ISP, some of which are described later. Another alternative and a more appealing one would be to have a single security gateway with a single tunnel endpoint address, a single X.509 certificate, etc., that exists in a common context and is able to negotiate IPSec tunnels for any VPN with a presence in the security gateway. For the later to be possible however, it is required for this common security gateway to be able to negotiate phase 2 SA's on behalf of each one of these VPN's with overlapping address spaces. A second motivation for the later approach would be to simply negotiate IPSec tunnels for each VPN as a whole without implying any specific traffic flow. This specification describes an extended DOI for ISAKMP which, while inheriting the existing IPSec DOI in its entirety, defines extra types of phase 2 identities which include a VPN-ID field as an extra piece of tunnel identity, i.e., a qualifier for the IP addresses selectors. The VPN-ID is defined in RFC 2685. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lordello-ipsec-vpn-doi-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-lordello-ipsec-vpn-doi-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-lordello-ipsec-vpn-doi-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: <20000821143524.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lordello-ipsec-vpn-doi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lordello-ipsec-vpn-doi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000821143524.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Aug 22 05:33:57 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17966; Tue, 22 Aug 2000 05:33:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA25707 Tue, 22 Aug 2000 06:57:21 -0400 (EDT) Message-Id: <200008221107.HAA00793@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipsec@lists.tislabs.com, smug@cs.umass.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-irtf-smug-taxonomy-01.txt Date: Tue, 22 Aug 2000 07:07:32 -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 taxonomy of multicast security issues Author(s) : R. Canetti, B. Pinkas Filename : draft-irtf-smug-taxonomy-01.txt Pages : 21 Date : 21-Aug-00 With the growth and commercialization of the Internet, the need for secure IP multicast is growing. In this draft we present a taxonomy of multicast security issues. We first sketch some multicast group parameters that are relevant to security, and outline the basic security issues concerning multicast in general, with emphasis on IP multicast. Next we suggest two 'benchmark' scenarios for secure multicast solutions. Lastly we review some previous works. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-smug-taxonomy-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-irtf-smug-taxonomy-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-irtf-smug-taxonomy-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: <20000821135321.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-irtf-smug-taxonomy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-irtf-smug-taxonomy-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000821135321.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Aug 22 07:43:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26154; Tue, 22 Aug 2000 07:43:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26490 Tue, 22 Aug 2000 09:20:36 -0400 (EDT) From: Gavin.Kerr@nl.abnamro.com X-Lotus-FromDomain: ABNAMRO To: ipsec@lists.tislabs.com Message-ID: Date: Tue, 22 Aug 2000 15:28:23 +0200 Subject: High Availability and IPSec Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Apologies if this is the wrong place to ask this... Does anyone know the action/impact of IPSec in a highly available environment. EG Scenario 1: Client (Win2K) connects to server (HP w/ ServiceGuard) using IPSec, network card in server fails, connections/IP Address get failed over to "backup" network card. Will the client cope with this? Or will something stop the connection from continuing? (Will it think it's someone trying to spoof the connection for example) Scenario 2: Client connects to server, server dies, packages (Including IP address) fail over to another machine... Pretty much the same questions. If there are problems, what is the best practice way to deal with them? I've looked pretty hard and can't find any information on this subject. If people can provide pointers that would be more than enough. Thanks in advance, Gav From owner-ipsec@lists.tislabs.com Tue Aug 22 07:44:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26177; Tue, 22 Aug 2000 07:44:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26578 Tue, 22 Aug 2000 09:30:32 -0400 (EDT) Message-ID: <53D69AD06EFAD311842300A0C99B4F08656558@ticsmtp2.innovation.siemens.ca> From: Claudio Lordello To: "'Markku Savela'" Cc: "'.IPSec-IETF'" , Claudio Lordello Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Date: Tue, 22 Aug 2000 09:35:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sorry for the earlier incomplete message. I must have hit some ctrl-whatever :-( Markku, Yes, the customer trusts the ISP the same way the customers today trust their FR, ATM link to their service provider. Well noted, the scenario described does not replace end-to-end security. However it does allow ISP's to provide not only leased-line replacement but also routing to their customers. Claudio. > -----Original Message----- > From: Markku Savela [SMTP:Markku.Savela@research.nokia.com] > Sent: Tuesday, August 22, 2000 8:24 AM > To: ipsec@lists.tislabs.com > Cc: claudio.lordello@innovation.siemens.ca > Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt > > > Title : VPN-ID-Enhanced IPSec-VPN DOI for ISAKMP > > Author(s) : C. Lordello, U. Neustadter > > Filename : draft-lordello-ipsec-vpn-doi-00.txt > > Just being in picky mood... > > The security considerations for this should probably include the obvious > note, that in this solution the customer implicitly trusts their ISP (ISP > can read and monitor everything in clear). So, I wonder what type of > "customer" actually would need this thing? From owner-ipsec@lists.tislabs.com Tue Aug 22 07:48:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26397; Tue, 22 Aug 2000 07:48:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA26512 Tue, 22 Aug 2000 09:24:30 -0400 (EDT) Message-ID: <53D69AD06EFAD311842300A0C99B4F08656557@ticsmtp2.innovation.siemens.ca> From: Claudio Lordello To: "'Markku Savela'" , ipsec@lists.tislabs.com Cc: Claudio Lordello Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Date: Tue, 22 Aug 2000 09:29:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, the customer trusts the ISP the same way the customers today trust their FR, ATM link to their service provider. Well noted, the > -----Original Message----- > From: Markku Savela [SMTP:Markku.Savela@research.nokia.com] > Sent: Tuesday, August 22, 2000 8:24 AM > To: ipsec@lists.tislabs.com > Cc: claudio.lordello@innovation.siemens.ca > Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt > > > Title : VPN-ID-Enhanced IPSec-VPN DOI for ISAKMP > > Author(s) : C. Lordello, U. Neustadter > > Filename : draft-lordello-ipsec-vpn-doi-00.txt > > Just being in picky mood... > > The security considerations for this should probably include the obvious > note, that in this solution the customer implicitly trusts their ISP (ISP > can read and monitor everything in clear). So, I wonder what type of > "customer" actually would need this thing? From owner-ipsec@lists.tislabs.com Tue Aug 22 07:48:22 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26442; Tue, 22 Aug 2000 07:48:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26115 Tue, 22 Aug 2000 08:14:03 -0400 (EDT) From: "Markku Savela" To: Cc: Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Date: Tue, 22 Aug 2000 15:24:13 +0300 Message-ID: <000101c00c33$e24f5810$e82815ac@hews0169nrc.research.nokia.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.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <200008221108.HAA00941@ietf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Title : VPN-ID-Enhanced IPSec-VPN DOI for ISAKMP > Author(s) : C. Lordello, U. Neustadter > Filename : draft-lordello-ipsec-vpn-doi-00.txt Just being in picky mood... The security considerations for this should probably include the obvious note, that in this solution the customer implicitly trusts their ISP (ISP can read and monitor everything in clear). So, I wonder what type of "customer" actually would need this thing? From owner-ipsec@lists.tislabs.com Tue Aug 22 08:23:14 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28429; Tue, 22 Aug 2000 08:23:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26898 Tue, 22 Aug 2000 10:02:05 -0400 (EDT) Message-Id: <3.0.5.32.20000822160614.033b5d80@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 22 Aug 2000 16:06:14 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: High Availability and IPSec 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 JAA26793 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 15:28 22.8.2000 +0200, you wrote: > > >Apologies if this is the wrong place to ask this... > >Does anyone know the action/impact of IPSec in a highly available environment. > >EG > >Scenario 1: Client (Win2K) connects to server (HP w/ ServiceGuard) using IPSec, >network card in > server fails, connections/IP Address get failed over to "backup" network >card. > >Will the client cope with this? Or will something stop the connection from >continuing? (Will it think it's >someone trying to spoof the connection for example) > There should not be any problem at the client side. It shouldn't even notice. I would expect such a fail-over system to deal with ARP problems. >Scenario 2: Client connects to server, server dies, packages (Including IP >address) fail over >to another machine... > >Pretty much the same questions. > Well that _is_ a problem. From the client side, it looks just like the server rebooted: The server forgot all IPsec SAs. ARP could also be a problem. If the client has a feature to detect dead tunnels, good. If it does not, the client can't reach the server for the remaining lifetime of the IPsec SA (phase 2). In this case, phase 2 lifetimes should be small. Like 5 minutes. J–rn From owner-ipsec@lists.tislabs.com Tue Aug 22 11:31:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10136; Tue, 22 Aug 2000 11:31:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27838 Tue, 22 Aug 2000 13:03:30 -0400 (EDT) X-Authentication-Warning: skinner.cs.mcgill.ca: boxer owned process doing -bs Date: Tue, 22 Aug 2000 13:13:34 -0400 (EDT) From: Carlton Roy DAVIS To: ipsec@lists.tislabs.com Subject: Difference between IPSec and SSH Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I Need some information about the difference between IPSec and SSH based VPN. Does anyone know of any good document source that you could point me to. My MSc. thesis was on IPSec VPN, so I am quite familar with IPSec. I don't know as much about SSH. Thanks in advance for any help and best regards. -Carlton __________________________________________________ Carlton Davis, E-mail: boxer@cs.mcgill.ca - Home page: http://www.cs.mcgill.ca/~boxer - School of Computer Science, McGill University - -------------------------------------------------- The heavens declare the glory of God; and the firmament sheweth His handywork. From owner-ipsec@lists.tislabs.com Tue Aug 22 14:37:55 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14388; Tue, 22 Aug 2000 14:37:55 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28565 Tue, 22 Aug 2000 16:22:54 -0400 (EDT) Message-ID: <39A2F16F.230A0AED@radguard.com> Date: Tue, 22 Aug 2000 23:32:31 +0200 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: antonio.barrera@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: Mobile IKE/IPSEC References: <0B3F42CA1FB6D2118FE50008C7894B0A02E37749@eseis06nok> Content-Type: multipart/mixed; boundary="------------8AF01BC72D7F5353E2A1DADA" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------8AF01BC72D7F5353E2A1DADA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is one of the problems discusses by the IPSRA wg http://www.ietf.org/html.charters/ipsra-charter.html Sara. antonio.barrera@nokia.com wrote: > Is there any draft/RFC discussing possiblilities to use IPSEC/IKE > for devices with dinamic addresses (eg: Dial-up)? > The problem arises because a device with a variable address that wants to > acces a intranet through a SG. How can I configure the SG IPSEC/IKE for this > situation? > The idea would be use in some way the ID used in IKE to transmit > some kind of info to do that. > Is there any IKE mode which fit best to this case? > > dial-up device - DD > Security gateway - SG > Intennal host n - Hn > > DD ========== SG ------------ H1 > H2 > ... > Hn > > Sorry if the subject has been discussed before (Just give a pointer > to some releveant message if that's the case) > > Toni --------------8AF01BC72D7F5353E2A1DADA Content-Type: text/x-vcard; charset=us-ascii; name="sarab.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Sara Bitan Content-Disposition: attachment; filename="sarab.vcf" begin:vcard n:Bitan;Sara tel;fax:+972-3-6480859 tel;work:+972-3-7658904 x-mozilla-html:TRUE url:www.radguard.com org:RADGUARD adr:;;;Tel-Aviv;;;ISRAEL version:2.1 email;internet:sarab@radguard.com title:V.P. of R&D fn:Sara Bitan end:vcard --------------8AF01BC72D7F5353E2A1DADA-- From owner-ipsec@lists.tislabs.com Thu Aug 24 14:26:50 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05868; Thu, 24 Aug 2000 14:23:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA07512 Thu, 24 Aug 2000 15:00:51 -0400 (EDT) Message-ID: <39A56CD9.4CD03781@ennovatenetworks.com> Date: Thu, 24 Aug 2000 14:43:37 -0400 From: Daniel Fox X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Claudio Lordello CC: "'Markku Savela'" , "'.IPSec-IETF'" , dfox@ennovatenetworks.com Subject: Re: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt References: <53D69AD06EFAD311842300A0C99B4F08656558@ticsmtp2.innovation.siemens.ca> Content-Type: multipart/mixed; boundary="------------DFC1EE4C2EE52EC0D6488319" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------DFC1EE4C2EE52EC0D6488319 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There are at least three products currently on the market that provide this solution, and more are on the way... Claudio Lordello wrote: > Sorry for the earlier incomplete message. I must have hit some ctrl-whatever > :-( > > Markku, > > Yes, the customer trusts the ISP the same way the customers today trust > their FR, ATM link to their service provider. > > Well noted, the scenario described does not replace end-to-end security. > However it does allow ISP's to provide not only leased-line replacement but > also routing to their customers. > > Claudio. > > > -----Original Message----- > > From: Markku Savela [SMTP:Markku.Savela@research.nokia.com] > > Sent: Tuesday, August 22, 2000 8:24 AM > > To: ipsec@lists.tislabs.com > > Cc: claudio.lordello@innovation.siemens.ca > > Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt > > > > > Title : VPN-ID-Enhanced IPSec-VPN DOI for ISAKMP > > > Author(s) : C. Lordello, U. Neustadter > > > Filename : draft-lordello-ipsec-vpn-doi-00.txt > > > > Just being in picky mood... > > > > The security considerations for this should probably include the obvious > > note, that in this solution the customer implicitly trusts their ISP (ISP > > can read and monitor everything in clear). So, I wonder what type of > > "customer" actually would need this thing? --------------DFC1EE4C2EE52EC0D6488319 Content-Type: text/x-vcard; charset=us-ascii; name="dfox.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Fox Content-Disposition: attachment; filename="dfox.vcf" begin:vcard n:Fox;Daniel tel;work:978-206-0405 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;60 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Principal Software Engineer fn:Daniel Fox end:vcard --------------DFC1EE4C2EE52EC0D6488319-- From owner-ipsec@lists.tislabs.com Thu Aug 24 18:37:06 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA13842; Thu, 24 Aug 2000 18:37:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA08399 Thu, 24 Aug 2000 19:40:12 -0400 (EDT) Message-ID: <53D69AD06EFAD311842300A0C99B4F0865655F@ticsmtp2.innovation.siemens.ca> From: Claudio Lordello To: "'Daniel Fox'" , Claudio Lordello Cc: "'Markku Savela'" , "'.IPSec-IETF'" Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Date: Thu, 24 Aug 2000 19:46:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am not sure how to interpret your comment: 1) there are products on the market and more coming so yes, customers do want this; -or- 2) there are products on the market and they must be solving this VPN identification issue some other way so let's not add any new idendities to the DOI. Perhaps you can clarify. Claudio. > -----Original Message----- > From: Daniel Fox [SMTP:dfox@ennovatenetworks.com] > Sent: Thursday, August 24, 2000 2:44 PM > To: Claudio Lordello > Cc: 'Markku Savela'; '.IPSec-IETF'; dfox@ennovatenetworks.com > Subject: Re: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt > > There are at least three products currently on the market that provide > this > solution, and more are on the way... > > Claudio Lordello wrote: > > > Sorry for the earlier incomplete message. I must have hit some > ctrl-whatever > > :-( > > > > Markku, > > > > Yes, the customer trusts the ISP the same way the customers today trust > > their FR, ATM link to their service provider. > > > > Well noted, the scenario described does not replace end-to-end security. > > However it does allow ISP's to provide not only leased-line replacement > but > > also routing to their customers. > > > > Claudio. > > > From owner-ipsec@lists.tislabs.com Fri Aug 25 09:58:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA21655; Fri, 25 Aug 2000 09:58:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18977 Fri, 25 Aug 2000 11:26:18 -0400 (EDT) Message-ID: <39A692D8.740B1F65@ennovatenetworks.com> Date: Fri, 25 Aug 2000 11:38:00 -0400 From: Daniel Fox X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Claudio Lordello CC: "'Markku Savela'" , "'.IPSec-IETF'" , dfox@ennovatenetworks.com Subject: Re: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt References: <53D69AD06EFAD311842300A0C99B4F0865655F@ticsmtp2.innovation.siemens.ca> Content-Type: multipart/mixed; boundary="------------5F13DDA96015145E3CD37BEB" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------5F13DDA96015145E3CD37BEB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The former, not the latter. Your intro does a great job of explaining how it might be solved without your proposed change, and I personally prefer your solution. Without your solution, we'll solve it by having a different cert for each VPN. But I'd rather do it with a new phase 2 ID and have just one cert to manage. -Dan Claudio Lordello wrote: > I am not sure how to interpret your comment: 1) there are products on the > market and more coming so yes, customers do want this; -or- 2) there are > products on the market and they must be solving this VPN identification > issue some other way so let's not add any new idendities to the DOI. > > Perhaps you can clarify. > > Claudio. > > > -----Original Message----- > > From: Daniel Fox [SMTP:dfox@ennovatenetworks.com] > > Sent: Thursday, August 24, 2000 2:44 PM > > To: Claudio Lordello > > Cc: 'Markku Savela'; '.IPSec-IETF'; dfox@ennovatenetworks.com > > Subject: Re: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt > > > > There are at least three products currently on the market that provide > > this > > solution, and more are on the way... > > > > Claudio Lordello wrote: > > > > > Sorry for the earlier incomplete message. I must have hit some > > ctrl-whatever > > > :-( > > > > > > Markku, > > > > > > Yes, the customer trusts the ISP the same way the customers today trust > > > their FR, ATM link to their service provider. > > > > > > Well noted, the scenario described does not replace end-to-end security. > > > However it does allow ISP's to provide not only leased-line replacement > > but > > > also routing to their customers. > > > > > > Claudio. > > > > > --------------5F13DDA96015145E3CD37BEB Content-Type: text/x-vcard; charset=us-ascii; name="dfox.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Daniel Fox Content-Disposition: attachment; filename="dfox.vcf" begin:vcard n:Fox;Daniel tel;work:978-206-0405 x-mozilla-html:FALSE url:http://www.ennovatenetworks.com org:Ennovate Networks adr:;;60 Codman Hill Road;Boxborough;MA;01719;USA version:2.1 email;internet:dfox@ennovatenetworks.com title:Principal Software Engineer fn:Daniel Fox end:vcard --------------5F13DDA96015145E3CD37BEB-- From owner-ipsec@lists.tislabs.com Tue Aug 29 17:18:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA28224; Tue, 29 Aug 2000 17:18:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA24225 Tue, 29 Aug 2000 18:45:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20000829154612.00d223c0@border.abrainc.com> X-Sender: jcday@garlic.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Aug 2000 15:55:47 -0700 To: ipsec@lists.tislabs.com From: "John C. Day" Subject: Looking for info on ipsec passthrough (or passthru?) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings. I'm poking around looking for information on "IPSec passthru", which I saw mentioned on http://www.linksys.com ("Firmware upgrade - IPSec passthru now supported"). I searched the archive files of ftp://ftp.tis.com/pub/lists/ipsec/ipsec.0001 through ipsec.0008 but I couldn't locate the string "passthr" anywhere in those. I also checked rfc2401 without success, but I'm guessing it's a feature/spec that's been introduced recently. Using google I did find a couple of mentions of it in news groups, but I wasn't able to locate an rfc or other doc which describes what it's for and how it's to be implemented. Any pointers? Thanks. John -- John C. Day Gilroy, CA http://www.JCDay.com From owner-ipsec@lists.tislabs.com Wed Aug 30 06:54:31 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26118; Wed, 30 Aug 2000 06:54:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA26657 Wed, 30 Aug 2000 08:11:56 -0400 (EDT) X-Originating-IP: [210.78.155.212] From: "Icegirl_69 Mini" To: ipsec@lists.tislabs.com Subject: Ask for Help Date: Wed, 30 Aug 2000 16:28:10 CST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Aug 2000 08:28:10.0734 (UTC) FILETIME=[3B4988E0:01C0125C] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I know that some people are studying various kinds of Crypto-APIs one can use to invoke cryptographic services from IPSec.I want to get help them. We have made a secure cryptographic system,and intend to offer a standard cryp tographic API to our users.So we eager to know Is there any international standard for cryptographic API,which specifies the functions,the exact function names and parameters?So we conform to it to make the API. I've read Microsoft crypto API,and will read GSS-API and Simple crypto API (RFC 2628). I am looking forward to your reply.Thank you. Icegirl _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-ipsec@lists.tislabs.com Wed Aug 30 09:55:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13966; Wed, 30 Aug 2000 09:55:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27483 Wed, 30 Aug 2000 11:35:23 -0400 (EDT) Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB20344B9E8@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'John C. Day'" , ipsec@lists.tislabs.com Subject: RE: Looking for info on ipsec passthrough (or passthru?) Date: Wed, 30 Aug 2000 08:45:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ok, I looked it up and think I know what "passthru" is. Getting IPsec through NAT is a VERY hard problem. There isn't an easy way of associating (on the wire) that a packet with an SPI of this value needs to be demultiplexed to this destination because a packet with another SPI went through the NAT gateway... Passthru is one way of solving this, basically saying all IPsec traffic flows through the NAT to this 1 destination. Passthru is a hack until something like RSIP becomes a reality. Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: John C. Day [mailto:JCDay@JCDay.com] > Sent: Tuesday, August 29, 2000 3:56 PM > To: ipsec@lists.tislabs.com > Subject: Looking for info on ipsec passthrough (or passthru?) > > > Greetings. I'm poking around looking for information on > "IPSec passthru", > which I saw mentioned on http://www.linksys.com ("Firmware > upgrade - IPSec > passthru now supported"). > > I searched the archive files of > ftp://ftp.tis.com/pub/lists/ipsec/ipsec.0001 through ipsec.0008 but I > couldn't locate the string "passthr" anywhere in those. I > also checked > rfc2401 without success, but I'm guessing it's a feature/spec > that's been > introduced recently. > > Using google I did find a couple of mentions of it in news > groups, but I > wasn't able to locate an rfc or other doc which describes > what it's for and > how it's to be implemented. > > Any pointers? Thanks. > > John > > -- > > John C. Day > Gilroy, CA > http://www.JCDay.com > > From owner-ipsec@lists.tislabs.com Wed Aug 30 10:04:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14614; Wed, 30 Aug 2000 10:04:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27525 Wed, 30 Aug 2000 11:52:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20000830085553.00d665e0@garlic.com> X-Sender: jcday@garlic.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Aug 2000 09:03:10 -0700 To: "Strahm, Bill" , ipsec@lists.tislabs.com From: "John C. Day" Subject: RE: Looking for info on ipsec passthrough (or passthru?) In-Reply-To: <7DAA70BEB463D211AC3E00A0C96B7AB20344B9E8@orsmsx41.jf.intel .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for the response, Bill. What I'm looking for is something which will enable me to use an IPSec VPN client (Cisco/Altiga) from a privately addressed machine at home which sits behind the Linksys device which in turn is connected to my DSL bridge. The VPN server sits (or will sit, to be more accurate - it's ordered but not in hand yet) on our corporate DMZ . Would you guess this passthru feature enables such a connection? I.e., it NATs everything other than what it sees on the VPN port? While a hack, that would seem to accomplish what we need. Is there better way to do it? Thanks. John At 08:45 AM 8/30/00, you wrote: >Ok, I looked it up and think I know what "passthru" is. > >Getting IPsec through NAT is a VERY hard problem. There isn't an easy way >of associating (on the wire) that a packet with an SPI of this value needs >to be demultiplexed to this destination because a packet with another SPI >went through the NAT gateway... > >Passthru is one way of solving this, basically saying all IPsec traffic >flows through the NAT to this 1 destination. > >Passthru is a hack until something like RSIP becomes a reality. > >Bill > >______________________________________________ >Bill Strahm Programming today is a race between >bill.strahm@ software engineers striving to build >intel.com bigger and better idiot-proof programs, >(503) 264-4632 and the Universe trying to produce > bigger and better idiots. So far, the > Universe is winning.--Rich Cook >I am not speaking for Intel. And Intel rarely speaks for me > > > > -----Original Message----- > > From: John C. Day [mailto:JCDay@JCDay.com] > > Sent: Tuesday, August 29, 2000 3:56 PM > > To: ipsec@lists.tislabs.com > > Subject: Looking for info on ipsec passthrough (or passthru?) > > > > > > Greetings. I'm poking around looking for information on > > "IPSec passthru", > > which I saw mentioned on http://www.linksys.com ("Firmware > > upgrade - IPSec > > passthru now supported"). > > > > I searched the archive files of > > ftp://ftp.tis.com/pub/lists/ipsec/ipsec.0001 through ipsec.0008 but I > > couldn't locate the string "passthr" anywhere in those. I > > also checked > > rfc2401 without success, but I'm guessing it's a feature/spec > > that's been > > introduced recently. > > > > Using google I did find a couple of mentions of it in news > > groups, but I > > wasn't able to locate an rfc or other doc which describes > > what it's for and > > how it's to be implemented. > > > > Any pointers? Thanks. > > > > John > > > > -- > > > > John C. Day > > Gilroy, CA > > http://www.JCDay.com > > > > -- John C. Day Gilroy, CA http://www.JCDay.com From owner-ipsec@lists.tislabs.com Wed Aug 30 15:16:45 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA22397; Wed, 30 Aug 2000 15:16:44 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA28376 Wed, 30 Aug 2000 16:49:18 -0400 (EDT) Message-ID: From: Michel de Koning To: "'John C. Day'" , "Strahm, Bill" , ipsec@lists.tislabs.com Subject: RE: Looking for info on ipsec passthrough (or passthru?) Date: Wed, 30 Aug 2000 22:58:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi John, currently we are testing (playing with) an Altiga / Cisco 3000 vpn concentrator. It allows IPsec Passthru Nat. haven't read everything yet, but the principle is that is uses UDP instead of TCP for the IPSec packets. As soon as we have tested it I will let you know. Must say this Altiga box is really great so far, the bad thing is it does not support win2000 clients unless you use certificates, this because win2000 client does not support mode-config. Cisco says "the altiga client for win2000 will ship in october"...... Usually when cisco buys something you have to wait for version 2 before it will really work :-), let's wait and see.. We had the Altiga up and running with NT4 using PPTP and after that IPSec within an afternoon. And this was before reading the documentation! Look at it I would say Michel -----Oorspronkelijk bericht----- Van: John C. Day [mailto:JCDay@JCDay.com] Verzonden: Wednesday, August 30, 2000 6:03 PM Aan: Strahm, Bill; ipsec@lists.tislabs.com Onderwerp: RE: Looking for info on ipsec passthrough (or passthru?) Thanks for the response, Bill. What I'm looking for is something which will enable me to use an IPSec VPN client (Cisco/Altiga) from a privately addressed machine at home which sits behind the Linksys device which in turn is connected to my DSL bridge. The VPN server sits (or will sit, to be more accurate - it's ordered but not in hand yet) on our corporate DMZ . Would you guess this passthru feature enables such a connection? I.e., it NATs everything other than what it sees on the VPN port? While a hack, that would seem to accomplish what we need. Is there better way to do it? Thanks. John At 08:45 AM 8/30/00, you wrote: >Ok, I looked it up and think I know what "passthru" is. > >Getting IPsec through NAT is a VERY hard problem. There isn't an easy way >of associating (on the wire) that a packet with an SPI of this value needs >to be demultiplexed to this destination because a packet with another SPI >went through the NAT gateway... > >Passthru is one way of solving this, basically saying all IPsec traffic >flows through the NAT to this 1 destination. > >Passthru is a hack until something like RSIP becomes a reality. > >Bill > >______________________________________________ >Bill Strahm Programming today is a race between >bill.strahm@ software engineers striving to build >intel.com bigger and better idiot-proof programs, >(503) 264-4632 and the Universe trying to produce > bigger and better idiots. So far, the > Universe is winning.--Rich Cook >I am not speaking for Intel. And Intel rarely speaks for me > > > > -----Original Message----- > > From: John C. Day [mailto:JCDay@JCDay.com] > > Sent: Tuesday, August 29, 2000 3:56 PM > > To: ipsec@lists.tislabs.com > > Subject: Looking for info on ipsec passthrough (or passthru?) > > > > > > Greetings. I'm poking around looking for information on > > "IPSec passthru", > > which I saw mentioned on http://www.linksys.com ("Firmware > > upgrade - IPSec > > passthru now supported"). > > > > I searched the archive files of > > ftp://ftp.tis.com/pub/lists/ipsec/ipsec.0001 through ipsec.0008 but I > > couldn't locate the string "passthr" anywhere in those. I > > also checked > > rfc2401 without success, but I'm guessing it's a feature/spec > > that's been > > introduced recently. > > > > Using google I did find a couple of mentions of it in news > > groups, but I > > wasn't able to locate an rfc or other doc which describes > > what it's for and > > how it's to be implemented. > > > > Any pointers? Thanks. > > > > John > > > > -- > > > > John C. Day > > Gilroy, CA > > http://www.JCDay.com > > > > -- John C. Day Gilroy, CA http://www.JCDay.com From owner-ipsec@lists.tislabs.com Wed Aug 30 15:33:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA22630; Wed, 30 Aug 2000 15:33:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA28568 Wed, 30 Aug 2000 17:35:10 -0400 (EDT) From: "Joseph D. Harwood" To: Subject: RFC2401 Questions Date: Wed, 30 Aug 2000 14:45:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I've been reviewing the IPsec discussion logs, and there were a couple of items I saw that I did not find a definitive resolution to. They're listed below, along with what seemed to me to be the majority (plurality?) opinion: 1. Section 5.2.1, Checking inbound packet against SPD entry The following note is after step 4: 'NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked or until the check succeeds.' The question is, if the inbound SPD is ordered, how can the first "matching" policy not be the correct policy? My interpretation from the discussion: This note only applies if backpointers are used to find SPD entries, as each SAD entry may point to multiple SPDs. If the check is performed by doing a search through the SPD, the first "matching" policy is the correct one, and can be used to accept (kind and order were correct) or reject (kind or order were incorrect) the packet. I.e., steps 3 and 4 are not repeated if the packet selectors are used to find the first "matching" policy in the SPD. 2. AH as Protocol Selector Is AH a valid Protocol Selector, or, when AH header is found, use the "Next Header" field to find the Protocol? My interpretation from the discussion: Could be done either way, should make this configurable on a per-SA basis. (Same applies to IPComp) 3. Section 5.2.1, ICMP Error Packets If, after decapsulation, an ICMP Error Packet is generated, how is it sent back to the source? My interpretation from the discussion: The plurality opinion (and based on the comments in section 5.2.1) is that the header of the packet that caused the ICMP Error message is used to select the SA bundle (with source/destination addresses swapped, and ports swapped if available). Since the port numbers may not be available, the actual SA used may not be the exactly correct one. I.e., it could be mapped to any SA bundle that had the correct Source/Destination address. 4. Section 4.4.2, Name As Selector Are User ID and System Name valid selectors in a Security Gateway? My interpretation from the discussion: No, these are only for Host implementations. 5. ICMP 'Type' and 'Code' fields Can these be used as selectors, similar to the use of 'Port' for TCP/UDP? My interpretation from the discussion: Yes. Many thanks in advance for any feedback. Best Regards, Joseph D. Harwood From owner-ipsec@lists.tislabs.com Thu Aug 31 06:16:18 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA19544; Thu, 31 Aug 2000 06:16:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA00713 Thu, 31 Aug 2000 07:34:03 -0400 (EDT) To: "Strahm, Bill" Cc: "'John C. Day'" , ipsec@lists.tislabs.com Subject: Re: Looking for info on ipsec passthrough (or passthru?) References: <7DAA70BEB463D211AC3E00A0C96B7AB20344B9E8@orsmsx41.jf.intel.com> From: Markus Stenberg Date: 31 Aug 2000 16:40:07 +0900 In-Reply-To: "Strahm, Bill"'s message of "Wed, 30 Aug 2000 08:45:21 -0700" Message-ID: <87d7ipanfs.fsf@porsas.tokyo.jp.ssh.com> Lines: 63 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Strahm, Bill" writes: > Ok, I looked it up and think I know what "passthru" is. > > Getting IPsec through NAT is a VERY hard problem. There isn't an easy way > of associating (on the wire) that a packet with an SPI of this value needs > to be demultiplexed to this destination because a packet with another SPI > went through the NAT gateway... In the most recent IETF Pittsburgh meeting, there was actually a lot of interest on this topic. To summarize: - In general case, IPsec that will pass through NATs will require _at least_ support from endpoints, and in many of the suggested solutions from other network components as well (both approaches were given good overview by Aboba/Dixon). - There are apparently ways to just make NAT compensate for some of the changes (as presented by Brustoloni). In this case, the example NAT was Linux's ipmasq suite. - Only presented approach for doing endpoint support was our draft draft-stenberg-ipsec-nat-traversal-00.txt(*). > Passthru is one way of solving this, basically saying all IPsec traffic > flows through the NAT to this 1 destination. Passthru is very ugly hack that doesn't work in European NAT cases at all (when ISPs do NAT due to lack of sufficient address space, you can't just have 1 NAT user _total_ at same time..). > Passthru is a hack until something like RSIP becomes a reality. I _wish_ RSIP could become reality in short term. But realistically speaking: RSIP is based on the assumption that all network hardware will change just to accommodate it - which is the opposite of the assumption made with NAT deployment in the first place (=quick hack without changing infrastructure). I (more realistically?) _hope_ that the deployment efforts will be spent on IPv6 instead. > Bill -Markus (*) I'd like to have some discussion on the topic in general on the list. The draft's version -01 will have a lot of changes based on input from various sources, but additional input is always welcome. > ______________________________________________ > Bill Strahm Programming today is a race between > bill.strahm@ software engineers striving to build > intel.com bigger and better idiot-proof programs, > (503) 264-4632 and the Universe trying to produce > bigger and better idiots. So far, the > Universe is winning.--Rich Cook > I am not speaking for Intel. And Intel rarely speaks for me -- Markus Stenberg SSH Communications Security Corp (http://www.ssh.com) From owner-ipsec@lists.tislabs.com Thu Aug 31 10:26:29 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA10645; Thu, 31 Aug 2000 10:26:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01520 Thu, 31 Aug 2000 11:54:12 -0400 (EDT) Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB20344B9F1@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'Michel de Koning'" , "'John C. Day'" , "Strahm, Bill" , ipsec@lists.tislabs.com Subject: RE: Looking for info on ipsec passthrough (or passthru?) Date: Thu, 31 Aug 2000 08:56:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ok, I am confused... IPsec used ESP or AH packets, not TCP or UDP (they can be encapsulated of course) What do you mean by your first paragraph ??? Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: Michel de Koning [mailto:mdkoning@vanenburg.com] > Sent: Wednesday, August 30, 2000 1:59 PM > To: 'John C. Day'; Strahm, Bill; ipsec@lists.tislabs.com > Subject: RE: Looking for info on ipsec passthrough (or passthru?) > > > Hi John, > > currently we are testing (playing with) an Altiga / Cisco 3000 vpn > concentrator. It allows IPsec Passthru Nat. haven't read > everything yet, but > the principle is that is uses UDP instead of TCP for the > IPSec packets. As > soon as we have tested it I will let you know. > > Must say this Altiga box is really great so far, the bad > thing is it does > not support win2000 clients unless you use certificates, this because > win2000 client does not support mode-config. Cisco says "the > altiga client > for win2000 will ship in october"...... > > Usually when cisco buys something you have to wait for > version 2 before it > will really work :-), let's wait and see.. > > We had the Altiga up and running with NT4 using PPTP and > after that IPSec > within an afternoon. And this was before reading the > documentation! Look at > it I would say > > > Michel > > -----Oorspronkelijk bericht----- > Van: John C. Day [mailto:JCDay@JCDay.com] > Verzonden: Wednesday, August 30, 2000 6:03 PM > Aan: Strahm, Bill; ipsec@lists.tislabs.com > Onderwerp: RE: Looking for info on ipsec passthrough (or passthru?) > > > Thanks for the response, Bill. > > What I'm looking for is something which will enable me to use > an IPSec VPN > client (Cisco/Altiga) from a privately addressed machine at > home which sits > behind the Linksys device which in turn is connected to my DSL > bridge. The VPN server sits (or will sit, to be more > accurate - it's > ordered but not in hand yet) on our corporate DMZ . > > Would you guess this passthru feature enables such a > connection? I.e., it > NATs everything other than what it sees on the VPN port? > While a hack, > that would seem to accomplish what we need. Is there better > way to do > it? Thanks. > > John > > > > > At 08:45 AM 8/30/00, you wrote: > >Ok, I looked it up and think I know what "passthru" is. > > > >Getting IPsec through NAT is a VERY hard problem. There > isn't an easy way > >of associating (on the wire) that a packet with an SPI of > this value needs > >to be demultiplexed to this destination because a packet > with another SPI > >went through the NAT gateway... > > > >Passthru is one way of solving this, basically saying all > IPsec traffic > >flows through the NAT to this 1 destination. > > > >Passthru is a hack until something like RSIP becomes a reality. > > > >Bill > > > >______________________________________________ > >Bill Strahm Programming today is a race between > >bill.strahm@ software engineers striving to build > >intel.com bigger and better idiot-proof programs, > >(503) 264-4632 and the Universe trying to produce > > bigger and better idiots. So far, the > > Universe is winning.--Rich Cook > >I am not speaking for Intel. And Intel rarely speaks for me > > > > > > > -----Original Message----- > > > From: John C. Day [mailto:JCDay@JCDay.com] > > > Sent: Tuesday, August 29, 2000 3:56 PM > > > To: ipsec@lists.tislabs.com > > > Subject: Looking for info on ipsec passthrough (or passthru?) > > > > > > > > > Greetings. I'm poking around looking for information on > > > "IPSec passthru", > > > which I saw mentioned on http://www.linksys.com ("Firmware > > > upgrade - IPSec > > > passthru now supported"). > > > > > > I searched the archive files of > > > ftp://ftp.tis.com/pub/lists/ipsec/ipsec.0001 through > ipsec.0008 but I > > > couldn't locate the string "passthr" anywhere in those. I > > > also checked > > > rfc2401 without success, but I'm guessing it's a feature/spec > > > that's been > > > introduced recently. > > > > > > Using google I did find a couple of mentions of it in news > > > groups, but I > > > wasn't able to locate an rfc or other doc which describes > > > what it's for and > > > how it's to be implemented. > > > > > > Any pointers? Thanks. > > > > > > John > > > > > > -- > > > > > > John C. Day > > > Gilroy, CA > > > http://www.JCDay.com > > > > > > > > > -- > > John C. Day > Gilroy, CA > http://www.JCDay.com >