From owner-ipsec@lists.tislabs.com Sat Apr 1 02:26: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 CAA11546; Sat, 1 Apr 2000 02:26:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA18902 Sat, 1 Apr 2000 04:04:05 -0500 (EST) Message-Id: <01BF9BE7.D8603E80.venkatn@future.futsoft.com> From: Venkatesh N Reply-To: "venkatn@future.futsoft.com" To: "ipsec@lists.tislabs.com" Cc: "'Joern Sierwald'" Subject: RE: Inbound packet processing- mobile host problem Date: Sat, 1 Apr 2000 14:37:45 +0530 Organization: Future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let us consider the following scenario PPP internet Local intranet H1 --------[ISP]---------------- SG2 ----------------------------------H2 Here let us assume H1 is the mobile host which wants to contact one of the machines(H2) inside the home organisation. Now the H1 dials up to any local ISP and gets an Public IP address, which H1 uses to contact the SG2. In this case it is equivalent to any new machine trying to get into the organizational network, so is there any means by which the SG2 can associate the dynamically allocated IP address with H1?? Venkatesh In this case Let us On Friday, March 31, 2000 10:48 PM, Joern Sierwald [SMTP:joern.sierwald@F-Secure.com] wrote: > At 20:05 31.3.2000 +0530, you wrote: > >Hi all > >I have the following doubts regarding the IPSEC > > > >(1) According to the RFC, for the inbound packets, the SA (tunnel mode) is > retrieved based on the > > > > --The Destination IP address of the Outer IP header > > --SPI > > --IPsec protocol > > > > (a)Does this mean that the security gateway can allot the same SPI > value for the different IP addresses (supposing It has > > more than one IP addresses)? > > > Yes it can. I wouldn't implement it that way, though. It's easier that > check whether the destination addr belongs to the GW at all and then > do a (prot/SPI) lookup on incoming packets. > > >(2) In the case of a mobile host contacting the home security gateway > after dialing to a local PPP > >server on the Internet and then crossing the Internet to the home > organization's firewall , then is there any automated way > >for the discovery/verification of the security gateway/mobile host?? > > > I'm afraid that you have to rephrase that. A drawing (ASCII) would be nice > as well. > If you're asking how a FW and a SGW (two computers) can communicate > (how does the FW know that packets were handled by the SGW), > the usual way is to map the mobile users into a private network > using NAT. > > > > >Venkatesh > > > > J-rn Sierwald From owner-ipsec@lists.tislabs.com Mon Apr 3 09:07: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 JAA21037; Mon, 3 Apr 2000 09:07:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA26756 Mon, 3 Apr 2000 10:00:35 -0400 (EDT) Message-ID: <38E67914.8122CABF@worldnet.att.net> Date: Sat, 01 Apr 2000 14:32:53 -0800 From: sankarramamoorthi X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Heartbeats draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >Ricky Charlet wrote: >> >> Howdy, >> Below is the text of the heartbeat presentation I made at the ipsec >> WG meeting. Is this the real problem? If so, is this the right way to >> rank cantidate solutions. >> >> -- >> Ricky Charlet rcharlet@redcreek.com usa 510-795-6903 >> >> =========================================== >> slide 1 >> Ricky Charlet >> >> Redcreek Communications >> rcharlet@redcreek.com >> >> ============================ >> slide 2. the problem >> >> black hole detection >> for redundancy/error messaging >> for resource recovery >> for time based accounting > > Here I claim there is only one problem that we are trying to solve with >heartbeats, 'black hole detection'. But we all have differing >motivations for wanting black-hole-detection. These motivations are at I would rather change it to 'black hole detection in a manner that is proofed against DOS' - otherwise I agree with you that this seems to be the crux of the problem. In my understanding of things The following assumptions have been made 1. It is assumed sending error notification in the clear will not work, since the peer will not accept it for fear of DOS attacks. 2. It is also not possible for the party sending the 'invalid spi' notification to create a new IKE SA to send the error notification securely because a. Fear of DOS attacks - spoofed 'invalid spi' packets may cause a party to initiate IKE SAs with peers which can be considered as DOS attack b. There may not be sufficient information to set up an IKE SA with the peer - for example in the case of remote client access, the server may not have enough information about the peer to make the right SA proposal. Based on the above assumptions, solutions have been proposed along the following lines to handle the different scenarios 1. Out of sync ipsec SAs scenario Try to ensure the IKE sa corresponding to the IPSec SAs remains around. This ensures that there is an IKE SA for every active ipsec SA. So if the peers go out of step and a packet arrives with invalid spi a 'invalid spi' notification can be sent securely through the IKE SA. 2. Out of sync IKE SAs and IPSec SAs scenario It is always not possible to ensure the IKE SAs between the peers are in sync because a) one side might have rebooted (minimized somewhat with INITIAL-CONTACT notification) b) one side might have crashed c) one side might have just have plain gone out of step (software bug, IKE SA has been deleted due to want of resources and the delete notification packet got dropped..) In these cases it is not possible to send a secure message through IKE SA since it does not exist. Therefore the designers have come up with a mechanism to detect the failure of an IKE SA and react immediately - Hence the proposal for a heartbeat protocol. I request that we should explore the possiblity of sending the error notification in the clear, before coming up with heartbeat protocol as the only means of synchronizing out-of-sync peers. Here is a proposal. This proposal assumes that a ping like mechanism is supported in both and IKE and ipsec SAs. I am assuming the error notifications are sent as a result of processing some message from peer. I also assume that the error notify payload format can be enhanced to carry some information about the original message that caused the error notification (similiar to icmp error notification). As an example consider the 'invalid spi' error notification. 'invalid spi' is a result of a incoming packet. So if the 'invalid spi' notifiation message can be enhanced to carry the first 8 bytes of the original packet that caused the error - that information can be used by the peer to verify it is indeed a valid error notification for one of its active ipsec SAs. The peer can then use a IPSec ping to ensure that this notification truly came from the source of the ip packet carrying the error notification. If the ping succeeds the notification was a spoof can be ignored - else the peer can act on the notification and clean up the stale SA. The sequence is as follows <----- ipsec packet No matching SA parties out of sync ------> invalid spi + original 8 bytes of packet causing this error The error notification message is sent in the clear. recover spi from error notification packet. Find sa corresponding to spi, protcol and peer address. If sa not found drop notification message and return. <------ echo on ipsec SA If echo reply was not received even after a few retries, the error notification is genuine - clean up the stale ipsec SA ------> echo reply on ipsec SA echo reply successfully received - therefore the ipsec sa is active. Ignore the error notification and return. The above proposal would work for all the cases except the case where the peer has crashed and remains crashed. In this case the peer is dead and will not send a error notification. This case can be solved by using an inactivity timer. If an IKE SA exists with the peer and no packet has been received on any active SAs from the peer for a period of time, send a hello message through the IKE SA. If no reply is received, then clean up the inactive IKE SA and corresponding ipsec SAs. Thanks, -- sankar -- From owner-ipsec@lists.tislabs.com Mon Apr 3 09:39: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 JAA21776; Mon, 3 Apr 2000 09:39:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA27096 Mon, 3 Apr 2000 11:26:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <01BF9B4C.67D07E00.venkatn@future.futsoft.com> References: <01BF9B4C.67D07E00.venkatn@future.futsoft.com> Date: Mon, 3 Apr 2000 11:29:58 -0400 To: "venkatn@future.futsoft.com" From: Stephen Kent Subject: Re: Inbound packet processing- mobile host problem Cc: "'ipsec@lists.tislabs.com'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:05 PM +0530 3/31/00, Venkatesh N wrote: >Hi all >I have the following doubts regarding the IPSEC > >(1) According to the RFC, for the inbound packets, the SA (tunnel >mode) is retrieved based on the > > --The Destination IP address of the Outer IP header > --SPI > --IPsec protocol > > (a)Does this mean that the security gateway can allot the same >SPI value for the different IP addresses (supposing It has > more than one IP addresses)? Yes. >(2) In the case of a mobile host contacting the home security >gateway after dialing to a local PPP >server on the Internet and then crossing the Internet to the home >organization's firewall , then is there any automated way >for the discovery/verification of the security gateway/mobile host?? There is no automated security gateway discovery protocol today. Steve From owner-ipsec@lists.tislabs.com Mon Apr 3 11:29: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 LAA23541; Mon, 3 Apr 2000 11:29:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27712 Mon, 3 Apr 2000 13:09:45 -0400 (EDT) Reply-To: From: "Sankar Ramamoorthi" To: "'Ricky Charlet'" , "'.ipsec'" Subject: RE: my presentation on heartbeats Date: Mon, 3 Apr 2000 10:16:57 -0700 Message-ID: <001b01bf9d90$6ac21920$881410ac@NetScreen.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <38E2FFF2.D15523E0@redcreek.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For some reason my previous mail did not make it to the list. Giving it a try again. -- sankar -- > >Ricky Charlet wrote: >> >> Howdy, >> Below is the text of the heartbeat presentation I made at the ipsec >> WG meeting. Is this the real problem? If so, is this the right way to >> rank cantidate solutions. >> >> -- >> Ricky Charlet rcharlet@redcreek.com usa 510-795-6903 >> >> =========================================== >> slide 1 >> Ricky Charlet >> >> Redcreek Communications >> rcharlet@redcreek.com >> >> ============================ >> slide 2. the problem >> >> black hole detection >> for redundancy/error messaging >> for resource recovery >> for time based accounting > > Here I claim there is only one problem that we are trying to solve with >heartbeats, 'black hole detection'. But we all have differing >motivations for wanting black-hole-detection. These motivations are at I would rather change it to 'black hole detection in a manner that is proofed against DOS' - otherwise I agree with you that this seems to be the crux of the problem. In my understanding of things The following assumptions have been made 1. It is assumed sending error notification in the clear will not work, since the peer will not accept it for fear of DOS attacks. 2. It is also not possible for the party sending the 'invalid spi' notification to create a new IKE SA to send the error notification securely because a. Fear of DOS attacks - spoofed 'invalid spi' packets may cause a party to initiate IKE SAs with peers which can be considered as DOS attack b. There may not be sufficient information to set up an IKE SA with the peer - for example in the case of remote client access, the server may not have enough information about the peer to make the right SA proposal. Based on the above assumptions, solutions have been proposed along the following lines to handle the different scenarios 1. Out of sync ipsec SAs scenario Try to ensure the IKE sa corresponding to the IPSec SAs remains around. This ensures that there is an IKE SA for every active ipsec SA. So if the peers go out of step and a packet arrives with invalid spi a 'invalid spi' notification can be sent securely through the IKE SA. 2. Out of sync IKE SAs and IPSec SAs scenario It is always not possible to ensure the IKE SAs between the peers are in sync because a) one side might have rebooted (minimized somewhat with INITIAL-CONTACT notification) b) one side might have crashed c) one side might have just have plain gone out of step (software bug, IKE SA has been deleted due to want of resources and the delete notification packet got dropped..) In these cases it is not possible to send a secure message through IKE SA since it does not exist. Therefore the designers have come up with a mechanism to detect the failure of an IKE SA and react immediately - Hence the proposal for a heartbeat protocol. I request that we should explore the possiblity of sending the error notification in the clear, before coming up with heartbeat protocol as the only means of synchronizing out-of-sync peers. Here is a proposal. This proposal assumes that a ping like mechanism is supported in both and IKE and ipsec SAs. I am assuming the error notifications are sent as a result of processing some message from peer. I also assume that the error notify payload format can be enhanced to carry some information about the original message that caused the error notification (similiar to icmp error notification). As an example consider the 'invalid spi' error notification. 'invalid spi' is a result of a incoming packet. So if the 'invalid spi' notifiation message can be enhanced to carry the first 8 bytes of the original packet that caused the error - that information can be used by the peer to verify it is indeed a valid error notification for one of its active ipsec SAs. The peer can then use a IPSec ping to ensure that this notification truly came from the source of the ip packet carrying the error notification. If the ping succeeds the notification was a spoof can be ignored - else the peer can act on the notification and clean up the stale SA. The sequence is as follows <----- ipsec packet No matching SA parties out of sync ------> invalid spi + original 8 bytes of packet causing this error The error notification message is sent in the clear. recover spi from error notification packet. Find sa corresponding to spi, protcol and peer address. If sa not found drop notification message and return. <------ echo on ipsec SA If echo reply was not received even after a few retries, the error notification is genuine - clean up the stale ipsec SA ------> echo reply on ipsec SA echo reply successfully received - therefore the ipsec sa is active. Ignore the error notification and return. The above proposal would work for all the cases except the case where the peer has crashed and remains crashed. In this case the peer is dead and will not send a error notification. This case can be solved by using an inactivity timer. If an IKE SA exists with the peer and no packet has been received on any active SAs from the peer for a period of time, send a hello message through the IKE SA. If no reply is received, then clean up the inactive IKE SA and corresponding ipsec SAs. Thanks, -- sankar -- From owner-ipsec@lists.tislabs.com Mon Apr 3 14:11: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 OAA26263; Mon, 3 Apr 2000 14:11:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA28455 Mon, 3 Apr 2000 15:23:37 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Mon, 3 Apr 2000 12:29:21 -0700 (PDT) From: Jan Vilhuber To: sankarramamoorthi cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats draft In-Reply-To: <38E67914.8122CABF@worldnet.att.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, 1 Apr 2000, sankarramamoorthi wrote: > The sequence is as follows > > <----- ipsec packet > No matching SA > parties out of sync > > ------> invalid spi > + original 8 bytes of packet > causing this error > The error notification message > is sent in the clear. > recover spi from > error notification > packet. Find sa > corresponding to spi, > protcol and peer > address. > If sa not found > drop notification > message and return. > <------ echo on ipsec SA > If echo reply was > not received even after > a few retries, the > error notification is > genuine - clean up the > stale ipsec SA > ------> echo reply on ipsec SA > echo reply successfully > received - therefore > the ipsec sa is > active. Ignore the > error notification and > return. > This sort of scheme has already been proposed and rejected, since echo requests may or may not be covered by the classification of the tunnel. This is not a good scheme. Replace 'echo on ipsec SA' with some sort of phase 1 keepalive request and reply (not timed, but, as you proposed above, event driven when needed), and I could agree, but not if done over phase 2 (for more than just the reason given above; check the archives). I'm working on another similar proposal/idea. Once I have some things worked out someone will post something to the list. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Mon Apr 3 20: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 UAA18007; Mon, 3 Apr 2000 20:43:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29844 Mon, 3 Apr 2000 22:30:35 -0400 (EDT) Message-ID: <20000404022500.28406.qmail@web1406.mail.yahoo.com> Date: Mon, 3 Apr 2000 19:25:00 -0700 (PDT) From: Pyda Srisuresh Subject: Re: Inbound packet processing- mobile host problem To: Stephen Kent , "venkatn@future.futsoft.com" Cc: "'ipsec@lists.tislabs.com'" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --- Stephen Kent wrote: > At 8:05 PM +0530 3/31/00, Venkatesh N wrote: > >Hi all > >I have the following doubts regarding the IPSEC > > > >(1) According to the RFC, for the inbound packets, the SA (tunnel > >mode) is retrieved based on the > > > > --The Destination IP address of the Outer IP header > > --SPI > > --IPsec protocol > > > > (a)Does this mean that the security gateway can allot the same > >SPI value for the different IP addresses (supposing It has > > more than one IP addresses)? > > Yes. > > >(2) In the case of a mobile host contacting the home security > >gateway after dialing to a local PPP > >server on the Internet and then crossing the Internet to the home > >organization's firewall , then is there any automated way > >for the discovery/verification of the security gateway/mobile host?? > > There is no automated security gateway discovery protocol today. > Well, a good way to do this would be to make PPP server the Security gateway. By doing this, you have added benefits of being able to monitor IPsec SA status and scale to a large number of user security profiles. Take a look at > Steve > > cheers, suresh __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-ipsec@lists.tislabs.com Tue Apr 4 06:55: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 GAA26396; Tue, 4 Apr 2000 06:55:10 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02113 Tue, 4 Apr 2000 08:28:44 -0400 (EDT) Message-ID: <002301bf9e33$08ac6620$2dcd09c0@nig95> From: "rupesh" To: , Cc: "'Joern Sierwald'" Subject: Re: Inbound packet processing- mobile host problem Date: Tue, 4 Apr 2000 18:10:52 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0518.4 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Let us consider the following scenario > > > PPP internet Local intranet > H1 --------[ISP]---------------- SG2 ----------------------------------H2 > >Here let us assume H1 is the mobile host which wants to contact one of the machines(H2) >inside the home organisation. Now the H1 dials up to any local ISP and gets an Public IP address, >which H1 uses to contact the SG2. In this case it is equivalent to any new machine trying to >get into the organizational network, so is there any means by which the SG2 can associate the dynamically >allocated IP address with H1?? > >Venkatesh In such a case one can make use of Virtual Adaptar Interface with Routing Support at the H1 side i.e. mobile host side. In such case virtual adaptar will do following in tunnel mode. Outbound Processing from mobile host. Outer destination IP add: IP add of SG2. Outer source IP add: IP addre got from ISP. Inner destination IP add: IP add of H2 Inner source IP add: one of the IP add of intranet of organization or IP add to be used by mobile host & given by organization's System Administrator. If there is some prob. with above then please correct me. Reg Rupesh MTS Cdac, Pune From owner-ipsec@lists.tislabs.com Tue Apr 4 11:18:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02387; Tue, 4 Apr 2000 11:18:06 -0700 (PDT) From: owner-ipsec@lists.tislabs.com Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03253 Tue, 4 Apr 2000 13:07:25 -0400 (EDT) Date: Tue, 4 Apr 2000 13:07:25 -0400 (EDT) Message-Id: <200004041707.NAA03253@lists.tislabs.com> X-Authentication-Warning: ahab.tic.siemens.ca: mail set sender to using -f smap (V2.1) id xma008402; Tue, 4 Apr 00 13:07:14 -0400 mailman.innovation.siemens.ca via smap (V2.1) id xma000769; Tue, 4 Apr 00 13:07:30 -0400 Service (5.5.2448.0) id <2B8YR6XB>; Tue, 4 Apr 2000 13:07:29 -0400 Message-ID: From: Claudio Lordello To: ".IPSec-IETF" Subject: FQDN as phase 2 identity Date: Tue, 4 Apr 2000 13:07:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a question about the use of FQDN or User FQDN identity types for a phase 2 SA negotiation: What are the imposed requirements (i.e. MUST's on the RFC's) on how to translate such FQDNs into its respective phase 2 selectors, if any? I would also appreciate to hear how other vendors are doing it. DNS lookups? Thanks for the help. Claudio Lordello. Siemens. From owner-ipsec@lists.tislabs.com Tue Apr 4 11:18: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 LAA02399; Tue, 4 Apr 2000 11:18:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03125 Tue, 4 Apr 2000 12:49:40 -0400 (EDT) Message-ID: From: Rajesh Mohan To: "'IP Security List'" Subject: RE: Heartbeats draft (fwd) Date: Tue, 4 Apr 2000 09:55:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1461.28) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If IKE does not have heartbeats, what is the best we can do within the framework of current standards for peer synchronization? Here is a possible solution which in the worst case, will force tunnel end points to have Phase 1 SAs with all other known tunnel end points. By known tunnel endpoints, I mean those IKE peers with known IP Address. So, for a Security G/W, we will have few known tunnel end points for site-to-site traffic & lot of unknown tunnel end points for each remote client. For Remote Client Software, there will be few known tunnel end points and probably no unknown tunnel endpoints. Also, if you receive an INVALID SPI notification for a SA that is not old enough (local policy issue), you may ignore it as it may be spoofed NOTIFY message or the box rebooted immediately after establishing phase 1 SA. In either case, there is no need to change your behavior. Based on the assumptions, let us consider three cases 1. Security G/W to Security G/W (site-to-site) when one of the boxes reboot 2. Security G/W to Remote Client when the Security G/W reboots 3. Security G/W to Remote Client when Remote client reboots. Case 1: H1 -------------- [ S G/W 1 ] ------ [ S G/W 2 ] ---------- H2 The G/Ws have phase2 SAs & for some reason, G/W 2 reboots. For traffic from H1 to H2, G/W2 will send an INVALID SPI notification. If the G/W 2 can find from it's database that the destination of INVALID SPI is part of the VPN that is defined and it does not have phase 1 SA with this G/W 1, then establish a phase 1 SA with G/W 1 & send INVALID SPI. This may also result in sending INITIAL-CONTACT message which will help the two to synchronize. Case 2: RC1 ------- [ S G/W ] -------------- H1 S G/W reboots. Secure traffic arrives from RC1 for H1. S G/W sends INVALID SPI. It looks in its database & does not any knowledge about the RC1 IP Address. Sends the notify in clear. RC1 receives INVALID SPI in clear from S G/W. It looks for phase 1 & phase 2 SAs with S G/W. It should atleast find Phase 2 SA. If the time difference since the SA was created was old enough (local policy decision depending on the seriousness of DOS attack on Clients), create new Phase 1 SA with S G/W. It should receive INITIAL-CONTACT message from S G/W which will help the peers to synch. Case 3: RC1 --------- [ S G/W ] --------------- H1 RC1 reboots. No big deal. Happens all the time. Ignore it. There may be dead lock when [S G/W 1] has phase 1 SA with [S G/W2] that is different from [S G/W2] having phase 1 SA with [S G/W1]. - Rajesh M ---------- From: CHINNA N.R. PELLACURU [SMTP:pcn@cisco.com] Sent: Thursday, March 30, 2000 4:27 PM To: Henry Spencer Cc: IP Security List Subject: RE: Heartbeats draft (fwd) What I am trying to point out is that, it is possible (efficient) to do it in an implementation specic way, within the framework of the current IKE/IPSec standards. Heartbeats is not the only solution to the problem, and heartbeats are not efficient. -chinna On Thu, 30 Mar 2000, Henry Spencer wrote: > On Wed, 29 Mar 2000, CHINNA N.R. PELLACURU wrote: > > I think, everybody is aware of atleast one implementation that elegantly > > provides high availability, in the current framework of IKE and IPSec. So, > > I feel that high availability can be acheived in an efficient way if we do > > it in an implementation specific way. > > Uh, no, not everybody is aware of such an implementation. Please be more > specific instead of vaguely alluding to it. Explanations of exactly how it > is done would also be welcome. > > Henry Spencer > henry@spsystems.net > > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Tue Apr 4 16:02:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06669; Tue, 4 Apr 2000 16:02:15 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04583 Tue, 4 Apr 2000 17:38:43 -0400 (EDT) Date: Tue, 04 Apr 2000 14:46:08 -0700 From: "Daniel N. Meredith" Subject: Meeting Summaries To: ipsec@lists.tislabs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Does anyone know of posted summaries of the recent meetings in Adelaide? Or even a posting of the agendas from the meetings? Thanks, ~Dan ================================ Daniel N. Meredith http://www.cs.hmc.edu/~dmeredit dmeredit@cs.hmc.edu or dmeredith@cmcvax.mckenna.edu From owner-ipsec@lists.tislabs.com Tue Apr 4 16: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 QAA06695; Tue, 4 Apr 2000 16:03:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04647 Tue, 4 Apr 2000 17:58:43 -0400 (EDT) Message-Id: <4.3.2.20000404150225.00d30d70@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 04 Apr 2000 15:04:55 -0700 To: Sheela Rowles , ddp@network-alchemy.com (Derrell Piper), briansw@microsoft.com (Brian Swander) From: Paul Hoffman Subject: Re: WG Last call: draft-ietf-ipsec-isakmp-gss-auth-05.txt Cc: tytso@valinux.com (Theodore Tso), srowles@cisco.com (Sheela Rowles), ipsec@lists.tislabs.com (IPSec List) In-Reply-To: <200003310157.RAA26908@sigma.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:57 PM 3/30/00 -0800, Sheela Rowles wrote: >My understanding is that the isakmp-gss draft is an informational draft, >that basically documents one vendor's implementation (Microsoft). >As it turns out, we are also implementing the draft (we = Cisco), >and so wondered if this should be considered as a future RFC rather >than an informational draft. Is there anyone else out there >who plans to implement this? The fact that more than one company is implementing from the draft is not the deciding factor for whether it should go on standards track. If the spec is not open to change (such as if it is a description of how the originating company implemented the protocol), it should be an Informational RFC. If the spec is open for change and better design, it might be appropriate on standards track. >In any case, since this is an informational draft (documenting >Microsoft's work in this area, the draft needs to be modified >to reflect some differences between the draft and Microsoft's >current implementation: Exactly right. Anything in the spec that doesn't match Microsoft's implementation should be fixed during this last-call phase. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Apr 4 23:48: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 XAA12106; Tue, 4 Apr 2000 23:48:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA05935 Wed, 5 Apr 2000 01:34:27 -0400 (EDT) Date: Wed, 5 Apr 2000 13:39:35 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@arizona To: ipsec@lists.tislabs.com Subject: IKE interoperability In-Reply-To: <200003092101.XAA26384@torni.ssh.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Does anyone know whether OpenBSD IKE is interoperable with Windows 2000 IKE? Thanks in advance. Jianying Zhou From owner-ipsec@lists.tislabs.com Wed Apr 5 01:25: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 BAA18757; Wed, 5 Apr 2000 01:25:57 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA06256 Wed, 5 Apr 2000 02:59:01 -0400 (EDT) X-Lotus-FromDomain: MCSUB2@MCEXT From: "Jonathan Oldroyd" To: ipsec@lists.tislabs.com Message-Id: <802568B8.0026C920.00@marconicomms.com> Date: Wed, 5 Apr 2000 08:04:57 +0000 Subject: Re: Meeting Summaries MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A near-complete list of the agendas for Adelaide can be found at: http://www.ietf.org/mail-archive/ietf/Current/msg06770.html JonO From owner-ipsec@lists.tislabs.com Wed Apr 5 02:58: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 CAA22263; Wed, 5 Apr 2000 02:58:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA06700 Wed, 5 Apr 2000 04:41:23 -0400 (EDT) Message-ID: From: Michel de Koning To: ipsec@lists.tislabs.com Subject: Windows 2000 Date: Wed, 5 Apr 2000 10:43:56 +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 Could someone please help me with the following question: What clients can I use to connect to windows 2000 server over L2TP/IPSEC besides other w2k clients, and what is the preferred one? thanks in advance Michel Kind Regards, Michel de Koning Tel: +31 341 37 5427 Fax: +31 341 37 5433 Mobile: +31 651 44 68 51 E-mail: mdkoning@vanenburg.com From owner-ipsec@lists.tislabs.com Wed Apr 5 06:01: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 GAA28681; Wed, 5 Apr 2000 06:01:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA07838 Wed, 5 Apr 2000 07:41:11 -0400 (EDT) Message-Id: <01BF9F22.71EE2480.ruheenar@future.futsoft.com> From: Ruheena R Reply-To: "ruheenar@future.futsoft.com" To: "'dharkins@cisco.com'" , "'carrel@ipsec.org'" Cc: "'ipsec@lists.tislabs.com'" Subject: Query -IPsec SA negotiation Date: Wed, 5 Apr 2000 17:14:46 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If we want to establish many IPSEC SA's from the same host to the particular destination depending on the transport layer protocol and ports. How is it possible to negotiate different SA's with these parameters. Since the rfc 2409 specifies only the destination, source IP address and security protocol type in the quick mode. It does not offer a field to negotiate the protocol and port . How can the situation be taken care? Ruheena From owner-ipsec@lists.tislabs.com Wed Apr 5 07:09: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 HAA29790; Wed, 5 Apr 2000 07:09:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08129 Wed, 5 Apr 2000 08:42:19 -0400 (EDT) Message-Id: <3.0.5.32.20000405152330.00ce97a0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 05 Apr 2000 15:23:30 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Query -IPsec SA negotiation In-Reply-To: <01BF9F22.71EE2480.ruheenar@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA07959 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 17:14 5.4.2000 +0530, you wrote: >If we want to establish many IPSEC SA's from the same host to the >particular destination depending on the transport layer protocol and > ports. How is it possible to negotiate different SA's with these >parameters. Since the rfc 2409 specifies only the destination, source IP >address and security protocol type in the quick mode. It does not offer a >field to negotiate the protocol and port . > >How can the situation be taken care? > >Ruheena > > Read RFC2407, 4.6.2. The ID payload has protocol and port fields. J–rn From owner-ipsec@lists.tislabs.com Wed Apr 5 07:11: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 HAA29850; Wed, 5 Apr 2000 07:11:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08195 Wed, 5 Apr 2000 08:59:51 -0400 (EDT) Date: Wed, 5 Apr 2000 15:55:36 +0300 (EET DST) From: Markku Savela Message-Id: <200004051255.PAA07646@anise.tte.vtt.fi> To: ruheenar@future.futsoft.com CC: dharkins@cisco.com, carrel@ipsec.org, ipsec@lists.tislabs.com In-reply-to: <01BF9F22.71EE2480.ruheenar@future.futsoft.com> (message from Ruheena R on Wed, 5 Apr 2000 17:14:46 +0530) Subject: Re: Query -IPsec SA negotiation Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Ruheena R > If we want to establish many IPSEC SA's from the same host to the > particular destination depending on the transport layer protocol and > ports. How is it possible to negotiate different SA's with these > parameters. Since the rfc 2409 specifies only the destination, source IP > address and security protocol type in the quick mode. It does not offer a > field to negotiate the protocol and port . > > How can the situation be taken care? I don't know about other implementations, but at least this works for me: - if the policy specifies that a different protection is to be used depending on ports, the kernel IPSEC will generate PFKEY acquire message that includes the port information. - the actual IKE negotiation need not concern with the ports, we are just requesting to setup a new SAs with certain algorithms and keys (as specified in the ACQUIRE request) - on successful negotiation, IKE just loads the SA's to the kernel *WITH* the same port information as the original ACQUIRE had, and the kernel side can use the appropriate different SA's as dictated by the policy (as described in RFC 2401) -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Wed Apr 5 08:35: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 IAA01237; Wed, 5 Apr 2000 08:35:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08419 Wed, 5 Apr 2000 10:05:35 -0400 (EDT) Date: Wed, 5 Apr 2000 17:12:15 +0300 (EET DST) From: Markku Savela Message-Id: <200004051412.RAA08191@anise.tte.vtt.fi> To: ruheenar@future.futsoft.com, ipsec@lists.tislabs.com In-reply-to: <200004051255.PAA07646@anise.tte.vtt.fi> (message from Markku Savela on Wed, 5 Apr 2000 15:55:36 +0300 (EET DST)) Subject: Re: Query -IPsec SA negotiation Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ooops... I said.. > - the actual IKE negotiation need not concern with the ports, we > are just requesting to setup a new SAs with certain algorithms > and keys (as specified in the ACQUIRE request) and as joern@smtp.datafellows.com pointed, there is the Identify payload (RFC2407, 4.6.2.) in phase 2? Thus I guess we need to fix our implementation to put the port/protocol from the ACQUIRE into negotiations, so that the responder knows to do the right thing? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Wed Apr 5 08:53: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 IAA01394; Wed, 5 Apr 2000 08:53:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08484 Wed, 5 Apr 2000 10:28:47 -0400 (EDT) From: "Glen Zorn" To: "Michel de Koning" , Subject: RE: Windows 2000 Date: Wed, 5 Apr 2000 07:34:42 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wind River has an L2TP/IPSec client that runs on Win9x and has successfully interoperated with several L2TP/IPSec server, includin Win2K and Cisco. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michel de Koning > Sent: Wednesday, April 05, 2000 1:44 AM > To: ipsec@lists.tislabs.com > Subject: Windows 2000 > > > Could someone please help me with the following question: > > What clients can I use to connect to windows 2000 server over L2TP/IPSEC > besides other w2k clients, and what is the preferred one? > > thanks in advance > > Michel > > Kind Regards, > > > Michel de Koning > Tel: +31 341 37 5427 > Fax: +31 341 37 5433 > Mobile: +31 651 44 68 51 > E-mail: mdkoning@vanenburg.com > > > From owner-ipsec@lists.tislabs.com Wed Apr 5 09:05:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01531; Wed, 5 Apr 2000 09:05:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08561 Wed, 5 Apr 2000 10:51:41 -0400 (EDT) Message-Id: <200004051452.HAA19862@potassium.network-alchemy.com> To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: ruheenar@future.futsoft.com, carrel@ipsec.org, ipsec@lists.tislabs.com Subject: Re: Query -IPsec SA negotiation In-reply-to: Your message of "Wed, 05 Apr 2000 15:55:36 +0300." <200004051255.PAA07646@anise.tte.vtt.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19859.954946322.1@network-alchemy.com> Date: Wed, 05 Apr 2000 07:52:02 -0700 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 05 Apr 2000 15:55:36 +0300 you wrote > > From: Ruheena R > > > If we want to establish many IPSEC SA's from the same host to the > > particular destination depending on the transport layer protocol and > > ports. How is it possible to negotiate different SA's with these > > parameters. Since the rfc 2409 specifies only the destination, source IP > > address and security protocol type in the quick mode. It does not offer a > > > field to negotiate the protocol and port . > > > > How can the situation be taken care? > > I don't know about other implementations, but at least this works for > me: > > - if the policy specifies that a different protection is to be used > depending on ports, the kernel IPSEC will generate PFKEY acquire > message that includes the port information. > > - the actual IKE negotiation need not concern with the ports, we > are just requesting to setup a new SAs with certain algorithms > and keys (as specified in the ACQUIRE request) > > - on successful negotiation, IKE just loads the SA's to the kernel > *WITH* the same port information as the original ACQUIRE had, and > the kernel side can use the appropriate different SA's as > dictated by the policy (as described in RFC 2401) That's the problem with PFKEY. The ACQUIRE message does not contain that information and IKE therefore cannot convey the wishes of your policy onto the other peer. Of course you'll say, "so what? IKE shouldn't negotiate policy" but then how do you convey your wishes to the peer? You have policy that specifies different protection is to be applied depending on ports. What if the other guy doesn't? He will start sending you traffic that he thinks is completely legitimate to send (since he just negotiated two SAs without any constraints) and you will drop because it is not. In a perfect world this would not happen since everyone would automagically know what everyone else's policy restrictions are; this is not a perfect world. The way to convey port and protocol information in an IKE exchange is using the ID payloads as defined in RFC2407. The way to get that information to IKE is to modify your PFKEY so it is, unfortunately, not RFC2367 compliant anymore. Or not use PFKEY. Dan. From owner-ipsec@lists.tislabs.com Wed Apr 5 09:37: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 JAA01953; Wed, 5 Apr 2000 09:37:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08691 Wed, 5 Apr 2000 11:17:31 -0400 (EDT) Message-Id: <01BF9F40.A9EBF600.venkatn@future.futsoft.com> From: Venkatesh N Reply-To: "venkatn@future.futsoft.com" To: "ipsec@lists.tislabs.com" Subject: ordering of the bundle Date: Wed, 5 Apr 2000 20:51:05 +0530 Organization: Future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The RFC2401 states that " If AH is used in a transport mode, in conjunction with ESP, AH SHOULD appear as the first header after IP, prior to the appearance of ESP. In that context, AH is applied to the ciphertext output of ESP. In contrast, for tunnel mode SAs, one can imagine uses for various orderings of AH and ESP. " is there any advantage of applying the ESP after doing AH for outbound packets in the tunnel mode case? ^^^^^^^^^^^^^^ Venkatesh From owner-ipsec@lists.tislabs.com Wed Apr 5 12:18: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 MAA04189; Wed, 5 Apr 2000 12:18:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09418 Wed, 5 Apr 2000 14:08:51 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Claudio Lordello Cc: ".IPSec-IETF" , vern@aciri.org Subject: Re: FQDN as phase 2 identity Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Apr 2000 14:15:22 -0400 Message-Id: <20000405181531.721A341F16@SIGABA.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Claudio Lordello writes: > > (Sorry for the re-post. It got corrupted the first time) > > Hi, > > I have a question about the use of FQDN or User FQDN identity types for a > phase 2 SA negotiation: What are the imposed requirements (i.e. MUST's on > the RFC's) on how to translate such FQDNs into its respective phase 2 > selectors, if any? I would also appreciate to hear how other vendors are > doing it. DNS lookups? > In Adelaide, during my discussion on SCTP, I noted that this was not well defined. In particular, what if the FQDN resolves to multiple IP addresses? SCTP support will require a new type supporting a list of IP addresses, with corresponding support elsewhere; FQDN will require these other changes as well. --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Apr 5 12:18: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 MAA04202; Wed, 5 Apr 2000 12:18:40 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09350 Wed, 5 Apr 2000 13:52:14 -0400 (EDT) Message-ID: From: Claudio Lordello To: ".IPSec-IETF" , Claudio Lordello Subject: FQDN as phase 2 identity Date: Wed, 5 Apr 2000 13:58:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk (Sorry for the re-post. It got corrupted the first time) Hi, I have a question about the use of FQDN or User FQDN identity types for a phase 2 SA negotiation: What are the imposed requirements (i.e. MUST's on the RFC's) on how to translate such FQDNs into its respective phase 2 selectors, if any? I would also appreciate to hear how other vendors are doing it. DNS lookups? Thanks for any help. Claudio Lordello. Siemens. From owner-ipsec@lists.tislabs.com Wed Apr 5 12:58: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 MAA04765; Wed, 5 Apr 2000 12:58:56 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09829 Wed, 5 Apr 2000 14:50:02 -0400 (EDT) Message-ID: <003501bf9f30$8abc3520$fa811818@we.mediaone.net> From: "Mark" To: References: Subject: Re: Windows 2000 Date: Wed, 5 Apr 2000 11:55:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have been using both IRE SafeNet/Soft-PK and Cisco routers with W2K for some time without any issues... ----- Original Message ----- From: "Michel de Koning" To: Sent: Wednesday, April 05, 2000 1:43 AM Subject: Windows 2000 > Could someone please help me with the following question: > > What clients can I use to connect to windows 2000 server over L2TP/IPSEC > besides other w2k clients, and what is the preferred one? > > thanks in advance > > Michel > > Kind Regards, > > > Michel de Koning > Tel: +31 341 37 5427 > Fax: +31 341 37 5433 > Mobile: +31 651 44 68 51 > E-mail: mdkoning@vanenburg.com > From owner-ipsec@lists.tislabs.com Wed Apr 5 13:00: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 NAA04790; Wed, 5 Apr 2000 13:00:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09857 Wed, 5 Apr 2000 14:52:51 -0400 (EDT) From: Sheela Rowles Message-Id: <200004051858.LAA23758@sigma.cisco.com> Subject: Re: WG Last call: draft-ietf-ipsec-isakmp-gss-auth-05.txt To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Wed, 5 Apr 2000 11:58:16 -0700 (PDT) Cc: srowles@cisco.com (Sheela Rowles), ddp@network-alchemy.com (Derrell Piper), briansw@microsoft.com (Brian Swander), tytso@valinux.com (Theodore Tso), ipsec@lists.tislabs.com (IPSec List) In-Reply-To: <4.3.2.20000404150225.00d30d70@mail.vpnc.org> from "Paul Hoffman" at Apr 04, 2000 03:04:55 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > At 05:57 PM 3/30/00 -0800, Sheela Rowles wrote: > >My understanding is that the isakmp-gss draft is an informational draft, > >that basically documents one vendor's implementation (Microsoft). > >As it turns out, we are also implementing the draft (we = Cisco), > >and so wondered if this should be considered as a future RFC rather > >than an informational draft. Is there anyone else out there > >who plans to implement this? > > The fact that more than one company is implementing from the draft is not > the deciding factor for whether it should go on standards track. If the > spec is not open to change (such as if it is a description of how the > originating company implemented the protocol), it should be an > Informational RFC. If the spec is open for change and better design, it > might be appropriate on standards track. Paul, Who would make this decision - that the spec is open for change vs being closed? thanks, Sheela > > >In any case, since this is an informational draft (documenting > >Microsoft's work in this area, the draft needs to be modified > >to reflect some differences between the draft and Microsoft's > >current implementation: > > Exactly right. Anything in the spec that doesn't match Microsoft's > implementation should be fixed during this last-call phase. > > --Paul Hoffman, Director > --VPN Consortium > > > > From owner-ipsec@lists.tislabs.com Wed Apr 5 13:12: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 NAA05025; Wed, 5 Apr 2000 13:12:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09885 Wed, 5 Apr 2000 15:02:37 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 5 Apr 2000 12:08:17 -0700 (PDT) From: Jan Vilhuber To: Sankar Ramamoorthi cc: "'sankarramamoorthi'" , ipsec@lists.tislabs.com Subject: RE: Heartbeats draft In-Reply-To: <000601bf9f30$d220ba30$881410ac@NetScreen.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 5 Apr 2000, Sankar Ramamoorthi wrote: > I agree that inserting 'echo requests' into an ipsec sa may be cumbersome. Cumbersome isn't the word I would have used, but yes.. > I was assuming that if the inner ip header containing the ping packet > can be addressed to the gateway and that traffic addressed > to the gateway(on the inner packet) can be sent through any ipsec SA to > the gateway. This is possible if we allow the gateway to implicitly match > the > ipsec SA selectors for all SAs (too many assumptions). > *WAY* too many assuptions. > As you mention the 'echo on ipsec SA' could be replaced with IKE SA, > if we assume that the a IKE gateway/endpoint will always ensure > IKE SA is around while there are active ipsec SAs. I did not want into > the get into the old argument about 'dangling SAs'. Well.. although I am of the camp that advocates 'dangling SA's, I'm also of the opinion, that if you want continuous keepalives, you'll have to try to keep the SA around. I don't advocate this out of any tying of the phase 2 SA's to the phase 1 SA or anything like that. It's just that if you want keepalives, you'll have to refresh your phase 1 SA periodically, if for no other reason than to send the keepalive. You can't have it both ways, and that's a concession I'm willing to make. If there are resource issues (which is why some people delete the phase 1 SA's before they expire, which is fine), then you shouldn't have configured keepalives. > Also if we use IKE SA's for ping, the 'echo reply' can be made to carry > out the list of active spi list so that both sides can synchronize the > ipsec SAs. > That's part of Andrew's proposal. > The main intention of the proposal was to find out whether we > can get away without having to invent a negotiated heartbeat protocol > for peer synchronization. > That's up for debate, still. The question I guess (in some people's minds) is whether this is all nonesense, and we can solve it with ack'd notifies (and deletes) and with initial contact messages. Since there's still ambiguities with initial contact messages in my mind (and, I guess they are unauthenticated!), there's still doubt in my mind that this is the correct solution. Implementing some sort of keepalives scheme is quicker than having the working group agree on changes in the IKE draft to make things more reliable... Just my 2c.. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Apr 5 15:04: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 PAA06877; Wed, 5 Apr 2000 15:04:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10696 Wed, 5 Apr 2000 16:52:49 -0400 (EDT) Message-ID: <38EBA9A4.6F7DF8DA@redcreek.com> Date: Wed, 05 Apr 2000 14:01:24 -0700 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: Heartbeats draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > > The main intention of the proposal was to find out whether we > > can get away without having to invent a negotiated heartbeat protocol > > for peer synchronization. > > > That's up for debate, still. The question I guess (in some people's minds) is > whether this is all nonesense, and we can solve it with ack'd notifies (and > deletes) and with initial contact messages. Since there's still ambiguities > with initial contact messages in my mind (and, I guess they are > unauthenticated!), there's still doubt in my mind that this is the correct > solution. Implementing some sort of keepalives scheme is quicker than having > the working group agree on changes in the IKE draft to make things more > reliable... > > Just my 2c.. > Howdy, Keeping SADs sychronized on both peers is not (IMHO) a goal of a heartbeat protocol. Although heartbeats have been proposed as a solution in that space and large amounts of list discussion have been generated there. I guess the debate still goes on. I propose that issues with SAD sychronization should be dealt with at their root cause (as I think they are by the son-of-ike draft with acknowledged notifies) and not in a heatbeat protocol. Opinions? The only remaining motivation I see for doing some type of interoperable heartbeat is for black-hole-detection. Different actions are possible once you know you have a black hole and different vendors may have different approaches to actions after a black hole is detected. You might want do a 'fail-over' to another gateway, you might want to send error notifications back the the traffic originator, you might want to just fail the SA and clean up your state and structure. Although all us implementors may have differing motivations and may take differing actions, we all want to know when a black hole exists. Sometimes our motivations make us willing to spend a large amount (if necessary) of resources to detect black holes. Sometimes our motivations advise us that if the resource cost is anything more than trivial, we would just as soon forget about black hole detection. So do we have sufficient motivation to want to work togehter on a black-hole detection mechanism ? (some on this list have pointed out that heartbeats are not required for even this) From my perspective, black-hole detection is a must for our customers and I'd rather it be interoperable than propriatary. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Wed Apr 5 15:12: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 PAA06976; Wed, 5 Apr 2000 15:12:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10795 Wed, 5 Apr 2000 17:14:56 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 5 Apr 2000 14:20:44 -0700 (PDT) From: Jan Vilhuber To: Ricky Charlet cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats draft In-Reply-To: <38EBA9A4.6F7DF8DA@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 5 Apr 2000, Ricky Charlet wrote: > From my perspective, black-hole detection is a must for our customers > and I'd rather it be interoperable than propriatary. > Absolutely agreed. Just don't do it in phase 2, and we can start working on details, i.e. heartbeat, or request-reply notifies... I think the SPI's-in-the-heartbeat thing was a nice idea, not the main thrust. I can live without that IF we have *mandatory* ack'd notifies and a solid INITIAL-CONTACT message (it's not authenticated, and I still have some questions about the semantics in, say, routers, i.e. something that's not an end-system...). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Apr 5 15:39: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 PAA07261; Wed, 5 Apr 2000 15:39:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10872 Wed, 5 Apr 2000 17:35:27 -0400 (EDT) Date: Wed, 5 Apr 2000 17:42:00 -0400 Message-Id: <200004052142.RAA13387@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rcharlet@redcreek.com Cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats draft References: <38EBA9A4.6F7DF8DA@redcreek.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Ricky" == Ricky Charlet writes: Ricky> Jan Vilhuber wrote: >> > The main intention of the proposal was to find out whether we > >> can get away without having to invent a negotiated heartbeat >> protocol > for peer synchronization. > That's up for debate, >> still. The question I guess (in some people's minds) is whether >> this is all nonesense, and we can solve it with ack'd notifies >> (and deletes) and with initial contact messages. Since there's >> still ambiguities with initial contact messages in my mind (and, I >> guess they are unauthenticated!), there's still doubt in my mind >> that this is the correct solution. Implementing some sort of >> keepalives scheme is quicker than having the working group agree >> on changes in the IKE draft to make things more reliable... >> >> Just my 2c.. >> Ricky> Howdy, Keeping SADs sychronized on both peers is not (IMHO) a Ricky> goal of a heartbeat protocol. Although heartbeats have been Ricky> proposed as a solution in that space and large amounts of list Ricky> discussion have been generated there. I guess the debate still Ricky> goes on. I propose that issues with SAD sychronization should Ricky> be dealt with at their root cause (as I think they are by the Ricky> son-of-ike draft with acknowledged notifies) and not in a Ricky> heatbeat protocol. Opinions? I'd say that it is not the first priority of the protocol. On the other hand, acknowledged notifies do not provide a self-stabilizing solution. While not all protocols we commonly use are self-stabilizing, I believe it is well recognized that the self-stabilizing property is a valuable property to have in a protocol. The more serious the consequences of mis-synchronization, the more this is true. For IPSEC, the consequences extend all the way to complete failure to communicate for an extended period of time (the SA lifetime). Because of this, I believe SAD synchronization *is* an important goal. paul From owner-ipsec@lists.tislabs.com Wed Apr 5 16:58: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 QAA08389; Wed, 5 Apr 2000 16:58:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11043 Wed, 5 Apr 2000 18:51:01 -0400 (EDT) From: "Scott Fanning" To: "Ricky Charlet" , Subject: RE: Heartbeats draft Date: Tue, 4 Apr 2000 15:57:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38EBA9A4.6F7DF8DA@redcreek.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ricky First, I think that this discussion is required. IKE needs a greater degree of reliability. Most protocols build on UDP talk about mechanisms to ensure that transport is somewhat reliable (RADIUS is a good example). IKE need this too. I agree that black-hole detection is very important for the reasons you stated, but a heartbeat can detect this. If I don't receive a heart-beat, then chances are I have a dead peer/black-hole. What part of heartbeats don't detect a black-hole? How quickly do we need to detect a dead peer? I suspect the in failover case, it is ASAP. The SPI list is optional and it is an option I may not want to use. It terms of SPD synchronization, ack'd NOTIFIES (deletes at the very least) and INITIAL-CONTACT and reduce sync issues. I propose that these become MUSTs for the son-of-ike draft. Just my 2 cents US (40 dollars AUD :-) ) Scott > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ricky Charlet > Sent: Wednesday, April 05, 2000 2:01 PM > To: ipsec@lists.tislabs.com > Subject: Re: Heartbeats draft > > > Jan Vilhuber wrote: > > > The main intention of the proposal was to find out whether we > > > can get away without having to invent a negotiated heartbeat protocol > > > for peer synchronization. > > > > > That's up for debate, still. The question I guess (in some > people's minds) is > > whether this is all nonesense, and we can solve it with ack'd > notifies (and > > deletes) and with initial contact messages. Since there's still > ambiguities > > with initial contact messages in my mind (and, I guess they are > > unauthenticated!), there's still doubt in my mind that this is > the correct > > solution. Implementing some sort of keepalives scheme is > quicker than having > > the working group agree on changes in the IKE draft to make things more > > reliable... > > > > Just my 2c.. > > > > Howdy, > Keeping SADs sychronized on both peers is not (IMHO) a goal of a > heartbeat protocol. Although heartbeats have been proposed as a solution > in that space and large amounts of list discussion have been generated > there. I guess the debate still goes on. I propose that issues with SAD > sychronization should be dealt with at their root cause (as I think they > are by the son-of-ike draft with acknowledged notifies) and not in a > heatbeat protocol. Opinions? > > The only remaining motivation I see for doing some type of > interoperable heartbeat is for black-hole-detection. Different actions > are possible once you know you have a black hole and different vendors > may have different approaches to actions after a black hole is detected. > You might want do a 'fail-over' to another gateway, you might want to > send error notifications back the the traffic originator, you might want > to just fail the SA and clean up your state and structure. Although all > us implementors may have differing motivations and may take differing > actions, we all want to know when a black hole exists. Sometimes our > motivations make us willing to spend a large amount (if necessary) of > resources to detect black holes. Sometimes our motivations advise us > that if the resource cost is anything more than trivial, we would just > as soon forget about black hole detection. > > So do we have sufficient motivation to want to work togehter on a > black-hole detection mechanism ? (some on this list have pointed out > that heartbeats are not required for even this) > > From my perspective, black-hole detection is a must for our > customers > and I'd rather it be interoperable than propriatary. > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > > From owner-ipsec@lists.tislabs.com Wed Apr 5 17:14: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 RAA08739; Wed, 5 Apr 2000 17:13:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11075 Wed, 5 Apr 2000 19:13:27 -0400 (EDT) Message-ID: <38EBCA9F.DE957587@redcreek.com> Date: Wed, 05 Apr 2000 16:22:07 -0700 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jan Vilhuber CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber wrote: > > On Wed, 5 Apr 2000, Ricky Charlet wrote: > > From my perspective, black-hole detection is a must for our customers > > and I'd rather it be interoperable than propriatary. > > > Absolutely agreed. Just don't do it in phase 2, and we can start working on > details, i.e. heartbeat, or request-reply notifies... Agreed. Actually It was your arguments previous in this thread which convinced me that phase 2 pings are bad. I've come around to seeing phase 1 hellos as the most scalable and easily implementable black hole detector. > > I think the SPI's-in-the-heartbeat thing was a nice idea, not the main > thrust. I can live without that IF we have *mandatory* ack'd notifies and a > solid INITIAL-CONTACT message (it's not authenticated, and I still have some > questions about the semantics in, say, routers, i.e. something that's not an > end-system...). > I'm not opposed to optional spi lists transported by the heartbeat packet. But I do want to be clear that SAD sychronization is a different problem (which is a valid work item in its own right) from black hole detection. It might turn out that sending spi lists around is the right solution for SAD sychronization, or maybe there are other approaches to it which are better. I don't have strong opinions there (or even weak ones :-). But I am trying to gather consensus that black hole detection is the problem which heartbeats address. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Wed Apr 5 17:27: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 RAA08964; Wed, 5 Apr 2000 17:27:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11124 Wed, 5 Apr 2000 19:28:37 -0400 (EDT) X-Authentication-Warning: jvilhube-ss20.cisco.com: vilhuber owned process doing -bs Date: Wed, 5 Apr 2000 16:34:02 -0700 (PDT) From: Jan Vilhuber To: Ricky Charlet cc: ipsec@lists.tislabs.com Subject: Re: Heartbeats draft In-Reply-To: <38EBCA9F.DE957587@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 5 Apr 2000, Ricky Charlet wrote: > Jan Vilhuber wrote: > > > > On Wed, 5 Apr 2000, Ricky Charlet wrote: > > > From my perspective, black-hole detection is a must for our customers > > > and I'd rather it be interoperable than propriatary. > > > > > Absolutely agreed. Just don't do it in phase 2, and we can start working on > > details, i.e. heartbeat, or request-reply notifies... > > > Agreed. Actually It was your arguments previous in this thread which > convinced me that phase 2 pings are bad. I've come around to seeing > phase 1 hellos as the most scalable and easily implementable black hole > detector. > This is basically the way we implemented our version of keepalives, except they are timed (and expected on both ends). Internally, we've discussed a way to do keepalives along the lines mentioned by you and previously by someone else (don't remember the name), i.e. not heartbeats. Either end can, at any time, send a keepalive-req, and the other end MUST reply. However the other end may NOT make any assupmtions about when the next request comes in. Works both ways of course. If one end wants to do this periodically, fine. If one end wants to do it only when it thinks it needs to, fine. Either way will work. As long as one end doesn't expect the other to send the requests (i.e. doesn't have a timer that tells it when to expect a request from the other end), you have flexibility. If they are sent with the same frequency as heartbeats would have been sent, then you've doubled the traffic and work. True. But if you send them less frequently, and possibly only when you suspect something is wrong, then you win. This is required for dial-up lines for example. It seems that it is also necessary to scale properly, so that there's not a constant flood of keepalives going around (still possible in this approach, of course, but not NECESSARY). To be perfectly honest, I can see different applications for either one. I'm almost convinced we need both. Not too sure. I'm rambling. > > > > I think the SPI's-in-the-heartbeat thing was a nice idea, not the main > > thrust. I can live without that IF we have *mandatory* ack'd notifies and a > > solid INITIAL-CONTACT message (it's not authenticated, and I still have some > > questions about the semantics in, say, routers, i.e. something that's not an > > end-system...). > > > > I'm not opposed to optional spi lists transported by the heartbeat > packet. But I do want to be clear that SAD sychronization is a different > problem (which is a valid work item in its own right) from black hole > detection. It might turn out that sending spi lists around is the right > solution for SAD sychronization, or maybe there are other approaches to > it which are better. I don't have strong opinions there (or even weak > ones :-). But I am trying to gather consensus that black hole detection > is the problem which heartbeats address. > Fair enough. I don't mind the SPI-list thing as an added bonus, though. I sort of feel (but have no logical argument for it) that more is better in this problem-space, i.e. if we have two things that help with SAD synchronisation (and help in error checking themselves), so much the better (as long as it doesn't add undue complexity, which I don't feel Andrew's SPI list does; I'm just not sure how they fly with randomized SPI's, though, which I thought SPI's should be, but I could be wrong). Robustness is good! It sells more ipsec, if it's stable, which makes me happy if the stock price goes up, but makes me even MORE happy as it proliferates strong crypto. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Apr 5 20:35: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 UAA01357; Wed, 5 Apr 2000 20:35:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA11764 Wed, 5 Apr 2000 22:29:57 -0400 (EDT) Message-ID: <00df01bf9f71$86b51b40$4c084a0a@isl.melco.co.jp> From: "Akira Watanabe" To: Subject: AH and ESP in tunnel mode Date: Thu, 6 Apr 2000 11:40:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" 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 Could someone tell me the following question: In RFC2401, 4.5 Basic Combinations of Security Associations, examples of tunnel mode in case1 and case 2 (especially in case 2), I would like to use the headers of [IP2] [AH] [ESP] [IP1] [upper], which is not written in the document. Are there any problem? Akira Watanabe From owner-ipsec@lists.tislabs.com Wed Apr 5 23:56: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 XAA12079; Wed, 5 Apr 2000 23:56:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA12265 Thu, 6 Apr 2000 01:50:18 -0400 (EDT) Message-Id: <01BF9FBA.7DCA3300.ruheenar@future.futsoft.com> From: Ruheena R Reply-To: "ruheenar@future.futsoft.com" To: "'Dan Harkins'" , Markku Savela Cc: "ruheenar@kailash.future.futsoft.com" , "carrel@ipsec.org" , "ipsec@lists.tislabs.com" Subject: RE: Query -IPsec SA negotiation Date: Thu, 6 Apr 2000 11:23:09 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Thanks for the prompt reply. Well, I need some more clarifications. If "ACQUIRE request" is modified to include the fields 'protocol' and 'port', in that case, will the other routers be able to correctly interpret the ACQUIRE request ? Generally, how is the SA negotiation/establishment performed ? I mean, does it include the port and the protocol information ? Regards Ruheena. -----Original Message----- From: Dan Harkins [SMTP:dharkins@network-alchemy.com] Sent: Wednesday, April 05, 2000 8:22 PM To: Markku Savela Cc: ruheenar@kailash.future.futsoft.com; carrel@ipsec.org; ipsec@lists.tislabs.com Subject: Re: Query -IPsec SA negotiation On Wed, 05 Apr 2000 15:55:36 +0300 you wrote > > From: Ruheena R > > > If we want to establish many IPSEC SA's from the same host to the > > particular destination depending on the transport layer protocol and > > ports. How is it possible to negotiate different SA's with these > > parameters. Since the rfc 2409 specifies only the destination, source IP > > address and security protocol type in the quick mode. It does not offer a > > > field to negotiate the protocol and port . > > > > How can the situation be taken care? > > I don't know about other implementations, but at least this works for > me: > > - if the policy specifies that a different protection is to be used > depending on ports, the kernel IPSEC will generate PFKEY acquire > message that includes the port information. > > - the actual IKE negotiation need not concern with the ports, we > are just requesting to setup a new SAs with certain algorithms > and keys (as specified in the ACQUIRE request) > > - on successful negotiation, IKE just loads the SA's to the kernel > *WITH* the same port information as the original ACQUIRE had, and > the kernel side can use the appropriate different SA's as > dictated by the policy (as described in RFC 2401) That's the problem with PFKEY. The ACQUIRE message does not contain that information and IKE therefore cannot convey the wishes of your policy onto the other peer. Of course you'll say, "so what? IKE shouldn't negotiate policy" but then how do you convey your wishes to the peer? You have policy that specifies different protection is to be applied depending on ports. What if the other guy doesn't? He will start sending you traffic that he thinks is completely legitimate to send (since he just negotiated two SAs without any constraints) and you will drop because it is not. In a perfect world this would not happen since everyone would automagically know what everyone else's policy restrictions are; this is not a perfect world. The way to convey port and protocol information in an IKE exchange is using the ID payloads as defined in RFC2407. The way to get that information to IKE is to modify your PFKEY so it is, unfortunately, not RFC2367 compliant anymore. Or not use PFKEY. Dan. From owner-ipsec@lists.tislabs.com Thu Apr 6 02:49: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 CAA22063; Thu, 6 Apr 2000 02:49:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA12751 Thu, 6 Apr 2000 04:09:32 -0400 (EDT) Date: Thu, 6 Apr 2000 11:15:14 +0300 (EET DST) From: Markku Savela Message-Id: <200004060815.LAA08647@anise.tte.vtt.fi> To: ruheenar@future.futsoft.com CC: dharkins@network-alchemy.com, ruheenar@kailash.future.futsoft.com, carrel@ipsec.org, ipsec@lists.tislabs.com In-reply-to: <01BF9FBA.7DCA3300.ruheenar@future.futsoft.com> (message from Ruheena R on Thu, 6 Apr 2000 11:23:09 +0530) Subject: RE: Query -IPsec SA negotiation Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > ..., I need some more clarifications. If "ACQUIRE request" is > modified to include the fields 'protocol' and 'port', in that case, > will the other routers be able to correctly interpret the ACQUIRE > request ? First, some clarifications - ACQUIRE message is part of PFKEY, which is separate from IKE. I use use it, some others don't. - ACQUIRE message *does* include src and dst port and protocol information, if required. No changes are required to PFKEY, - and if I understood correct, also IKE allows passing this information in the phase 2 negotiations using the identity payloads. My understanding of the PFKEY/IKE interactions on this issue are as follows - for example, if I want to have distinct SA's used for each HTTP transaction, I can (in my implementation) specify this in the policy description. Such requirement causes my ACQUIRE's to include non-zero port and protocol for src and dst address extensions. - when the IKE receives ACQUIRE with non-zero ports, it should cause these values to appear in Identification payloads (src port goes into src identification, and dst port into dst identifaction). - similarly, if the IKE is a responder, the resulting PFKEY adds will contain non-zero ports, if identity payloads specify them. I have to confess that our implementation didn't generate the phase 2 identify payloads this way yet. Unless, someone corrects me soon, I assume the above interpretation is correct and everyone is doing this the same way. Testing this connection specific SA setup has been mostly ignored by us, as there doesn't appear to be a ways to really test it against other implementations (do Kame IPSEC or Freeswan support such policy selectors yet?). Anyone have a web server on IPSEC host and a policy that negotiates SA's for every transaction? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Apr 6 03:17: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 DAA25529; Thu, 6 Apr 2000 03:17:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA12883 Thu, 6 Apr 2000 04:48:53 -0400 (EDT) Message-Id: <01BF9FD3.9F963380.ruheenar@future.futsoft.com> From: Ruheena R Reply-To: "ruheenar@future.futsoft.com" To: "'Markku Savela'" , "ruheenar@kailash.future.futsoft.com" Cc: "dharkins@network-alchemy.com" , "carrel@ipsec.org" , "ipsec@lists.tislabs.com" Subject: RE: Query -IPsec SA negotiation Date: Thu, 6 Apr 2000 14:23:04 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Well, I would like to know whether any implementation exists which takes care of the condition of establishing SAs with protocol id and port? Regards Ruheena. -----Original Message----- From: Markku Savela [SMTP:msa@anise.tte.vtt.fi] Sent: Thursday, April 06, 2000 1:45 PM To: ruheenar@kailash.future.futsoft.com Cc: dharkins@network-alchemy.com; ruheenar@kailash.future.futsoft.com; carrel@ipsec.org; ipsec@lists.tislabs.com Subject: RE: Query -IPsec SA negotiation > ..., I need some more clarifications. If "ACQUIRE request" is > modified to include the fields 'protocol' and 'port', in that case, > will the other routers be able to correctly interpret the ACQUIRE > request ? First, some clarifications - ACQUIRE message is part of PFKEY, which is separate from IKE. I use use it, some others don't. - ACQUIRE message *does* include src and dst port and protocol information, if required. No changes are required to PFKEY, - and if I understood correct, also IKE allows passing this information in the phase 2 negotiations using the identity payloads. My understanding of the PFKEY/IKE interactions on this issue are as follows - for example, if I want to have distinct SA's used for each HTTP transaction, I can (in my implementation) specify this in the policy description. Such requirement causes my ACQUIRE's to include non-zero port and protocol for src and dst address extensions. - when the IKE receives ACQUIRE with non-zero ports, it should cause these values to appear in Identification payloads (src port goes into src identification, and dst port into dst identifaction). - similarly, if the IKE is a responder, the resulting PFKEY adds will contain non-zero ports, if identity payloads specify them. I have to confess that our implementation didn't generate the phase 2 identify payloads this way yet. Unless, someone corrects me soon, I assume the above interpretation is correct and everyone is doing this the same way. Testing this connection specific SA setup has been mostly ignored by us, as there doesn't appear to be a ways to really test it against other implementations (do Kame IPSEC or Freeswan support such policy selectors yet?). Anyone have a web server on IPSEC host and a policy that negotiates SA's for every transaction? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Apr 6 03:18: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 DAA25549; Thu, 6 Apr 2000 03:18:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA12935 Thu, 6 Apr 2000 05:06:57 -0400 (EDT) Message-ID: <002001bf9fa9$3b2c1f60$2dcd09c0@nig95> From: "rupesh" To: Cc: Subject: Re: Query -IPsec SA negotiation Date: Thu, 6 Apr 2000 14:49:35 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0518.4 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0518.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi SPI value will different for each & every SA . So, at outbound processing you will apply some SA having some SPI. At other end same SA will be used as SPI will be same. So, there will not be any prob using many SA for same protocol & port. Reg Rupesh MTS Cdac,Pune >Hello >Thanks for the prompt reply. Well, I need some more clarifications. >If "ACQUIRE request" is modified to include the fields 'protocol' and >'port', in that case, will the other routers be able to correctly interpret >the ACQUIRE request ? >Generally, how is the SA negotiation/establishment performed ? I mean, does >it include the port and the protocol information ? > >Regards >Ruheena. >-----Original Message----- >From: Dan Harkins [SMTP:dharkins@network-alchemy.com] >Sent: Wednesday, April 05, 2000 8:22 PM >To: Markku Savela >Cc: ruheenar@kailash.future.futsoft.com; carrel@ipsec.org; >ipsec@lists.tislabs.com >Subject: Re: Query -IPsec SA negotiation > >On Wed, 05 Apr 2000 15:55:36 +0300 you wrote >> > From: Ruheena R >> >> > If we want to establish many IPSEC SA's from the same host to the >> > particular destination depending on the transport layer protocol and >> > ports. How is it possible to negotiate different SA's with these >> > parameters. Since the rfc 2409 specifies only the destination, source >IP >> > address and security protocol type in the quick mode. It does not >offer a >> >> > field to negotiate the protocol and port . >> > >> > How can the situation be taken care? >> >> I don't know about other implementations, but at least this works for >> me: >> >> - if the policy specifies that a different protection is to be used >> depending on ports, the kernel IPSEC will generate PFKEY acquire >> message that includes the port information. >> >> - the actual IKE negotiation need not concern with the ports, we >> are just requesting to setup a new SAs with certain algorithms >> and keys (as specified in the ACQUIRE request) >> >> - on successful negotiation, IKE just loads the SA's to the kernel >> *WITH* the same port information as the original ACQUIRE had, and >> the kernel side can use the appropriate different SA's as >> dictated by the policy (as described in RFC 2401) > >That's the problem with PFKEY. The ACQUIRE message does not contain that >information and IKE therefore cannot convey the wishes of your policy onto >the other peer. > >Of course you'll say, "so what? IKE shouldn't negotiate policy" but then >how do you convey your wishes to the peer? You have policy that specifies >different protection is to be applied depending on ports. What if the >other guy doesn't? He will start sending you traffic that he thinks is >completely legitimate to send (since he just negotiated two SAs without >any constraints) and you will drop because it is not. In a perfect world >this would not happen since everyone would automagically know what everyone >else's policy restrictions are; this is not a perfect world. > >The way to convey port and protocol information in an IKE exchange is >using the ID payloads as defined in RFC2407. The way to get that >information >to IKE is to modify your PFKEY so it is, unfortunately, not RFC2367 >compliant anymore. Or not use PFKEY. > > Dan. From owner-ipsec@lists.tislabs.com Thu Apr 6 03:32: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 DAA26337; Thu, 6 Apr 2000 03:32:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA13015 Thu, 6 Apr 2000 05:17:08 -0400 (EDT) Message-Id: <200004060923.FAA24628@adk.gr> X-Mailer: exmh version 2.0.2 2/24/98 To: Claudio Lordello , ".IPSec-IETF" Subject: Re: FQDN as phase 2 identity Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Apr 2000 05:23:34 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Claudio Lordello writes: > > (Sorry for the re-post. It got corrupted the first time) > > Hi, > > I have a question about the use of FQDN or User FQDN identity types for a > phase 2 SA negotiation: What are the imposed requirements (i.e. MUST's on the RFC's) on how to translate such FQDNs into its respective phase 2 > selectors, if any? I would also appreciate to hear how other vendors are > doing it. DNS lookups? I don't think you're supposed to use FQDN/UFQDN in Phase 2 IDs; these were meant for Phase 1 IDs. I didn't see anything to that effect in the RFC, but I recall that was a decision reached at some interop workshop by the attendees. -Angelos From owner-ipsec@lists.tislabs.com Thu Apr 6 04:55: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 EAA29797; Thu, 6 Apr 2000 04:55:48 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA13313 Thu, 6 Apr 2000 06:47:03 -0400 (EDT) Message-ID: <38EC5EE5.35E1C6E9@zopps.fi> Date: Thu, 06 Apr 2000 12:54:45 +0300 From: Jari Arkko Reply-To: jarkko@zopps.fi Organization: None X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins Cc: Markku Savela , ruheenar@future.futsoft.com, carrel@ipsec.org, ipsec@lists.tislabs.com Subject: Re: Query -IPsec SA negotiation References: <200004051452.HAA19862@potassium.network-alchemy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: > That's the problem with PFKEY. The ACQUIRE message does not contain that > information and IKE therefore cannot convey the wishes of your policy onto > the other peer. > > The way to convey port and protocol information in an IKE exchange is > using the ID payloads as defined in RFC2407. The way to get that information > to IKE is to modify your PFKEY so it is, unfortunately, not RFC2367 > compliant anymore. Or not use PFKEY. While the discussion is on the subject of PF_KEY, I might note that we have defined an extended/different version of PF_KEY which enables the passing of certain important policy information between IPsec and IKE, as well as allows IKE to make intelligent SA proposal selection decisions for incoming connections. If anybody's interested in defining a standards-based PF_KEY++ or at least a new informational RFC, we'd be interested in such work. Jari Arkko Ericsson From owner-ipsec@lists.tislabs.com Thu Apr 6 06:45: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 GAA01706; Thu, 6 Apr 2000 06:45:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13719 Thu, 6 Apr 2000 08:36:24 -0400 (EDT) Date: Thu, 6 Apr 2000 15:43:05 +0300 (EET DST) From: Markku Savela Message-Id: <200004061243.PAA08982@anise.tte.vtt.fi> To: ipsec@lists.tislabs.com Subject: Proxies and IKE Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Speaking about IKE, I have been wondering about the following in IKE, caused by the fact that IKE assumes symmetric SA's and have to "guess" the parameters of the other SA from the other. Assuming following setup with B and C being security gateways. A_1 --| |-- D_1 |--- B ====== C ---| A_2 --| |-- D_2 and then for a packet A_1 -> D_1 the following SA (from B -> C) needs to be negotiated proxy=A_1, src=B, dst=C Thus IKE at B initiates a negotiation with C. And now, my problem.... IKE negotiates symmetric SA's. How is the responding IKE on C supposed to guess from this information (A_1,B,C) that the SA going from C to A must have proxy=D_1, src=C, dst=B??? e.g. the problem is that the final destination D_1 does not appear anywhere in the negotiations or does it? If D_1 does appear somewhere, can anyone point this payload to me? Or, are the source and destination identity payloads containing now addresses of A_1 and D_1? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Apr 6 06:49: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 GAA01775; Thu, 6 Apr 2000 06:49:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13664 Thu, 6 Apr 2000 08:25:41 -0400 (EDT) Date: Thu, 6 Apr 2000 15:32:07 +0300 (EET DST) From: Markku Savela Message-Id: <200004061232.PAA08924@anise.tte.vtt.fi> To: niklas@appli.se CC: jarkko@zopps.fi, dharkins@network-alchemy.com, ruheenar@future.futsoft.com, carrel@ipsec.org, ipsec@lists.tislabs.com, pf_key@inner.net In-reply-to: <200004061159.NAA32292@waldorf.appli.se> (message from Niklas Hallqvist on Thu, 06 Apr 2000 13:59:31 +0200) Subject: Re: Query -IPsec SA negotiation Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > We are a couplo of others who have done just that. Like KAME, > FreeS/WAN and OpenBSD. Everyone does it a little bit different, but > we have a consensus in wanting to standardize it. We thought of > bringing this to the pfkey list, pf_key@inner.net. If you have a > proposal ready, feel free to submit it. We are many that want to see > convergence. I would still prefer simpler IKE, that would not require these changes. As far as IPSEC RFC-2401 is concerned, *everything* in it can be supported with the existing PFKEY interface, if IKE only negotiated one directional SA for an ACQUIRE and didn't concern with anything else. This is an old fight. To pre-empt responses, that "Pfkey is just internal API and informal RFC". The reason I like my approach, is that it produces cleaner key negotiation. It is definitely *NOT* derived from the PFKEY requirements, which in my opinion, just happens to be perfect for the purpose. I would prefer simple IKE, regardless of existence of PFKEY. But, yes current IKE that wants to make policy decisions, needs additional information from PFKEY and I suppose, some discussion about them is a good move. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Apr 6 06:59:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02123; Thu, 6 Apr 2000 06:59:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13789 Thu, 6 Apr 2000 08:58:14 -0400 (EDT) Date: Thu, 6 Apr 2000 22:03:55 +0900 (JST) From: Shoichi Sakane Message-Id: <200004061303.WAA43120@tanu.tanu.org> To: jarkko@zopps.fi Cc: dharkins@network-alchemy.com, msa@hemuli.tte.vtt.fi, ruheenar@future.futsoft.com, carrel@ipsec.org, ipsec@lists.tislabs.com Subject: Re: Query -IPsec SA negotiation In-Reply-To: Your message of "Thu, 06 Apr 2000 12:54:45 +0300" <38EC5EE5.35E1C6E9@zopps.fi> References: <38EC5EE5.35E1C6E9@zopps.fi> X-Mailer: Cue version 0.6 (000307-2340/sakane) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > While the discussion is on the subject of PF_KEY, I might note that we have defined > an extended/different version of PF_KEY which enables the passing of certain > important policy information between IPsec and IKE, as well as allows IKE to > make intelligent SA proposal selection decisions for incoming connections. > If anybody's interested in defining a standards-based PF_KEY++ or at least > a new informational RFC, we'd be interested in such work. In current of KAME implementaion, ACQUIRE message has policy identifier. When IKE daemon receives ACQUIRE message from kernel, IKE daemon will get a policy which triggered to acquire SA(s). A policy has source address and port, also destination's and upper layer protocol. IKE daemon can send these parameter included ID payload. /Shoichi `NE' Sakane @ KAME project/ From owner-ipsec@lists.tislabs.com Thu Apr 6 07:07:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02343; Thu, 6 Apr 2000 07:07:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13813 Thu, 6 Apr 2000 09:01:27 -0400 (EDT) Message-ID: <013801bf9fc9$a41adcd0$d1d77018@cr592232-a.flfrd1.on.wave.home.com> Reply-To: "Claudio Lordello" From: "Claudio Lordello" To: "Claudio Lordello" , ".IPSec-IETF" , "Angelos D. Keromytis" Subject: Re: FQDN as phase 2 identity Date: Thu, 6 Apr 2000 09:11:37 -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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks for the answer. I also couldn't find any constraints regarding their use for phase 2 IDs in the RFC's. The next question is: is there a reference for such decisions taken by workshop attendees? I had a quick run through the list archive and all I could find on this regard was a message by Dan Harkins (15Jun99) about bakeoff issues where he states "But the IKE and DOI authors agreed to include some text in their respective documents that clarified which identities are valid when". Did that happen? Where is the "son of IKE"? Claudio. > >In message s.ca>, Claudio Lordello writes: >> >> (Sorry for the re-post. It got corrupted the first time) >> >> Hi, >> >> I have a question about the use of FQDN or User FQDN identity types for a >> phase 2 SA negotiation: What are the imposed requirements (i.e. MUST's on > the RFC's) on how to translate such FQDNs into its respective phase 2 >> selectors, if any? I would also appreciate to hear how other vendors are >> doing it. DNS lookups? > >I don't think you're supposed to use FQDN/UFQDN in Phase 2 IDs; these were >meant for Phase 1 IDs. I didn't see anything to that effect in the RFC, but >I recall that was a decision reached at some interop workshop by the attendees. >-Angelos > > From owner-ipsec@lists.tislabs.com Thu Apr 6 07:08:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02356; Thu, 6 Apr 2000 07:08:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13871 Thu, 6 Apr 2000 09:07:36 -0400 (EDT) Message-Id: <200004061159.NAA32292@waldorf.appli.se> To: jarkko@zopps.fi cc: Dan Harkins , Markku Savela , ruheenar@future.futsoft.com, carrel@ipsec.org, ipsec@lists.tislabs.com, pf_key@inner.net Subject: Re: Query -IPsec SA negotiation In-reply-to: Your message of "Thu, 06 Apr 2000 12:54:45 +0300." <38EC5EE5.35E1C6E9@zopps.fi> Date: Thu, 06 Apr 2000 13:59:31 +0200 From: Niklas Hallqvist Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Date: Thu, 06 Apr 2000 12:54:45 +0300 > From: Jari Arkko > > While the discussion is on the subject of PF_KEY, I might note that we have defined > an extended/different version of PF_KEY which enables the passing of certain > important policy information between IPsec and IKE, as well as allows IKE to > make intelligent SA proposal selection decisions for incoming connections. > If anybody's interested in defining a standards-based PF_KEY++ or at least > a new informational RFC, we'd be interested in such work. We are a couplo of others who have done just that. Like KAME, FreeS/WAN and OpenBSD. Everyone does it a little bit different, but we have a consensus in wanting to standardize it. We thought of bringing this to the pfkey list, pf_key@inner.net. If you have a proposal ready, feel free to submit it. We are many that want to see convergence. Niklas From owner-ipsec@lists.tislabs.com Thu Apr 6 07:09:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02389; Thu, 6 Apr 2000 07:09:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13870 Thu, 6 Apr 2000 09:07:36 -0400 (EDT) Reply-To: From: "Sankar Ramamoorthi" To: "'Jan Vilhuber'" , "'sankarramamoorthi'" Cc: Subject: RE: Heartbeats draft Date: Wed, 5 Apr 2000 11:57:41 -0700 Message-ID: <000601bf9f30$d220ba30$881410ac@NetScreen.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >On Sat, 1 Apr 2000, sankarramamoorthi wrote: >> The sequence is as follows >> >> <----- ipsec packet >> No matching SA >> parties out of sync >> >> ------> invalid spi >> + original 8 bytes of packet >> causing this error >> The error notification message >> is sent in the clear. >> recover spi from >> error notification >> packet. Find sa >> corresponding to spi, >> protcol and peer >> address. >> If sa not found >> drop notification >> message and return. >> <------ echo on ipsec SA >> If echo reply was >> not received even after >> a few retries, the >> error notification is >> genuine - clean up the >> stale ipsec SA >> ------> echo reply on ipsec SA >> echo reply successfully >> received - therefore >> the ipsec sa is >> active. Ignore the >> error notification and >> return. >> > >This sort of scheme has already been proposed and rejected, since echo >requests may or may not be covered by the classification of the tunnel. This >is not a good scheme. > >Replace 'echo on ipsec SA' with some sort of phase 1 keepalive request and >reply (not timed, but, as you proposed above, event driven when needed), and >I could agree, but not if done over phase 2 (for more than just the reason >given above; check the archives). > I agree that inserting 'echo requests' into an ipsec sa may be cumbersome. I was assuming that if the inner ip header containing the ping packet can be addressed to the gateway and that traffic addressed to the gateway(on the inner packet) can be sent through any ipsec SA to the gateway. This is possible if we allow the gateway to implicitly match the ipsec SA selectors for all SAs (too many assumptions). As you mention the 'echo on ipsec SA' could be replaced with IKE SA, if we assume that the a IKE gateway/endpoint will always ensure IKE SA is around while there are active ipsec SAs. I did not want into the get into the old argument about 'dangling SAs'. Also if we use IKE SA's for ping, the 'echo reply' can be made to carry out the list of active spi list so that both sides can synchronize the ipsec SAs. The main intention of the proposal was to find out whether we can get away without having to invent a negotiated heartbeat protocol for peer synchronization. >I'm working on another similar proposal/idea. Once I have some things worked >out someone will post something to the list. > Looking forward to seeing it. >jan > -- -- sankar -- >Jan Vilhuber vilhuber@cisco.com >Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Thu Apr 6 10:02:09 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05003; Thu, 6 Apr 2000 10:02:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14612 Thu, 6 Apr 2000 11:26:29 -0400 (EDT) Message-ID: <029201bf9fdd$e6bae4e0$d1d77018@cr592232-a.flfrd1.on.wave.home.com> Reply-To: "Claudio Lordello" From: "Claudio Lordello" To: "Markku Savela" , Subject: Re: Proxies and IKE Date: Thu, 6 Apr 2000 11:36:39 -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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk src=C and dst=B are the SG addresses and C knows it from the phase 1 exchange. A_1 and D_1 identities are exchanged between B and C in the QM exchange as IDi and IDr respectively (if initiated by B). Have a look at the ISAKMP RFC in the ID payload description. One thing that is not clear to me either is if IDr can be "suggested" by the initiator (B in this case) or if it is completely up to C's local policies. Claudio Lordello. >Speaking about IKE, I have been wondering about the following in IKE, >caused by the fact that IKE assumes symmetric SA's and have to "guess" >the parameters of the other SA from the other. > >Assuming following setup with B and C being security gateways. > > A_1 --| |-- D_1 > |--- B ====== C ---| > A_2 --| |-- D_2 > >and then for a packet A_1 -> D_1 the following SA (from B -> C) needs >to be negotiated > > proxy=A_1, src=B, dst=C > >Thus IKE at B initiates a negotiation with C. And now, my problem.... > > IKE negotiates symmetric SA's. How is the responding IKE on C > supposed to guess from this information (A_1,B,C) that the SA > going from C to A must have proxy=D_1, src=C, dst=B??? > > e.g. the problem is that the final destination D_1 does not > appear anywhere in the negotiations or does it? > >If D_1 does appear somewhere, can anyone point this payload to me? Or, >are the source and destination identity payloads containing now >addresses of A_1 and D_1? > >-- >Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland >Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Apr 6 11:07: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 LAA05938; Thu, 6 Apr 2000 11:07:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15085 Thu, 6 Apr 2000 12:43:15 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E372EC@eseis06nok> To: ipsec@lists.tislabs.com Subject: RE: Proxies and IKE Date: Thu, 6 Apr 2000 19:49:54 +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 But how does B know that the comunication is with D_1 if the acquire doesn't say it. Shouldn't it give 2 proxies instead of one (against the RFC). Toni Barrera -----Original Message----- From: EXT Claudio Lordello [mailto:clordello@home.com] Sent: 06. April 2000 18:37 To: Markku Savela; ipsec@lists.tislabs.com Subject: Re: Proxies and IKE src=C and dst=B are the SG addresses and C knows it from the phase 1 exchange. A_1 and D_1 identities are exchanged between B and C in the QM exchange as IDi and IDr respectively (if initiated by B). Have a look at the ISAKMP RFC in the ID payload description. One thing that is not clear to me either is if IDr can be "suggested" by the initiator (B in this case) or if it is completely up to C's local policies. Claudio Lordello. >Speaking about IKE, I have been wondering about the following in IKE, >caused by the fact that IKE assumes symmetric SA's and have to "guess" >the parameters of the other SA from the other. > >Assuming following setup with B and C being security gateways. > > A_1 --| |-- D_1 > |--- B ====== C ---| > A_2 --| |-- D_2 > >and then for a packet A_1 -> D_1 the following SA (from B -> C) needs >to be negotiated > > proxy=A_1, src=B, dst=C > >Thus IKE at B initiates a negotiation with C. And now, my problem.... > > IKE negotiates symmetric SA's. How is the responding IKE on C > supposed to guess from this information (A_1,B,C) that the SA > going from C to A must have proxy=D_1, src=C, dst=B??? > > e.g. the problem is that the final destination D_1 does not > appear anywhere in the negotiations or does it? > >If D_1 does appear somewhere, can anyone point this payload to me? Or, >are the source and destination identity payloads containing now >addresses of A_1 and D_1? > >-- >Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland >Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Apr 6 11:12: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 LAA06004; Thu, 6 Apr 2000 11:12:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA15125 Thu, 6 Apr 2000 12:59:25 -0400 (EDT) Message-Id: <4.3.2.20000406100505.00b02f00@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 06 Apr 2000 10:06:04 -0700 To: Sheela Rowles From: Paul Hoffman Subject: Re: WG Last call: draft-ietf-ipsec-isakmp-gss-auth-05.txt Cc: srowles@cisco.com (Sheela Rowles), ddp@network-alchemy.com (Derrell Piper), briansw@microsoft.com (Brian Swander), tytso@valinux.com (Theodore Tso), ipsec@lists.tislabs.com (IPSec List) In-Reply-To: <200004051858.LAA23758@sigma.cisco.com> References: <4.3.2.20000404150225.00d30d70@mail.vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:58 AM 4/5/00 -0700, Sheela Rowles wrote: >Who would make this decision - that the spec is open for change vs being >closed? Probably a meeting of minds between the authors of the document, the WG chair, and possibly the Security Area Directors. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Apr 6 14:35: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 OAA09556; Thu, 6 Apr 2000 14:35:49 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15790 Thu, 6 Apr 2000 16:14:23 -0400 (EDT) Date: Thu, 6 Apr 2000 13:20:35 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: ipsec mailling list Subject: Re: Heartbeats draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To question some basics: IP is a best effort datagram delivery protocol. Why do people expect IPSec to be more reliable than IP. Black holes can happen in IP, why do people want to solve the black hole problem in IPSec? It should be solved in IP. If feel that whatever applications are using IP should be able to handle the black hole problem, because the problem exists in IP. So, when the traffic generated by these applications is protected by IPSec, it is not different. The applications still have to deal with the black hole problem. If SA sync problem is solved (by various ways already discussed), then the IPSec black hole problem becomes the same as the IP black hole problem, because then the black holes are only created by events like the box crashing etc. When one peer crashes, then the other peer may be sending encrypted traffic without realising that it is sending stuff into a black hole. How is it any different in IP? Even IP does the same thing. People are still debating on how to solve this problem in IP (fickle BOF), so I guess, if they ever choose to solve it, and solve it, our problem will be solved too. IMHO, we should concentrate on solving the SA sync problem, because when SADs are out of sync, IPSec introduces a new kind of black hole that already does not exist in IP. All other kinds of black holes that can occur in IPSec also occur in IP, so we should not try to tackle them. I guess reliablity should be fixed in the base IP protocol if people want it in IP. The general feeling at the fickle (Fast IP Keepalives ?) BOF is that this is not an easy problem to solve, end-to-end at the IP layer. -chinna On Wed, 5 Apr 2000, Jan Vilhuber wrote: > On Wed, 5 Apr 2000, Ricky Charlet wrote: > > Jan Vilhuber wrote: > > > > > > On Wed, 5 Apr 2000, Ricky Charlet wrote: > > > > From my perspective, black-hole detection is a must for our customers > > > > and I'd rather it be interoperable than propriatary. > > > > > > > Absolutely agreed. Just don't do it in phase 2, and we can start working on > > > details, i.e. heartbeat, or request-reply notifies... > > > > > > Agreed. Actually It was your arguments previous in this thread which > > convinced me that phase 2 pings are bad. I've come around to seeing > > phase 1 hellos as the most scalable and easily implementable black hole > > detector. > > > This is basically the way we implemented our version of keepalives, except > they are timed (and expected on both ends). Internally, we've discussed a way > to do keepalives along the lines mentioned by you and previously by someone > else (don't remember the name), i.e. not heartbeats. Either end can, at any > time, send a keepalive-req, and the other end MUST reply. However the other > end may NOT make any assupmtions about when the next request comes in. > > Works both ways of course. If one end wants to do this periodically, fine. If > one end wants to do it only when it thinks it needs to, fine. Either way will > work. As long as one end doesn't expect the other to send the requests (i.e. > doesn't have a timer that tells it when to expect a request from the other > end), you have flexibility. If they are sent with the same frequency as > heartbeats would have been sent, then you've doubled the traffic and work. > True. But if you send them less frequently, and possibly only when you > suspect something is wrong, then you win. > > This is required for dial-up lines for example. It seems that it is also > necessary to scale properly, so that there's not a constant flood of > keepalives going around (still possible in this approach, of course, but not > NECESSARY). > > To be perfectly honest, I can see different applications for either one. I'm > almost convinced we need both. Not too sure. I'm rambling. > > > > > > > I think the SPI's-in-the-heartbeat thing was a nice idea, not the main > > > thrust. I can live without that IF we have *mandatory* ack'd notifies and a > > > solid INITIAL-CONTACT message (it's not authenticated, and I still have some > > > questions about the semantics in, say, routers, i.e. something that's not an > > > end-system...). > > > > > > > I'm not opposed to optional spi lists transported by the heartbeat > > packet. But I do want to be clear that SAD sychronization is a different > > problem (which is a valid work item in its own right) from black hole > > detection. It might turn out that sending spi lists around is the right > > solution for SAD sychronization, or maybe there are other approaches to > > it which are better. I don't have strong opinions there (or even weak > > ones :-). But I am trying to gather consensus that black hole detection > > is the problem which heartbeats address. > > > Fair enough. I don't mind the SPI-list thing as an added bonus, though. I > sort of feel (but have no logical argument for it) that more is better in > this problem-space, i.e. if we have two things that help with SAD > synchronisation (and help in error checking themselves), so much the better > (as long as it doesn't add undue complexity, which I don't feel Andrew's SPI > list does; I'm just not sure how they fly with randomized SPI's, though, > which I thought SPI's should be, but I could be wrong). Robustness is good! > It sells more ipsec, if it's stable, which makes me happy if the stock price > goes up, but makes me even MORE happy as it proliferates strong crypto. > > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 > > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Thu Apr 6 16: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 QAA11144; Thu, 6 Apr 2000 16:32:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16289 Thu, 6 Apr 2000 18:25:23 -0400 (EDT) Message-ID: <38ED10DB.638C8DAB@redcreek.com> Date: Thu, 06 Apr 2000 15:34:03 -0700 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.0.34 i686) X-Accept-Language: en MIME-Version: 1.0 To: "CHINNA N.R. PELLACURU" CC: ipsec mailling list Subject: Re: Heartbeats draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some excellent questions Chinna. My answers are interspersed: "CHINNA N.R. PELLACURU" wrote: > > To question some basics: > > IP is a best effort datagram delivery protocol. Why do people expect IPSec > to be more reliable than IP. Black holes can happen in IP, why do people > want to solve the black hole problem in IPSec? It should be solved in IP. > A complimentary pair of IPsec SAs very nearly aproximate the analogy of a link layer connection to IP. Routing protocols need to know ( within seconds ) when their links go down. General IP WANs are often build with some redundancy in mind so that when a link goes down, the routing protocol has alternate paths to choose from. If we want to complete the analogy of an IPsec tunnel (a pair of complementary IPsec SAs) forming a link layer connection, then we need the capability to mark the tunnel with the states of a link, ie up, down, testing, notPresent, lowerLayerDown, dormant, and unknown. > If feel that whatever applications are using IP should be able to handle > the black hole problem, because the problem exists in IP. So, when the > traffic generated by these applications is protected by IPSec, it is not > different. The applications still have to deal with the black hole > problem. A black hole problem in IP is usually the result of a misconfiguration of or a bug in a routing protocol. It SHOULD be avoidable. The black hole problem in IPsec is unavoidable when a peer becomes unreachable. I feel we should take action to amend that situation. > > If SA sync problem is solved (by various ways already discussed), then the > IPSec black hole problem becomes the same as the IP black hole problem, > because then the black holes are only created by events like the box > crashing etc. When one peer crashes, then the other peer may be sending > encrypted traffic without realising that it is sending stuff into a black > hole. How is it any different in IP? Even IP does the same thing. In IP, a black hole is not guarenteed to result if a router crashes. Actually, wise network implementors make sure to deploy and configure their networks in such a way that any single point of failure is recoverable. And recovering from any single point of failure is really pretty easy. However, in an IPsec tunnel, a black-hole is guarenteed to result if a SGW goes down. The IPsec architecture document requires that your selectors be searched in adminstrative order and the first match found be used. No reguard was given as to wether or not the peer is currently reachable. In order to take any sensible recovery action (like send back an ICMP unreachable to the traffic source or attempt to form an SA with a backup SGW) you must be able to detect if your peer is currently reachable. > > People are still debating on how to solve this problem in IP (fickle BOF), > so I guess, if they ever choose to solve it, and solve it, our problem > will be solved too. Personally, I found the fickle BOF disapointing for IPsec purposes. Their approach is very lan centric and tuned to discovery within tens of milliseconds. The eventual result of their work will certianly be a new IP packet type which is source and dest addressed to the gatways or IANA registered multicast addresses. It would just about have to be carried in Phase2 SAs as encapsulated by IPsec. And that would lead to configuration difficulties and/or loading up extra exception processing in the optimized packet forwarding path. I think using some type of new notify in Phase1 SAs is our most scalable bet. > > IMHO, we should concentrate on solving the SA sync problem, because when > SADs are out of sync, IPSec introduces a new kind of black hole that > already does not exist in IP. All other kinds of black holes that can > occur in IPSec also occur in IP, so we should not try to tackle them. I > guess reliablity should be fixed in the base IP protocol if people want it > in IP. The general feeling at the fickle (Fast IP Keepalives ?) BOF is > that this is not an easy problem to solve, end-to-end at the IP layer. Now that is a very good point. If I reword it just to make sure that I understand something, I would say: If your SADs are guarenteed to be sychronized *even in the event that a peer becomes unreachable*, then we would not need to solve dead peer detection as a stand alone problem because your SAD would be updated if the peer does become unreable. I'm certianly willing to listen to proposals about how to do that. I don't think that ack'd notifies go that far. As best as I can see right now, we will always seem to need some type of periodic "are you still there" message. But I'd love to hear alternatives. -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Thu Apr 6 20:13: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 UAA01016; Thu, 6 Apr 2000 20:13:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA16857 Thu, 6 Apr 2000 21:57:45 -0400 (EDT) Date: Thu, 6 Apr 2000 19:03:58 -0700 (PDT) From: "CHINNA N.R. PELLACURU" To: Ricky Charlet cc: ipsec mailling list Subject: Re: Heartbeats draft In-Reply-To: <38ED10DB.638C8DAB@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you run heartbeats between the end-host to a security gateway, then it only helps you with knowing the reachability between the end-host to the security gateway. That's only solving half the problem, because if the link/route between the security gateway and the true destination of the traffic is down, and you still have a black hole. Even if you have another security gateway that can handle traffic to actual destination, the heartbeat protocol won't help you in this situation. Heartbeats are not very useful on Dial-on-Demand links. I am not sure how we can do conditional echo-reply kind of messages, because, what are the trigger points for such echo-replys. If you say, we are going to do an echo-reply only if we suspect that there is a black hole, then what makes you suspect that there is a black hole? I guess that intellegence is not available in the IP layer. Even Mobile IP has the same problem. They have tunnels between Home Agent, and the Foriegn Agent. How does an FA know whether the HA is up or it is just tunnelling into a black hole? So, I guess, this problem, may be generic to all IP tunneling protocols, if not for IP itself. If you are going to treat a tunnel as a link layer connection, then I guess what you are suggesting is that we should simulate link behaviour, and interact with the routing protocols like a link would do. This is the perfect argument to do hellos on IPSec SAs/tunnels. So, an IPSec tunnel should be treated as another interface in the system. This may not be very easy to do, because interfaces are at the granularity of IP addresses, and tunnels are at a much finer granularity. And this approach is not going to scale. How many interfaces do you expect a system to handle? In the case of end systems, where there is no routing capabilities, what you are suggesting is put the routing functionality into IPSec, where IPSec makes routing decisions on which tunnel (link) to use. That is why I feel that stateful redundacy on the server side is a better way to deal with this, and this is best done in an implementation specific way. -chinna On Thu, 6 Apr 2000, Ricky Charlet wrote: > Some excellent questions Chinna. My answers are interspersed: > > > "CHINNA N.R. PELLACURU" wrote: > > > > To question some basics: > > > > IP is a best effort datagram delivery protocol. Why do people expect IPSec > > to be more reliable than IP. Black holes can happen in IP, why do people > > want to solve the black hole problem in IPSec? It should be solved in IP. > > > > A complimentary pair of IPsec SAs very nearly aproximate the analogy of > a link layer connection to IP. Routing protocols need to know ( within > seconds ) when their links go down. General IP WANs are often build with > some redundancy in mind so that when a link goes down, the routing > protocol has alternate paths to choose from. If we want to complete the > analogy of an IPsec tunnel (a pair of complementary IPsec SAs) forming a > link layer connection, then we need the capability to mark the tunnel > with the states of a link, ie up, down, testing, notPresent, > lowerLayerDown, dormant, and unknown. > > > > If feel that whatever applications are using IP should be able to handle > > the black hole problem, because the problem exists in IP. So, when the > > traffic generated by these applications is protected by IPSec, it is not > > different. The applications still have to deal with the black hole > > problem. > > A black hole problem in IP is usually the result of a misconfiguration > of or a bug in a routing protocol. It SHOULD be avoidable. The black > hole problem in IPsec is unavoidable when a peer becomes unreachable. I > feel we should take action to amend that situation. > > > > > > If SA sync problem is solved (by various ways already discussed), then the > > IPSec black hole problem becomes the same as the IP black hole problem, > > because then the black holes are only created by events like the box > > crashing etc. When one peer crashes, then the other peer may be sending > > encrypted traffic without realising that it is sending stuff into a black > > hole. How is it any different in IP? Even IP does the same thing. > > In IP, a black hole is not guarenteed to result if a router crashes. > Actually, wise network implementors make sure to deploy and configure > their networks in such a way that any single point of failure is > recoverable. And recovering from any single point of failure is really > pretty easy. > However, in an IPsec tunnel, a black-hole is guarenteed to result if a > SGW goes down. The IPsec architecture document requires that your > selectors be searched in adminstrative order and the first match found > be used. No reguard was given as to wether or not the peer is currently > reachable. In order to take any sensible recovery action (like send back > an ICMP unreachable to the traffic source or attempt to form an SA with > a backup SGW) you must be able to detect if your peer is currently > reachable. > > > > > People are still debating on how to solve this problem in IP (fickle BOF), > > so I guess, if they ever choose to solve it, and solve it, our problem > > will be solved too. > > Personally, I found the fickle BOF disapointing for IPsec purposes. > Their approach is very lan centric and tuned to discovery within tens of > milliseconds. The eventual result of their work will certianly be a new > IP packet type which is source and dest addressed to the gatways or IANA > registered multicast addresses. It would just about have to be carried > in Phase2 SAs as encapsulated by IPsec. And that would lead to > configuration difficulties and/or loading up extra exception processing > in the optimized packet forwarding path. > I think using some type of new notify in Phase1 SAs is our most > scalable bet. > > > > > > IMHO, we should concentrate on solving the SA sync problem, because when > > SADs are out of sync, IPSec introduces a new kind of black hole that > > already does not exist in IP. All other kinds of black holes that can > > occur in IPSec also occur in IP, so we should not try to tackle them. I > > guess reliablity should be fixed in the base IP protocol if people want it > > in IP. The general feeling at the fickle (Fast IP Keepalives ?) BOF is > > that this is not an easy problem to solve, end-to-end at the IP layer. > > Now that is a very good point. If I reword it just to make sure that I > understand something, I would say: > > If your SADs are guarenteed to be sychronized *even in the event that > a peer becomes unreachable*, then we would not need to solve dead peer > detection as a stand alone problem because your SAD would be updated if > the peer does become unreable. > > I'm certianly willing to listen to proposals about how to do that. I > don't think that ack'd notifies go that far. As best as I can see right > now, we will always seem to need some type of periodic "are you still > there" message. But I'd love to hear alternatives. > > -- > Ricky Charlet : Redcreek Communications : usa (510) 795-6903 > chinna narasimha reddy pellacuru s/w engineer From owner-ipsec@lists.tislabs.com Fri Apr 7 05:42: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 FAA02681; Fri, 7 Apr 2000 05:42:38 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA19581 Fri, 7 Apr 2000 07:22:03 -0400 (EDT) Message-ID: <38EDB7C0.734B1587@zopps.fi> Date: Fri, 07 Apr 2000 13:26:08 +0300 From: Jari Arkko Reply-To: jarkko@zopps.fi Organization: None X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: Niklas Hallqvist , Markku Savela Cc: Dan Harkins , ruheenar@future.futsoft.com, carrel@ipsec.org, ipsec@lists.tislabs.com, pf_key@inner.net Subject: Re: Query -IPsec SA negotiation References: <200004061159.NAA32292@waldorf.appli.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Niklas Hallqvist wrote: > we have a consensus in wanting to standardize it. We thought of > bringing this to the pfkey list, pf_key@inner.net. If you have a > proposal ready, feel free to submit it. We are many that want to see > convergence. I actually do have a proposal and could post it next week when I get back from the bushes of Australia. That proposal is of course just our own with a particular set of objectives and a particular division of policy handling between IPsec and IKE. With some input from the rest of the people who have done this, it would be interesting to see if the objectives and/or solutions are similar or if they diverge. At the very least there needs to be a lot of discussion to get something everybody could agree on... [I'm not sure yet if the extensions various groups have done are actually at all the same thing. Some groups seem to have defined mechanisms for e.g. downloading policy information to a kernel-resident IPSec module from a configuration tool. I've been concerned with IKE-IPSec communication myself for the moment at least.] Markku Savela wrote: >I would still prefer simpler IKE, that would not require these >changes. As far as IPSEC RFC-2401 is concerned, *everything* in it can >be supported with the existing PFKEY interface, if IKE only negotiated >one directional SA for an ACQUIRE and didn't concern with anything >else. Hm, I have trouble seeing how. Care to explain? One of the problems I see is supporting incoming connection requests; PFKEY has *no* way of asking IPsec to make a decision between proposals P1, P2, ... and Pn if the other side is sending us several alternative protection schemes. Now, I understand that many implementations handle this by having some sort of default policy for incoming connections at the IKE level. Personally, I find this insufficient. I need to specify different protection for different traffic, and duplicating such policy information in IKE when it clearly already exists in IPsec side would be bad design. And I don't think IPsec can sort the issue out afterwards in a satisfactory manner if IKE has already made a decision and informed the other side about it. Anyway, perhaps the point is moot. IKE is a widely implemented standard, and everybody's boxes need to talk to other boxes. Changing it to allow a less widely used internal protocol to go unchanged doesn't sound very promising. Jari From owner-ipsec@lists.tislabs.com Fri Apr 7 05:50:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02788; Fri, 7 Apr 2000 05:50:07 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA19639 Fri, 7 Apr 2000 07:44:15 -0400 (EDT) Message-ID: <38EDBD03.92DFEF7@zopps.fi> Date: Fri, 07 Apr 2000 13:48:35 +0300 From: Jari Arkko Reply-To: jarkko@zopps.fi Organization: None X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: antonio.barrera@nokia.com, clordello@home.com Cc: ipsec@lists.tislabs.com Subject: Re: Proxies and IKE References: <0B3F42CA1FB6D2118FE50008C7894B0A02E372EC@eseis06nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk clordello@home.com wrote: >ISAKMP RFC in the ID payload description. One thing that is not clear to me >either is if IDr can be "suggested" by the initiator (B in this case) or if >it is completely up to C's local policies. Section 5.5, RFC 2409: The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode. If ISAKMP is acting as a client negotiator on behalf of another party, the identities of the parties MUST be passed as IDci and then IDcr. Local policy will dictate whether the proposals are acceptable for the identities specified. If the client identities are not acceptable to the Quick Mode responder (due to policy or other reasons), a Notify payload with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. To me, this says that the initiator specifies the identities and the responder can't change them, only complain... hence the identities coming back on the second message of QM should be the same. antonio.barrera@nokia.com wrote: > > But how does B know that the comunication is with D_1 if the acquire > doesn't say it. > Shouldn't it give 2 proxies instead of one (against the RFC). It is pretty clear that when initiating a new connection, IPsec/IKE must come up with the following information: - Own gateway identity (IDi=B) - Peer gateway identity (IDr=C) [these two are used to find an existing ISAKMP SA or used to establish a new one] - Client identity (IDci=A_1) - Peer client identity (IDcr=D_1) [these two are the information that is matched against the IPsec policies] Note that RFC 2409 allows leaving out the identies, in which case they default to the gateway identities with no ports or protocols. Now, the PF_KEY documentation is very unclear with respect to the use of the identities and the role of the proxy parameter. But, the above information must get through, no matter what. Jari From owner-ipsec@lists.tislabs.com Fri Apr 7 06: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 GAA03032; Fri, 7 Apr 2000 06:05:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19681 Fri, 7 Apr 2000 08:01:19 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E372F3@eseis06nok> To: ipsec@lists.tislabs.com Subject: RE: Proxies and IKE Date: Fri, 7 Apr 2000 15:04:42 +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 >It is pretty clear that when initiating a new connection, IPsec/IKE must come up with >the following information: > > - Own gateway identity (IDi=B) > - Peer gateway identity (IDr=C) [these two are used to find an existing > ISAKMP SA or used to establish a new one] > - Client identity (IDci=A_1) > - Peer client identity (IDcr=D_1) [these two are the information that is matched > against the IPsec policies] > >Note that RFC 2409 allows leaving out the identies, in which case they default to >the gateway identities with no ports or protocols. > >Now, the PF_KEY documentation is very unclear with respect to the use of the identities >and the role of the proxy parameter. But, the above information must get through, >no matter what. ----- That's what I was asking. The Pfekey is only prepared to supply 3 of these 4 addresses. Hence, the problem I'm commenting here. In theory the Acquire should supply the addresses - Own gateway identity (IDi=B) - Peer gateway identity (IDr=C) [these two are used to find an existing ISAKMP SA or used to establish a new one] - Client identity (IDci=A_1) But that's not enough so what I think is that it should supply C, A_1 and D_1. Because B is alreay known as it's the gateway own address. Then the use of the SRC, DST and PROXY payloads in PFKEY should be different than specified in the RFC (unless I misunderstood them of course!) Toni From owner-ipsec@lists.tislabs.com Fri Apr 7 12:10:02 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11400; Fri, 7 Apr 2000 12:10:02 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21082 Fri, 7 Apr 2000 13:49:17 -0400 (EDT) Message-ID: Date: Wed, 31 Dec 1969 16:00:00 +0000 From: sankarramamoorthi X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: pcn@cisco.com CC: ipsec@lists.tislabs.com Subject: Re: Heartbeats draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Heartbeats are not very useful on Dial-on-Demand links. I am not sure how > we can do conditional echo-reply kind of messages, because, what are the > trigger points for such echo-replys. If you say, we are going to do an > echo-reply only if we suspect that there is a black hole, then what makes > you suspect that there is a black hole? I guess that intellegence is not > available in the IP layer. I believe IP layer does provide mechanisms to detect blackhole. If the destination is down, should'nt the initiator get an ICMP error 'Host Unreachable'? From RFC 1009 The ICMP Destination Unreachable message is sent by a gateway in response to a datagram which it cannot forward because the destination is unreachable or down. The gateway chooses one of the following two types of Destination Unreachable messages to send: * Net Unreachable * Host Unreachable A 'Host Unreachable' or 'Net Unreachable' error should indicate the possiblity of a blackhole. I know icmp messages are quite often blocked by firewalls either by misconfiguration or intention, but this is not the fault of IP framework. Am I missing something here? I agree that if ICMP messages drop into a blackhole, there is no way detect the existence of a blackhole short of a heartbeat/inactivity timer. The other possiblity for a blackhole is that the host specified by the destination address of the ipsec/IKE packet is up but either the IKE or ipsec state machine has gone out of sync. This case is out of scope of the IP framework. In this case, error notifications from IKE/IPSec should be good indicators of a possible blackhole. Thanks, -- sankar -- From owner-ipsec@lists.tislabs.com Fri Apr 7 13:18:20 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12361; Fri, 7 Apr 2000 13:18:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21496 Fri, 7 Apr 2000 15:09:11 -0400 (EDT) Date: Fri, 7 Apr 2000 15:15:52 -0400 Message-Id: <200004071915.PAA21973@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: sanka2g@worldnet.att.net Cc: pcn@cisco.com, ipsec@lists.tislabs.com Subject: Re: Heartbeats draft References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "sankarramamoorthi" == sankarramamoorthi writes: >> Heartbeats are not very useful on Dial-on-Demand links. I am not >> sure sankarramamoorthi> how >> we can do conditional echo-reply kind of messages, because, what >> are sankarramamoorthi> the >> trigger points for such echo-replys. If you say, we are going to >> do an >> echo-reply only if we suspect that there is a black hole, then >> what sankarramamoorthi> makes >> you suspect that there is a black hole? I guess that intellegence >> is sankarramamoorthi> not >> available in the IP layer. sankarramamoorthi> I believe IP layer does provide mechanisms to sankarramamoorthi> detect blackhole. If the destination is down, sankarramamoorthi> should'nt the initiator get an ICMP error 'Host sankarramamoorthi> Unreachable'? I'm a bit puzzled by the way this discussion is going. The issue with black holes isn't necessarily that they are undetectable. Routing protocols certainly will notice that a path is out of service, and take action. That assumes you're running a dynamic routing protocol over the tunnel and the routing protocol in question has a suitable "hello" type of protocol. ICMP, on the other hand, is not part of the solution. The problem is that one end thinks a tunnel is up while the other end has it down (or non-existent). If the side that shows tthe tunnel state as up has a packet to send, it will send it; no ICMP will result since it believes the destination to be reachable. But it doesn't actually get to its destination. Even if you could detect the failure of the path, that's only part of the problem. You need a mechanism to *repair* the problem in a reasonable amount of time. Specifically, in less time than it takes the customer to get annoyed enough to call support and demand a service person to be dispatched on site. :-) This is why dynamic routing itself isn't a solution either. While that will route around the fault *if* there is another route, it doesn't make the fault go away. Making the fault go away is the missing piece. paul From owner-ipsec@lists.tislabs.com Sun Apr 9 13:26: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 NAA03816; Sun, 9 Apr 2000 13:26:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA27528 Sun, 9 Apr 2000 14:45:11 -0400 (EDT) Date: Sun, 9 Apr 2000 14:51:04 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Heartbeats draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 31 Dec 1969, sankarramamoorthi wrote: > I believe IP layer does provide mechanisms to detect blackhole. > If the destination is down, should'nt the initiator get an ICMP error > 'Host Unreachable'? Perhaps. That's not a mechanism for *detecting* black holes, it's a mechanism for alerting others to their presence, *after* they are detected. Detecting them remains a problem in many cases. Gateways do not always know whether the hosts they serve are up or down. As others have noted, also, no IP-level mechanism is entirely adequate for this job. If a host crashes and quickly reboots, its downtime may never be noticed... but it has probably forgotten all its tunnels. Continued IPSec connectivity ultimately must be determined at the IPSec level, although warnings from lower levels might be useful *hints* that it is time to do a connectivity test. > The other possiblity for a blackhole is that the host specified by the > destination address of the ipsec/IKE packet is up but either the > IKE or ipsec state machine has gone out of sync. This case is out of > scope of the IP framework. In this case, error notifications from > IKE/IPSec should be good indicators of a possible blackhole. Many types of IKE/IPSec errors do not result in notifications, partly because of the possibility for denial-of-service attacks. If the two ends have lost synchronization, there is no easy way to supply strong authentication for such notifications... so how can they be trusted? Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Apr 10 09:27: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 JAA17362; Mon, 10 Apr 2000 09:27:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00341 Mon, 10 Apr 2000 10:48:40 -0400 (EDT) Message-ID: <38EE4B74.95FCB0AE@worldnet.att.net> Date: Fri, 07 Apr 2000 13:56:21 -0700 From: sankarramamoorthi X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: pcn@cisco.com, ipsec@lists.tislabs.com Subject: Re: Heartbeats draft References: <200004071915.PAA21973@tonga.xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning wrote: > >>>>> "sankarramamoorthi" == sankarramamoorthi writes: > > >> Heartbeats are not very useful on Dial-on-Demand links. I am not > >> sure > sankarramamoorthi> how > >> we can do conditional echo-reply kind of messages, because, what > >> are > sankarramamoorthi> the > >> trigger points for such echo-replys. If you say, we are going to > >> do an > > >> echo-reply only if we suspect that there is a black hole, then > >> what > sankarramamoorthi> makes > >> you suspect that there is a black hole? I guess that intellegence > >> is > sankarramamoorthi> not > >> available in the IP layer. > > sankarramamoorthi> I believe IP layer does provide mechanisms to > sankarramamoorthi> detect blackhole. If the destination is down, > sankarramamoorthi> should'nt the initiator get an ICMP error 'Host > sankarramamoorthi> Unreachable'? > > I'm a bit puzzled by the way this discussion is going. > > The issue with black holes isn't necessarily that they are > undetectable. Routing protocols certainly will notice that a path is > out of service, and take action. That assumes you're running a > dynamic routing protocol over the tunnel and the routing protocol in > question has a suitable "hello" type of protocol. I agree that routing protocols will handle path failure - I was not referring to path failures or dynamic routing protocols over the tunnel. I was referring to destination (ipsec peer) failures - The failure is either at the IP level (machine has crashed and no longer reachable) or the failure is above the IP layer (state machine out of sync). My question was whether error notifications (icmp and IKE/IPSec) error notifications are sufficient to cover both cases. > > > ICMP, on the other hand, is not part of the solution. The problem is Why? Could'nt ICMP error(Host Unreachable) be an indicator that a possible blackhole exists? It cannot be the total solution because the receiving entity needs to proof itself against possible DOS attack. > > that one end thinks a tunnel is up while the other end has it down (or > non-existent). If the side that shows tthe tunnel state as up has a > packet to send, it will send it; no ICMP will result since it believes > the destination to be reachable. But it doesn't actually get to its > destination. Should'nt this result in IKE/IPSec error notifications? If IKE/IPSec modules are not loaded then should'nt this result in a suitable ICMP error (protocol unreachable)? > > > Even if you could detect the failure of the path, that's only part of > the problem. You need a mechanism to *repair* the problem in a > reasonable amount of time. Specifically, in less time than it takes > the customer to get annoyed enough to call support and demand a > service person to be dispatched on site. :-) Error notifications should help in taking corrective action in reasonable amount of time. > > > > This is why dynamic routing itself isn't a solution either. While > that will route around the fault *if* there is another route, it > doesn't make the fault go away. Making the fault go away is the > missing piece. I did not consider dynamic routing protocols at all. Thanks, -- sankar -- From owner-ipsec@lists.tislabs.com Mon Apr 10 10:00: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 KAA17961; Mon, 10 Apr 2000 10:00:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00603 Mon, 10 Apr 2000 11:46:18 -0400 (EDT) From: tcosenza@us.ibm.com X-Lotus-FromDomain: IBMUS To: ipsec@lists.tislabs.com Message-ID: <852568BD.00574026.00@d54mta07.raleigh.ibm.com> Date: Mon, 10 Apr 2000 11:52:55 -0400 Subject: IPSec and NAT Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What RFC's pertain to NAT and IPSec? Thanks Thomas Mr. Thomas Cosenza Software Eng. IBM T/L 441-8782 Outside Line 919-543-8782 "Everyone Fights, No one Quits! If you Quit I will shoot you myself!" Michael Irons in Starship Troopers From owner-ipsec@lists.tislabs.com Mon Apr 10 11:47: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 LAA20434; Mon, 10 Apr 2000 11:47:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA00999 Mon, 10 Apr 2000 13:13:16 -0400 (EDT) Message-ID: <20000410172005.9483.qmail@web906.mail.yahoo.com> Date: Mon, 10 Apr 2000 10:20:05 -0700 (PDT) From: Wen-Chi Wang Subject: Re: IPSec and NAT To: tcosenza@us.ibm.com, ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are some of RFCs that are related to IPsec, NAT and VPNs. Please try RFC 2709, 2663, 2766, 2694, 2775, 2401, 2719, 2449, 2764, 1631, 2500, 2101, 2207, 2407, 2428, 2661, 2400, 2289, 2391, and 2765. --- tcosenza@us.ibm.com wrote: > > > > > > What RFC's pertain to NAT and IPSec? > > Thanks > Thomas > > > > > Mr. Thomas Cosenza > Software Eng. IBM > T/L 441-8782 > Outside Line 919-543-8782 > "Everyone Fights, No one Quits! If you Quit I will > shoot you myself!" > Michael Irons in Starship Troopers > > > ===== Alex W. Wang Senior Network Analyst, MCSE+Internet, CCNA Sumitomo Sitix Silicon Inc. Homepage: http://members.xoom.com/alexw1970 Phone: (510) 4403314 __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-ipsec@lists.tislabs.com Mon Apr 10 12:07: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 MAA20767; Mon, 10 Apr 2000 12:07:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA01079 Mon, 10 Apr 2000 13:58:20 -0400 (EDT) Message-Id: <01BFA344.DE4F3620.venkatn@future.futsoft.com> From: Venkatesh N Reply-To: "venkatn@future.futsoft.com" To: "ipsec@lists.tislabs.com" Subject: ipsc sa transform Date: Mon, 10 Apr 2000 23:31:14 +0530 Organization: Future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 1)Is it possible to have different transform sets for the inbound and outbound SA's for the same client src and dst IP addresses. (In the quick mode a single SA negotiation results in two two SA's which necessitates both the inbound and outbound SA's to have the same transform sets.) 2)consider the the following scenario, h1 ---- r1 -----r2------h2 where all the machines are ipsec enabled, what will be the processing at r2 for a transport mode packet from h1 to h2, and r1,r2 is configured to simply pass the packets from h1 to h2. where will reassembly be performed for this packet? Venki From owner-ipsec@lists.tislabs.com Mon Apr 10 19:15: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 TAA08467; Mon, 10 Apr 2000 19:15:14 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02349 Mon, 10 Apr 2000 20:56:08 -0400 (EDT) Message-ID: <001c01bfa351$62c947e0$f50cfe81@etri.re.kr> From: =?ks_c_5601-1987?B?udq/+MHW?= To: Subject: SKIP drafts Date: Tue, 11 Apr 2000 10:00:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by lists.tislabs.com id UAA02346 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Can anyone give me drafts or documents of "SKIP(Simple Key-management for Internet Protocol)" ? maybe, Its final version is 7. (draft-ietf-ipsec-skip-07.txt) Regards, Wonjoo wjpark@earthling.net I want a perfect soul ... From owner-ipsec@lists.tislabs.com Tue Apr 11 04: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 EAA14519; Tue, 11 Apr 2000 04:56:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA04148 Tue, 11 Apr 2000 06:44:57 -0400 (EDT) Message-Id: <200004111051.GAA27765@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-dhcp-05.txt Date: Tue, 11 Apr 2000 06:51:40 -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 : DHCP Configuration of IPSEC Tunnel Mode Author(s) : B. Patel, B. Aboba, S. Kelly, V. Gupta Filename : draft-ietf-ipsec-dhcp-05.txt Pages : 13 Date : 10-Apr-00 In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a 'virtual' address from the corporate network, and then tunneling traffic via Ipsec from the host's ISP-assigned address to the corporate security gateway. The Dynamic Host Configuration Protocol (DHCP) provides for such remote host configuration. This draft explores the requirements for host configuration in IPSEC tunnel mode, and describes how the DHCP protocol may be leveraged for configuration in this case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-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-dhcp-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-dhcp-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: <20000410121824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000410121824.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Apr 11 13:01: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 NAA25684; Tue, 11 Apr 2000 13:01:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA06101 Tue, 11 Apr 2000 14:28:04 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: Subject: Re: Heartbeats draft Date: Tue, 11 Apr 2000 14:32:18 -0400 Message-Id: <000f01bfa3e4$45c3bcf0$59daa8c0@andrewktest.timestep.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I just got back from vacation and I'm swamped with mail, so I'm not going to try to answer every message on this subject. Let me just make a few general comments: Bounded Overhead --------------------------- The negotiated interval ensures that the overhead is bounded. State creation, CPU usage, and recovery time are all bounded. This gives us a few nice properties. At the meeting, we heard that some people are trying to run IPsec over high-latency, low-bandwidth devices. These connections require bandwidth to be bounded. A side-effect is that black-holes can be detected and corrected within a predictable (and configurable) time interval. This aids in meeting service-level agreements. I also wasn't sure whether we will need to eventually incorporate some kind of DDoS resistance into IKE. The design of the heartbeat protocol allows graceful degradation of service when combined with most foreseeable DDoS counter-measures. Modularity --------------------------- The heartbeat protocol is designed such that there is minimal interaction with other IPsec services running on the box. This is to reduce complexity. In particular, you don't have to trigger heartbeats based on whether there is or isn't traffic on an IPsec SA. You don't have to rely on unauthenticated notify messages to trigger an action. You don't have to apply an external resource-limitation mechanism to counteract replay. Chinna: > I have addressed the DOS risk in another mail, and I feel > that the risk > can be bounded easily. You have to deal with DOS in every > aspect of IKE, > and this is just one more place. > Probably we can be more specific(after some experimentation) > about under > what conditions we initiate, then try to analyse the risk. I > am sure it is > not very hard to come up with a simple algorithm, that can > bound the risk. > I think we can be smart about initiating, and it is not a major risk. > [etc.] If it is so easy, then please design this algorithm and post it to the list. I'm sure all of us would like to see it. In particular, I would like to see how it rates with regards to bounded-ness, analyzability and modularity. As the draft suggests, I don't have a strong objection to request-reply type heartbeats, as long as the sender can specify the minimum interval and a sequence number (or timestamp) is included for DoS detection. This will double the bandwidth in the simplest case (high modularity) but it's still insignificant in the long run. Unfortunately, DDoS resistance is reduced. Inactivity --------------------------- Inactivity timers normally apply to the pair of SAs (inbound & outbound). High level protocols may continue to send traffic on the outbound SA even if they don't receive any traffic on the inbound SA. To use inactivity as a trigger for sending request-reply heartbeats we would have to keep separate timers for inbound inactivity. Other Things --------------------------- Processing and generating the SPI list should not be a problem with random SPIs if you use a good database (i.e. one with dynamic indexing). As Paul pointed out, self-stabilization is a good thing. It is the equivalent of negative feedback in an electric circuit. I would be very wary of trusting a protocol without some kind of self-stablization. Not only is there the possibility of implementation error, but the lack of a stabilization mechanism can exacerbate existing security weaknesses. Chinna: > Firslty, the proposal is to act on an invalid SPI error > condition, and not > responding to an Invalid SPI notification. I did the analysis of this a long time ago and trust me, you do not want to base a heartbeat protocol on the reception of a message with an invalid SPI. It is okay to base a protocol on the reception of Invalid SPI notifies, but this requires that the peer always send the Invalid SPI notify. (This has sometimes been criticized as being too susceptible to DDoS.) Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. From owner-ipsec@lists.tislabs.com Wed Apr 12 03:51: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 DAA02622; Wed, 12 Apr 2000 03:51:12 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA08922 Wed, 12 Apr 2000 05:11:09 -0400 (EDT) Message-Id: <01BFA48D.AB8DBC80.ruheenar@future.futsoft.com> From: Ruheena Rashid Reply-To: "ruheenar@future.futsoft.com" To: "'Jayashree'" Cc: "'Ruheena Rashid'" , "'Venkatesh'" , "'ipsec@lists.tislabs.com'" Subject: Query : PF_KEY related Date: Wed, 12 Apr 2000 14:44:55 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello RFC 2367 states that - when IKE sends a KEY_REGISTER to IPSEC, the IPSEC replies with supported algorithms. (i) I would like to know whether this set of supported algorithms contains only the default algorithms (provided there are separate configuration for every peer, which contains the set of algorithms supported for negotiating with each peer) Or it contains the complete set of algorithms supported. (ii) Also, when a remote peer contacts IKE for negotiation, does the IKE check for the supported algorithms based on the algorithms sent in the reply to KEY_REGISTER (as mentioned above)? If this is so, then the IKE needs to be furnished with all the supported algorithms. How is this done ? (iii) Is there any existing implementation which takes care of this condition ? Regards Ruheena Rashid. From owner-ipsec@lists.tislabs.com Wed Apr 12 03:53: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 DAA02815; Wed, 12 Apr 2000 03:53:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA09028 Wed, 12 Apr 2000 05:35:21 -0400 (EDT) Message-Id: <01BFA491.13364480.ruheenar@future.futsoft.com> From: Ruheena Rashid Reply-To: "ruheenar@future.futsoft.com" To: "'Jayashree'" Cc: "'Ruheena Rashid'" , "'Venkatesh'" , "'ipsec@lists.tislabs.com'" Subject: Query - Phase 2 negotiation (RFC 2409) Date: Wed, 12 Apr 2000 15:09:17 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello I have a query regarding the negotiation of IPSEC SAs in Quick mode. RFC 2409 states that - "A single phase 1 negotiation may be used for more than one phase 2 negotiation." Does this mean that the endpoints need to be different in the subsequent phase 2 negotiations? Suppose We have hosts A and B and the tunnel endpoints X and Y, which supports both AH and ESP with x1, x2, x3 algorithms. Let us assume that already an SA has been established using AH protocol and x1 algorithm using phase 2 negotiation. I would like to know whether another SA can be established using phase 2 negotiation between the same endpoints using AH protocol and algorithm x2 ? If yes, then does this mean that there is no check performed before creating a new SA between the same endpoints and any number of SAs can exist between the 2 endpoints with the same parameters? Regards Ruheena Rashid. From owner-ipsec@lists.tislabs.com Wed Apr 12 04:35: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 EAA03800; Wed, 12 Apr 2000 04:35:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA09133 Wed, 12 Apr 2000 06:23:51 -0400 (EDT) Message-Id: <01BFA497.D517FFC0.ruheenar@future.futsoft.com> From: Ruheena Rashid Reply-To: "ruheenar@future.futsoft.com" To: "'Joern Sierwald'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: Query - Phase 2 negotiation (RFC 2409) Date: Wed, 12 Apr 2000 15:57:39 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Thanks for your reply. I need some more clarifications on this. Let us assume the scenario where H1, H3 are connected to R1 and H2, H4 are connected to R2, where R1 and R2 are routers. H1----------R1 ========= R2--------H2 H3----------| |-----------H4 For H1 and H2, an SA is established with AH and algorithm alg1. Again, is it possible to establish an SA between R1 and R2 with AH and algorithm alg2 ? Also, is it possible that, since more than one SAs exist between RI andR2, whether the outbound packet from R1 uses the first SA and the packet from R2 uses the second SA ? Is it that the second SA can be established only when the first SA lifetime is about to get expired ? What are the other cases when multiple SAs need to be established between R1 and R2 ? Regards Ruheena Rashid. -----Original Message----- From: Joern Sierwald [SMTP:joern.sierwald@f-secure.com] Sent: Wednesday, April 12, 2000 4:41 PM To: ruheenar@future.futsoft.com Subject: Re: Query - Phase 2 negotiation (RFC 2409) At 15:09 12.4.2000 +0530, you wrote: >Hello > >I have a query regarding the negotiation of IPSEC SAs in Quick mode. RFC >2409 states that - > >"A single phase 1 negotiation may be used for more than one phase 2 >negotiation." >Does this mean that the endpoints need to be different in the subsequent >phase 2 negotiations? > >Suppose >We have hosts A and B and the tunnel endpoints X and Y, which supports both >AH and ESP with x1, x2, x3 algorithms. Let us assume that already an SA has >been established using AH protocol and x1 algorithm using phase 2 >negotiation. I would like to know whether another SA can be established >using phase 2 negotiation between the same endpoints using AH protocol and >algorithm x2 ? If yes, then does this mean that there is no check performed >before creating a new SA between the same endpoints and any number of SAs >can exist between the 2 endpoints with the same parameters? > Well, yes. You may establish as many tunnels as you like. Parameters don't really matter. About your "no check" remark, that's another matter. You may want to implement one, to see if something goes seriously wrong. I mean, a host may try (due to some malfunction, or as an attack) to do 10000 QMs with the same parameters, and your implementation should be able to detect such a case. But it is normal that more than one tunnel exists. I mean, you rekey the Ipsec SA early, and for a short time there are two tunnels. Jorn From owner-ipsec@lists.tislabs.com Wed Apr 12 04:59: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 EAA04167; Wed, 12 Apr 2000 04:59:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA09229 Wed, 12 Apr 2000 06:48:38 -0400 (EDT) Date: Wed, 12 Apr 2000 13:54:37 +0300 (EET DST) From: Markku Savela Message-Id: <200004121054.NAA12700@anise.tte.vtt.fi> To: ruheenar@future.futsoft.com CC: jayashreej@kailash.future.futsoft.com, ruheenar@kailash.future.futsoft.com, venkatn@kailash.future.futsoft.com, ipsec@lists.tislabs.com In-reply-to: <01BFA48D.AB8DBC80.ruheenar@future.futsoft.com> (message from Ruheena Rashid on Wed, 12 Apr 2000 14:44:55 +0530) Subject: Re: Query : PF_KEY related Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > RFC 2367 states that > - when IKE sends a KEY_REGISTER to IPSEC, the IPSEC replies with supported > algorithms. > (i) I would like to know whether this set of supported algorithms contains > only the default algorithms (provided there are separate configuration for > every peer, which contains the set of algorithms supported for negotiating > with each peer) > Or > it contains the complete set of algorithms supported. In our implementation reply contains complete set of algorithms that have been installed into kernel IPSEC. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Wed Apr 12 05:10: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 FAA04385; Wed, 12 Apr 2000 05:10:36 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA09292 Wed, 12 Apr 2000 07:00:04 -0400 (EDT) Message-ID: <38F458C3.D8F604D9@lmf.ericsson.se> Date: Wed, 12 Apr 2000 14:06:43 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "ruheenar@future.futsoft.com" CC: "'Jayashree'" , "'Ruheena Rashid'" , "'Venkatesh'" , "'ipsec@lists.tislabs.com'" , pf_key@inner.net Subject: Re: Query : PF_KEY related References: <01BFA48D.AB8DBC80.ruheenar@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ruheena Rashid wrote: > RFC 2367 states that > - when IKE sends a KEY_REGISTER to IPSEC, the IPSEC replies with supported > algorithms. > (i) I would like to know whether this set of supported algorithms contains > only the default algorithms (provided there are separate configuration for > every peer, which contains the set of algorithms supported for negotiating > with each peer) > Or > it contains the complete set of algorithms supported. As far as I've understood, the REGISTER message isn't too good for this purpose. Let's assume you want to use DES towards peer X and BLOWFISH towards peer Y, and that you additionally support also 3DES. You've got three possibilities: (1) register list is the list of supported algorithms: {DES, 3DES, BLOWFISH} (2) register list is the union of policies: {DES, BLOWFISH} (3) register list is the intersection of policies: {} NONE of the above possibilities is useful when IKE negotiates something with a peer. In case 1, it would be led to believe we can actually use 3DES. In case 2, it might mistakenly agree on the use of DES when in fact this particular peer policy needed BLOWISH. Case 3 goes obviously wrong. Furthermore, it could be that the set of peer policies is not known at boot time, it could change over time and perhaps be partially fetched from the network, so sending this information at REGISTER time may not make much sense. > (ii) Also, when a remote peer contacts IKE for negotiation, does the IKE > check for the supported algorithms based on the algorithms sent in the > reply to KEY_REGISTER (as mentioned above)? If this is so, then the IKE > needs to be furnished with all the supported algorithms. How is this done ? As you see above, if your policies are not the same towards all peers, or if your policy differs from "accept all IPsec connections using whatever algorithms I implement", then the information given at REGISTER time is not very useful. > (iii) Is there any existing implementation which takes care of this > condition ? I've worked on one implementation which uses an additional PF_KEY message, perhaps it could be called ERIUQCA. This is a per-connection message that at time asks the IPsec to make a decision regarding how it wants to protect this particular proposed connection. IKE can then take an intersection of the policy given from IPSec, from the peer, and possibly from the REGISTER list of algorithms. /Jari From owner-ipsec@lists.tislabs.com Wed Apr 12 05:10: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 FAA04399; Wed, 12 Apr 2000 05:10:41 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA09284 Wed, 12 Apr 2000 06:59:56 -0400 (EDT) Message-Id: <01BFA49C.91490B40.ruheenar@future.futsoft.com> From: Ruheena Rashid Reply-To: "ruheenar@future.futsoft.com" To: "'Joern Sierwald'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: Query - Phase 2 negotiation (RFC 2409) Date: Wed, 12 Apr 2000 16:31:33 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, As you have said that by having multiple SA's we can secure different traffics using different kind of algorithms. Now if we consider a case like host H1 is with IP address 10.0.0.1 and connected to R1 LAN. Host - H2 is in a different network connected to R2 with IP address 20.0.0.1. I have an SA say, SA1 : for 10.0.0.1 to 20.0.0.1 - AH protocol , supporting algorithms set 1. SA2 : Again, I have another SA for the same pair 10.0.0.1 to 20.0.0.1 - AH protocol , supporting algorithms set 2. Now my TCP traffic goes on SA1. But when I get a response to the same the peer might use SA2 to Send the same as Protocol & port information's are not exchanged as part of IKE Phase 2 negotiations. Is it possible to take care of such situations? Is this what you are referring to in your reply? Thanks, Ruheena Rashid -----Original Message----- From: Joern Sierwald [SMTP:joern.sierwald@f-secure.com] Sent: Wednesday, April 12, 2000 5:15 PM To: ruheenar@future.futsoft.com Subject: RE: Query - Phase 2 negotiation (RFC 2409) At 15:57 12.4.2000 +0530, you wrote: >Hello > >Thanks for your reply. I need some more clarifications on this. > >Let us assume the scenario where H1, H3 are connected to R1 and H2, H4 are >connected to R2, where R1 and R2 are routers. > >H1----------R1 ========= R2--------H2 >H3----------| |-----------H4 > >For H1 and H2, an SA is established with AH and algorithm alg1. >Again, is it possible to establish an SA between R1 and R2 with AH and >algorithm alg2 ? > Yes. >Also, is it possible that, since more than one SAs exist between RI andR2, >whether the outbound packet from R1 uses the first SA and the packet from >R2 uses the second SA ? > Yes. That's rather normal. Image two gateways, each with 10 subnets behind it, 192.168.1 to 192.168.10 and 192.168.11 to 192.168.20. That'd result in 100 tunnels (200 SAs) between the gateways. And the gateways send the packets through the right tunnels. >Is it that the second SA can be established only when the first SA lifetime >is about to get expired ? No. >What are the other cases when multiple SAs need to be established between >R1 and R2 ? Well, you can have port and protocol selectors. You can secure every tcp stream (source/remote port combination) with it's own tunnel. If you want to. Jorn From owner-ipsec@lists.tislabs.com Wed Apr 12 06:34: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 GAA06574; Wed, 12 Apr 2000 06:34:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09587 Wed, 12 Apr 2000 08:26:03 -0400 (EDT) Message-ID: <38F46D34.B95321E6@F-Secure.com> Date: Wed, 12 Apr 2000 15:33:56 +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: ipsec-list Subject: Conf. Mode & X-Auth specifics questions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What is the correct way to signal an error in configuration mode (-05) if the peer sends you a packet that contains a) zero ATTR payloads, or b) more than one ATTR payload? What if c) the peer sends you a REPLY or an ACK without you having first sent a REQUEST or a SET? Would it sound right for a) and b) to reply with a REPLY or an ACK with zero attributes? For c) to silently discard? Or perhaps some informational payload thingies? Or define an error reporting message type inside conf. mode (ISAKMP_CFG_ERROR=5) and a generic error attribute containing ASCII text? There's also a way in conf. mode to request the peer's version as a printable ASCII string. That's a nice invention, I wonder why ISAKMP doesn't use printable free-form version strings ;). Seriously, what's the practical use of that? In XAUTH (-06) you're supposed to send in the first message both a vendor id and attributes from the private number range. This is not according to ISAKMP rules, which to my understanding state that you must first RECEIVE the vendor id to be able to use those private number ranges. Right? Why don't you just reserve the proper numbers right away? Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Wed Apr 12 06:36: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 GAA06628; Wed, 12 Apr 2000 06:36:08 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09593 Wed, 12 Apr 2000 08:27:37 -0400 (EDT) Date: Wed, 12 Apr 2000 15:34:20 +0300 (EET DST) From: Markku Savela Message-Id: <200004121234.PAA12908@anise.tte.vtt.fi> To: Jari.Arkko@lmf.ericsson.se CC: ipsec@lists.tislabs.com In-reply-to: <38F458C3.D8F604D9@lmf.ericsson.se> (message from Jari Arkko on Wed, 12 Apr 2000 14:06:43 +0300) Subject: IKE should not do policy [Re: Query : PF_KEY related] Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ I trimmed the CC-list, as this reply has only incidental connection with PFKEY ] > As you see above, if your policies are not the same towards all > peers, or if your policy differs from "accept all IPsec connections > using whatever algorithms I implement", then the information given > at REGISTER time is not very useful. - my basic premise has always been that IKE does not do policy. RFC-2401 does not require it. - IKE negotiation includes the proposals, which list the set of algorithms from which to choose for the SA. - in our system, the negotiation for a SA is succesful, if a requested set of algorithms is available (this is for responder, as initiator the proposed algorithms are implictly available, as they would not be requested otherwise). The policy, combination of SA's (bundle) required between peers, is defined for the kernel IPSEC, and for all communications, it will be checked and verified (as per RFC 2401). This means, that IKE negotiation may be success (all algoritms are available), but the actual communication may fail, if the policies on peers are not matching. I don't see this situation a fault, as the policies *should* match, and any difference is an administration error. Of course, the system *will* notice mismatch of the policy and will log and report it. A user can be notified that "your policy configuration with peer X is not correct". I don't see what else can be done. I don't accept that IKE or any other program automaticly starts changing my configured policy requirements. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Wed Apr 12 06:48: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 GAA06875; Wed, 12 Apr 2000 06:48:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA09662 Wed, 12 Apr 2000 08:40:23 -0400 (EDT) Message-ID: <38F47052.368090F2@lmf.ericsson.se> Date: Wed, 12 Apr 2000 15:47:14 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Markku Savela CC: ipsec@lists.tislabs.com Subject: Re: IKE should not do policy [Re: Query : PF_KEY related] References: <200004121234.PAA12908@anise.tte.vtt.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markku Savela wrote: > This means, that IKE negotiation may be success (all algoritms are > available), but the actual communication may fail, if the policies on > peers are not matching. I don't see this situation a fault, as the > policies *should* match, and any difference is an administration > error. > > Of course, the system *will* notice mismatch of the policy and will > log and report it. A user can be notified that "your policy > configuration with peer X is not correct". I don't see what else can > be done. I don't accept that IKE or any other program automaticly > starts changing my configured policy requirements. I'm confused now. I accept that IKE should not transmit policy. But shouldn't it still act based on the locally configured policy? I mean if I've configured my box to use BLOWFISH towards X, then I'd like my IKE implementation to choose the BLOWFISH proposal and not the DES one, even if X for some reason proposed both. Remember that we're the terminating side box in this discussion. I'm not sure why you say something is automatically changing your configured policy requirements? Nothing should do that. Instead, the locally configured policy requirements should be followed in the decisions IKE makes. Can you explain what you meant? Jari From owner-ipsec@lists.tislabs.com Wed Apr 12 07:30: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 HAA07641; Wed, 12 Apr 2000 07:30:53 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09830 Wed, 12 Apr 2000 09:17:27 -0400 (EDT) Date: Wed, 12 Apr 2000 16:24:01 +0300 (EET DST) From: Markku Savela Message-Id: <200004121324.QAA13282@anise.tte.vtt.fi> To: Jari.Arkko@lmf.ericsson.se CC: ipsec@lists.tislabs.com In-reply-to: <38F47052.368090F2@lmf.ericsson.se> (message from Jari Arkko on Wed, 12 Apr 2000 15:47:14 +0300) Subject: Re: IKE should not do policy [Re: Query : PF_KEY related] Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I mean if I've configured my box to use BLOWFISH towards X, then I'd > like my IKE implementation to choose the BLOWFISH proposal and not > the DES one, even if X for some reason proposed both. If my policy is Me -> X : use Blowfish and other ends policy to me is X -> Me : use Blowfish (which is what I mean with *mathing* policy). Where does the DES come into proposal? For it to appear, the other end must have X -> Me : use Blowfish or DES which implies non-matching policies => configuration error. To fix, my end would also have to be Me -> X : use Blowfish or DES -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Wed Apr 12 08:07: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 IAA08982; Wed, 12 Apr 2000 08:07:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA09913 Wed, 12 Apr 2000 09:32:04 -0400 (EDT) Message-ID: <11EAD88229D3D3118A4D009027DC878C0B9C86@magnum.osd.ausys.se> From: Per Persson Exjobbare To: "'ipsec@lists.tislabs.com'" Subject: ipsec-layer in Solaris7? Date: Wed, 12 Apr 2000 15:38:58 +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 1. How do i implement ipsec in Solaris7? 2. Where can i get sourcecode or binares of ipsec? Thanks Per Persson From owner-ipsec@lists.tislabs.com Wed Apr 12 08:44: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 IAA10246; Wed, 12 Apr 2000 08:44:11 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10428 Wed, 12 Apr 2000 10:29:56 -0400 (EDT) Message-ID: <38F489FF.F7912FC7@lmf.ericsson.se> Date: Wed, 12 Apr 2000 17:36:47 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Markku Savela CC: ipsec@lists.tislabs.com Subject: Re: IKE should not do policy [Re: Query : PF_KEY related] References: <200004121324.QAA13282@anise.tte.vtt.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markku Savela wrote: >For it to appear, the other end must have > > X -> Me : use Blowfish or DES Right. That's what I meant. > which implies non-matching policies => configuration error. To fix, my > end would also have to be > > Me -> X : use Blowfish or DES I think you're saying that the proposal lists of two peers should be equal, otherwise something is broken. Is this the way most implementations work? If the lists must always be equal, why do we have lists and not simply a single algorithm name in IKE? Why is the IKE proposal selection process needed? Wouldn't it be hard to get all the policies exactly the same, say in a larger group of nodes all of which may communicate with each other. Jari From owner-ipsec@lists.tislabs.com Wed Apr 12 09:19: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 JAA11925; Wed, 12 Apr 2000 09:19:51 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA10528 Wed, 12 Apr 2000 10:53:39 -0400 (EDT) Message-ID: <001c01bfa48f$eec99490$cbd62ca1@cisco.com> From: "Stephane Beaulieu" To: "Ari Huttunen" , "ipsec-list" Cc: "Roy Pereira" References: <38F46D34.B95321E6@F-Secure.com> Subject: Re: Conf. Mode & X-Auth specifics questions Date: Wed, 12 Apr 2000 11:01:03 -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 Hi Ari, > What is the correct way to signal an error in configuration mode (-05) > if the peer sends you a packet that contains a) zero ATTR payloads, > or b) more than one ATTR payload? What if c) the peer sends you a REPLY > or an ACK without you having first sent a REQUEST or a SET? > > Would it sound right for a) and b) to reply with a REPLY or > an ACK with zero attributes? For c) to silently discard? Or perhaps > some informational payload thingies? Or define an error reporting > message type inside conf. mode (ISAKMP_CFG_ERROR=5) and a generic > error attribute containing ASCII text? It's currently not defined. In my previous life, malformed or out of sequence packets were silently discarded. It's a good point though, perhaps it'll be defined in v6? Roy???? > > There's also a way in conf. mode to request the peer's version > as a printable ASCII string. That's a nice invention, I wonder > why ISAKMP doesn't use printable free-form version strings ;). > Seriously, what's the practical use of that? > > In XAUTH (-06) you're supposed to send in the first message both > a vendor id and attributes from the private number range. This is > not according to ISAKMP rules, which to my understanding state > that you must first RECEIVE the vendor id to be able to use those > private number ranges. Right? I'm not aware of any such rules. If the peer receives the vendor ID and doesn't recognize it, then he'll probably send back a NOTIFY because he doesn't understand the private numbers you sent, or he'll silently pick another proposal if one is available. > > Why don't you just reserve the proper numbers right away? Funny ! Dibs on numbers 6-1000 :) Actually, we (actually Roy) did that mistake with Mode-Cfg. This actually goes against what is defined in 2409 which states that those numbers may only be assigned by IANA. Unfortunately, by the time the error was discovered, there were several deployed implementations, so it was kind of too late to change it. Xauth did not make that mistake. The numbers will be re-assigned and the vendor-id disposed of when/if it ever gets standardized. regards, Stephane. From owner-ipsec@lists.tislabs.com Wed Apr 12 13:18: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 NAA17902; Wed, 12 Apr 2000 13:18:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA11516 Wed, 12 Apr 2000 14:51:29 -0400 (EDT) Reply-To: From: "Paul Kierstead" To: Subject: RFC 2401, Inbound SPD and SAD Date: Wed, 12 Apr 2000 14:50:57 -0400 Message-Id: <002901bfa4b0$0a4d2310$61daa8c0@pmk_laptop.timestep.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Question on Inbound SPD, SAD and checking. Assume that the inbound SPD looks like: src=any dest=1.2.3.4 action=ESP 3-DES tunnel src=any dest=1.2.3.* action=ESP DES tunnel The obvious intention here is to have 1.2.3.4 be 3-DES and anything else in the subnet be DES. After IKE, we end up with a SAD that looks like: src=*, dest=1.2.3.4 spi=1000 3-DES (back points to first SPD entry) src=*, dest=1.2.3.* spi=1001 DES (back points to second SPD entry) I now get an inbound packet, ESP on spi 1001 which has src=1.2.4.4, dest=1.2.3.4 which used DES. According to RFC 2401, section 5.2.1, we could use the back pointer. Yup, everything is good: selectors match, DES was done. Yet clearly the SPD was NOT met as a higher priority entry specified that that selector should be 3-DES. So backpointer doesn't -- in fact -- correctly enforce the policy. The same section says that -- if searching -- you repeat the search until a match is found. In this case, we hit the first entry: selectors match (as per section), but action does not. So pick up where we left off, we repeat and see the second one. Yup selectors match, action match, A-OK. But again, the SPD is ordered: 1.2.3.4 should be 3-DES. So what am I missing/misinterpreting here? It seems that section 5.2.1 gives an incorrect algorithm for enforcement. Paul Kierstead TimeStep Corporation mailto:pkierste@newbridge.com http:\\www.timestep.com From owner-ipsec@lists.tislabs.com Wed Apr 12 13:28: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 NAA18490; Wed, 12 Apr 2000 13:28:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11622 Wed, 12 Apr 2000 15:24:06 -0400 (EDT) Message-Id: <3.0.5.32.20000412183137.0324f7f0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 12 Apr 2000 18:31:37 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Conf. Mode & X-Auth specifics questions In-Reply-To: <001c01bfa48f$eec99490$cbd62ca1@cisco.com> References: <38F46D34.B95321E6@F-Secure.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA10676 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:01 12.4.2000 -0400, you wrote: >Funny ! Dibs on numbers 6-1000 :) > >Actually, we (actually Roy) did that mistake with Mode-Cfg. This actually >goes against what is defined in 2409 which states that those numbers may >only be assigned by IANA. Unfortunately, by the time the error was >discovered, there were several deployed implementations, so it was kind of >too late to change it. Xauth did not make that mistake. The numbers will >be re-assigned and the vendor-id disposed of when/if it ever gets >standardized. > > >regards, >Stephane. > Did anybody actually try to get an IANA number for IKE while an idea or feature was still in the draft state? J–rn From owner-ipsec@lists.tislabs.com Wed Apr 12 14:19: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 OAA19895; Wed, 12 Apr 2000 14:19:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11866 Wed, 12 Apr 2000 16:07:00 -0400 (EDT) Date: Wed, 12 Apr 2000 16:13:49 -0400 Message-Id: <200004122013.QAA07979@tonga.xedia.com> From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: joern.sierwald@F-Secure.com Cc: ipsec@lists.tislabs.com Subject: Re: Conf. Mode & X-Auth specifics questions References: <38F46D34.B95321E6@F-Secure.com> <001c01bfa48f$eec99490$cbd62ca1@cisco.com> <3.0.5.32.20000412183137.0324f7f0@smtp.datafellows.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Joern" == Joern Sierwald writes: Joern> At 11:01 12.4.2000 -0400, you wrote: >> Funny ! Dibs on numbers 6-1000 :) >> >> Actually, we (actually Roy) did that mistake with Mode-Cfg. This >> actually goes against what is defined in 2409 which states that >> those numbers may only be assigned by IANA. ... Joern> Did anybody actually try to get an IANA number for IKE while Joern> an idea or feature was still in the draft state? I thought the process specifically forbids that. Some people consider this a feature (I'm not among those). paul From owner-ipsec@lists.tislabs.com Wed Apr 12 14:19: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 OAA19896; Wed, 12 Apr 2000 14:19:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11875 Wed, 12 Apr 2000 16:07:54 -0400 (EDT) Message-Id: <200004122011.NAA23824@potassium.network-alchemy.com> To: Joern Sierwald cc: ipsec@lists.tislabs.com Subject: Re: Conf. Mode & X-Auth specifics questions In-reply-to: Your message of "Wed, 12 Apr 2000 18:31:37 +0200." <3.0.5.32.20000412183137.0324f7f0@smtp.datafellows.com> MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <23821.955570300.1@network-alchemy.com> Date: Wed, 12 Apr 2000 13:11:40 -0700 From: Dan Harkins Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id QAA11872 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You're not supposed to do it that way. Check out the IANA Considerations section of RFC2409 and RFC2408. Internet-drafts are not allowed to request magic numbers from IANA. Since Mode-Cfg has expired I suggest that if it is ever resurrected (and since it is not a current work item I guess it would have to be a personal submission) that it not use a number reserved to IANA. "Several deployed implementations" be damned. That'll learn ya. Dan. On Wed, 12 Apr 2000 18:31:37 +0200 you wrote > At 11:01 12.4.2000 -0400, you wrote: > > >Funny ! Dibs on numbers 6-1000 :) > > > >Actually, we (actually Roy) did that mistake with Mode-Cfg. This actually > >goes against what is defined in 2409 which states that those numbers may > >only be assigned by IANA. Unfortunately, by the time the error was > >discovered, there were several deployed implementations, so it was kind of > >too late to change it. Xauth did not make that mistake. The numbers will > >be re-assigned and the vendor-id disposed of when/if it ever gets > >standardized. > > > > > >regards, > >Stephane. > > > > Did anybody actually try to get an IANA number for IKE while > an idea or feature was still in the draft state? > > J–rn From owner-ipsec@lists.tislabs.com Wed Apr 12 14:30: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 OAA20105; Wed, 12 Apr 2000 14:30:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA11954 Wed, 12 Apr 2000 16:17:27 -0400 (EDT) Date: Wed, 12 Apr 2000 23:24:15 +0300 (EET DST) From: Markku Savela Message-Id: <200004122024.XAA13632@anise.tte.vtt.fi> To: pkierste@newbridge.com CC: ipsec@lists.tislabs.com In-reply-to: <002901bfa4b0$0a4d2310$61daa8c0@pmk_laptop.timestep.com> (pkierste@newbridge.com) Subject: Re: RFC 2401, Inbound SPD and SAD Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Assume that the inbound SPD looks like: > src=any dest=1.2.3.4 action=ESP 3-DES tunnel > src=any dest=1.2.3.* action=ESP DES tunnel > > After IKE, we end up with a SAD that looks like: > > src=*, dest=1.2.3.4 spi=1000 3-DES (back points to first SPD entry) > src=*, dest=1.2.3.* spi=1001 DES (back points to second SPD entry) > > I now get an inbound packet, ESP on spi 1001 which has src=1.2.4.4, > dest=1.2.3.4 which used DES. > In this case, we hit the first entry: selectors match (as per > section), but action does not. You got it already there. Action does not match, and thus the packet has been sent with wrong policy. The statement about continuing search, if not match happens, applies only to comparing the selector part... Any ways, the whole text about "backpointers" in RFC is (IMHO) just an attempt to hint about optimization, without really explaining how they work. As you noted, just simple "backpointer" is not working... (especially, considering that the same SA could be referenced from multiple selectors). The "unoptimized" inbound policy checking, which I do roughly as follows (some details omitted): 1. process all IPSEC headers (including some tunnels), and while doing so, remember all SA's that were applied. 2. After this you have a packet where topmost header is not AH or ESP, and usually something like UDP, TCP etc. 3. Apply this "unwrapped" packet to the inbound policy selectors, => if no match, either drop the packet or pass (depening on what you consider correct for a packet that no selector applies) => if match is found, compare the required actions with the ones actually done. If actions (SAs) and their order does not match, then there is a policy mismatch or some other spoof attempt. If actions match, pass the packet. This is simple and and 100% right, without any need to fall back into these "you need to continue search in some cases". -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Wed Apr 12 15:16:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA21212; Wed, 12 Apr 2000 15:16:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA12249 Wed, 12 Apr 2000 17:10:09 -0400 (EDT) Date: Thu, 13 Apr 2000 00:16:59 +0300 (EET DST) From: Markku Savela Message-Id: <200004122116.AAA13718@anise.tte.vtt.fi> To: Jari.Arkko@lmf.ericsson.se CC: ipsec@lists.tislabs.com In-reply-to: <38F489FF.F7912FC7@lmf.ericsson.se> (message from Jari Arkko on Wed, 12 Apr 2000 17:36:47 +0300) Subject: Re: IKE should not do policy [Re: Query : PF_KEY related] Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I think you're saying that the proposal lists of two peers > should be equal, otherwise something is broken. Is this the > way most implementations work? If the lists must always > be equal, why do we have lists and not simply a single > algorithm name in IKE? Why is the IKE proposal selection > process needed? Wouldn't it be hard to get all the policies > exactly the same, say in a larger group of nodes all of > which may communicate with each other. Consider the situation, with 4 different clients (A - D) which support DES and BLOWFISH as follows A (DES,IDEA) -------\ \ B (DES,BLOWFISH) --- SG --- X // C (BLOWFISH) -------// / D (IDEA) ----------/ Someone is going to define the policy for accessing X behind the SG, and this person desides that either DES or BLOWFISH is sufficient. Thus he configures the SG with (any) -> X => Use DES or Blowfish and distributes the same policy to clients A - D. These clients must load the policy into their kernels and at latest this is the point where some notice that policy specifies algorithms that are not supported locally. The logical thing to do at this point (policy load), is to drop all unsupported algorithms from the actual activated policy as follows A: use DES for X B: use DES or BLOWFISH for X C: use BLOWFISH for X D: intersection is empty, complain that policy cannot be done (at least one algorithm is required for ESP SA) When SG is initiator, it will offer (DES or BLOWFISH) to each A-D. A: only DES is available, accept DES B: DES and BLOWFISH is available, so IKE can decide which to accept C: only BLOWFISH is available, accept BLOWFISH D: not applicaple, can't get this far (or will reject all offers) When A-D is initiator, A: offers only DES (ACQUIRE asks only DES) B: offers DES and BLOWFISH (ACQUIRE asks DES or BLOWFISH) C: offers only BLOWFISH (ACQUIRE asks BLOWFISH) D: not applicaple, because policy was already impossible So, the alternatives have a role in policy distribution, but unsupported alternates can already be checked and filtered out at the policy loading phase. -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Thu Apr 13 07:25: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 HAA22073; Thu, 13 Apr 2000 07:25:43 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA14939 Thu, 13 Apr 2000 08:13:33 -0400 (EDT) Message-ID: <38F5BBCD.1B1F69DD@F-Secure.com> Date: Thu, 13 Apr 2000 15:21: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: Markku Savela CC: Jari.Arkko@lmf.ericsson.se, ipsec@lists.tislabs.com Subject: Re: IKE should not do policy [Re: Query : PF_KEY related] References: <200004122116.AAA13718@anise.tte.vtt.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Markku Savela wrote: > > Consider the situation, with 4 different clients (A - D) which > support DES and BLOWFISH as follows > > A (DES,IDEA) -------\ > \ > B (DES,BLOWFISH) --- SG --- X > // > C (BLOWFISH) -------// > / > D (IDEA) ----------/ > > Someone is going to define the policy for accessing X behind the SG, > and this person desides that either DES or BLOWFISH is > sufficient. Thus he configures the SG with > > (any) -> X => Use DES or Blowfish > > and distributes the same policy to clients A - D. These clients must > load the policy into their kernels and at latest this is the point > where some notice that policy specifies algorithms that are not > supported locally. The logical thing at this point is to fire the person responsible for this so-called 'policy'. According to it, anyone, including any malicious hacker, is allowed to connect to SG if there only is DES or Blowfish being used. This offers no security whatsoever to X. Even though this example was clearly simplified, it points quite clearly the current state of mind for 'policy' discussions relating to IPSec. The problem is that policy is viewed as being able to overcome the immediate problems relating to choosing correct parameters for IKE/IPSec, a problem sort-of created by IKE/IPSec. The real POLICY in this situation should state something like the following. Any entity trusted by X should contact it using a secure tunnel to SG. SG should trust any such entity for the purpose of contacting X. And so forth. So in reply to the subject line: no, IKE does not do policy. Ari -- Ari Huttunen phone: +358 9 859 900 Senior Software Engineer fax : +358 9 8599 0452 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ipsec@lists.tislabs.com Thu Apr 13 08:45: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 IAA23723; Thu, 13 Apr 2000 08:45:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15311 Thu, 13 Apr 2000 09:36:31 -0400 (EDT) Message-ID: <11EAD88229D3D3118A4D009027DC878C0B9C99@magnum.osd.ausys.se> From: Per Persson Exjobbare To: "'ipsec@lists.tislabs.com'" Subject: Implementing ipsec on Solaris7 Date: Thu, 13 Apr 2000 15:43:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello everyone. I want to implement ipsec in Solaris7. I don't want to use Solaris8. Where can i get the source code or binaries for use on Solaris7? Thanks Per Persson From owner-ipsec@lists.tislabs.com Thu Apr 13 12:13: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 MAA28367; Thu, 13 Apr 2000 12:13:35 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16302 Thu, 13 Apr 2000 13:58:27 -0400 (EDT) Message-Id: <3.0.5.32.20000412183137.0324f7f0@smtp.datafellows.com> X-Sender: joern@smtp.datafellows.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 12 Apr 2000 18:31:37 +0200 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: Conf. Mode & X-Auth specifics questions In-Reply-To: <001c01bfa48f$eec99490$cbd62ca1@cisco.com> References: <38F46D34.B95321E6@F-Secure.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA10676 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:01 12.4.2000 -0400, you wrote: >Funny ! Dibs on numbers 6-1000 :) > >Actually, we (actually Roy) did that mistake with Mode-Cfg. This actually >goes against what is defined in 2409 which states that those numbers may >only be assigned by IANA. Unfortunately, by the time the error was >discovered, there were several deployed implementations, so it was kind of >too late to change it. Xauth did not make that mistake. The numbers will >be re-assigned and the vendor-id disposed of when/if it ever gets >standardized. > > >regards, >Stephane. > Did anybody actually try to get an IANA number for IKE while an idea or feature was still in the draft state? J–rn From owner-ipsec@lists.tislabs.com Thu Apr 13 12:18:17 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28458; Thu, 13 Apr 2000 12:18:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16293 Thu, 13 Apr 2000 13:57:27 -0400 (EDT) Message-ID: <02f901bfa571$da508220$7164a8c0@ruchirnt> From: "Ruchir" To: Subject: latest ipsec , isakmp and ike MIB drafts Date: Thu, 13 Apr 2000 10:58:18 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F6_01BFA537.2D15A200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_02F6_01BFA537.2D15A200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Which are the latest drafts on IPSEC, ISAKMP AND IKE MIBs ? Ruchir ------=_NextPart_000_02F6_01BFA537.2D15A200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
    Which are the latest = drafts=20 on IPSEC, ISAKMP AND IKE MIBs ?
 
Ruchir
------=_NextPart_000_02F6_01BFA537.2D15A200-- From owner-ipsec@lists.tislabs.com Thu Apr 13 16:33: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 QAA02724; Thu, 13 Apr 2000 16:33:30 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA17369 Thu, 13 Apr 2000 18:18:16 -0400 (EDT) Message-ID: <38F649A2.95799F7C@infoexpress.com> Date: Thu, 13 Apr 2000 15:26:42 -0700 From: "Cary Y. Tsai" X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: XAUTH question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi There: In draft-ietf-ipsec-isakmp-xauth-06.txt, it mentions ISAKMP-Config, which is "The ISAKMP Configuration Method", draft-ietf-ipsec-isakmp-cfg-05 Where is this doc? cary tsai --ctsai@.infoexpress.com From owner-ipsec@lists.tislabs.com Fri Apr 14 06:11: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 GAA27648; Fri, 14 Apr 2000 06:11:17 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA19549 Fri, 14 Apr 2000 07:32:33 -0400 (EDT) Message-Id: <01BFA633.73C9A140.ruheenar@future.futsoft.com> From: Ruheena Rashid Reply-To: "ruheenar@future.futsoft.com" To: "ipsec@lists.tislabs.com" Cc: "'Markku Savela'" , "'Joern Sierwald'" , "'Ruheena Rashid'" Subject: Query : IPSEC SA lifetime Date: Fri, 14 Apr 2000 17:04:09 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello I have a query regarding the lifetime of an IPSEC SA. RFC 2409 states that - "Lifetime of this Security Association may be expressed as a time or byte count, or a simultaneous use of both, the first lifetime to expire taking precedence. A compliant implementation MUST support both types of lifetimes, and must support a simultaneous use of both." Does this mean that an entry in the SAD for an IPSEC SA can have 2 entries for lifetime (provided my implementation supports simultaneous use of both lifetimes) ? For example, lifetime_sec1 and lifetime_sec2 -- for time count, and lifetime_byte1 and lifetime_byte2 -- for byte count Is this possible ? But RFC 2409 states that - "For a given "Life Type" the value of the "Life Duration" attribute defines the actual length of the SA life-- either a number of seconds, or a number of kbytes protected." Which means that either of the two can be used. How will IKE pass on the information for both types of lifetime to IPSEC because IKE supports any one only ? Is this not contradictory ? Please clarify. Regards Ruheena Rashid. From owner-ipsec@lists.tislabs.com Fri Apr 14 07:17: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 HAA28700; Fri, 14 Apr 2000 07:17:46 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19849 Fri, 14 Apr 2000 09:05:34 -0400 (EDT) Message-ID: <016301bfa613$1d21d850$cbd62ca1@cisco.com> From: "Stephane Beaulieu" To: "Cary Y. Tsai" , References: <38F649A2.95799F7C@infoexpress.com> Subject: Re: XAUTH question Date: Fri, 14 Apr 2000 09:12:40 -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 Hi, The draft expired a short time ago. It will be republished shortly. Sorry for the inconvenience. Stephane. ----- Original Message ----- From: "Cary Y. Tsai" To: Sent: Thursday, April 13, 2000 6:26 PM Subject: XAUTH question > Hi There: > > In draft-ietf-ipsec-isakmp-xauth-06.txt, > it mentions ISAKMP-Config, which is > "The ISAKMP Configuration Method", > draft-ietf-ipsec-isakmp-cfg-05 > > Where is this doc? > > cary tsai --ctsai@.infoexpress.com > > From owner-ipsec@lists.tislabs.com Fri Apr 14 14:50: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 OAA06571; Fri, 14 Apr 2000 14:50:18 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20841 Fri, 14 Apr 2000 14:55:26 -0400 (EDT) Date: Fri, 14 Apr 2000 15:02:18 -0400 Message-Id: <200004141902.PAA27701@tsx-prime.MIT.EDU> From: "Theodore Y. Ts'o" To: "Stephane Beaulieu" CC: "Cary Y. Tsai" , In-reply-to: Stephane Beaulieu's message of Fri, 14 Apr 2000 09:12:40 -0400, <016301bfa613$1d21d850$cbd62ca1@cisco.com> Subject: Re: XAUTH question Phone: (781) 391-3464 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From: "Stephane Beaulieu" Date: Fri, 14 Apr 2000 09:12:40 -0400 The draft expired a short time ago. It will be republished shortly. Sorry for the inconvenience. If you're referring to the following draft: >Internet Engineering Task Force R. Pereira, TimeStep Corp. >IP Security Working Group S. Anand, Microsoft Corp. >Internet Draft B. Patel, Intel Corp. >Expires in six months > August 17, 1999 > > The ISAKMP Configuration Method > It is currently *not* an IPSEC working group work item, as the functionality discussed is in the domain of the IPSRA (IPSEC Remote Access) working group. They're currently working on requirements to see what's the best way of solving that set of issues, of which ISAKMP Configuration Method is but one contender. If you want to base something on ISAKMP Configuration Method which is not in the IPSRA domain, that can certainly be discussed, although any expansion of the IPSEC wg's charter requires the approval of the Security Area Directors, and they have a marked bias towards *not* make IPSEC protocol suite more complicated at this time. However, if there's strong consensus in the working group do work on such an item, we can certainly take that request to the AD's. (BTW, the same goes for the heartbeats proposal --- I am still not sure I'm seeing strong consensus that we actually need do need to standardize a heartbeat protocol. There's still discussion going on about *whether* some new protocol is needed to solve this problem, and if so, what the general shape of that protocol should be. I encourage that discussion to continue, especially focused on that first point, since we'll need strong arguments to take to the IESG to approve letting us expand our charter to take on this new work item.) - Ted From owner-ipsec@lists.tislabs.com Fri Apr 14 16:46: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 QAA07861; Fri, 14 Apr 2000 16:46:05 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA21310 Fri, 14 Apr 2000 18:44:45 -0400 (EDT) Message-Id: <4.3.2.20000414154822.00e34350@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 14 Apr 2000 15:52:01 -0700 To: "Theodore Y. Ts'o" , ipsec@lists.tislabs.com From: Paul Hoffman Subject: Re: XAUTH question In-Reply-To: <200004141902.PAA27701@tsx-prime.MIT.EDU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:02 PM 4/14/00 -0400, Theodore Y. Ts'o wrote: >It is currently *not* an IPSEC working group work item, as the >functionality discussed is in the domain of the IPSRA (IPSEC Remote >Access) working group. Er, no it's not. IPSRA is prohibited in our charter from solutions that require changes to IKE. A new mode is pretty clearly a change to IKE. XAUTH and mode-cfg are thus now forced out of both WGs. This may be a non-optimal situation. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Apr 14 17:07: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 RAA08019; Fri, 14 Apr 2000 17:07:24 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA21387 Fri, 14 Apr 2000 19:08:55 -0400 (EDT) Message-ID: <010a01bfa667$602cbc10$7164a8c0@ruchirnt> From: "Ruchir" To: , Subject: IPsecMIB Date: Fri, 14 Apr 2000 16:15:51 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01BFA62C.B396F590" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0105_01BFA62C.B396F590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi The IPsecMIB module is defined in the draft = draft-ietf-ipsec-flow-monitoring-mib-00.txt -------------------------------------------------------------------------= ----------------- IPsecMIB MODULE-IDENTITY LAST-UPDATED "9911040000Z" ORGANIZATION "Tivoli Systems and Cisco Systems" CONTACT-INFO "Tivoli Systems Research Triangle Park, NC Cisco Systems San Jose, CA" DESCRIPTION "This is the MIB Module for objects to manage the IP Security Protocol." ::=3D { enterprises ibm(2) ibmProd(6) tivoliNma(168) IPsecMgmt(1) IPsecMgmtT1(1) 1 } -------------------------------------------------------------------------= ----------- Why is this MIB under the "enterprises" node ? Its not a proprietary = MIB, right ? where i.e. under which node, is IETF planning to put it ? Ruchir Malhotra ------=_NextPart_000_0105_01BFA62C.B396F590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
    The IPsecMIB module = is defined=20 in the draft draft-ietf-ipsec-flow-monitoring-mib-00.txt
 
----------------------------------------------------------------= --------------------------
IPsecMIB=20 MODULE-IDENTITY
       LAST-UPDATED=20 "9911040000Z"
       ORGANIZATION = "Tivoli=20 Systems and Cisco Systems"
      =20 CONTACT-INFO
          = "Tivoli=20 Systems
           = Research=20 Triangle Park, NC
 
           = Cisco=20 Systems
           = San=20 Jose, CA"
      =20 DESCRIPTION
          = "This is=20 the MIB Module for objects=20 to
           = manage the IP=20 Security Protocol."
       ::=3D { = enterprises=20 ibm(2) ibmProd(6)=20 tivoliNma(168)
         &= nbsp;           &n= bsp;           &nb= sp;        =20 IPsecMgmt(1)
         &nb= sp;           &nbs= p;            = ;        =20 IPsecMgmtT1(1) 1 }
 
----------------------------------------------------------------= --------------------
 
Why is this MIB under the = "enterprises" node ?=20 Its not a proprietary MIB, right ? where i.e. under which node, is IETF = planning=20 to put it ?
 
Ruchir = Malhotra
------=_NextPart_000_0105_01BFA62C.B396F590-- From owner-ipsec@lists.tislabs.com Fri Apr 14 19:26:00 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA22946; Fri, 14 Apr 2000 19:26:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21889 Fri, 14 Apr 2000 21:13:57 -0400 (EDT) Message-ID: <01e301bfa678$d8ab3b10$7164a8c0@ruchirnt> From: "Ruchir" To: Subject: ipsec flow monitoring mib Date: Fri, 14 Apr 2000 18:20:54 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E0_01BFA63E.2C24B6D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01E0_01BFA63E.2C24B6D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In many notification types, objects with MAX-ACCESS not-accessible are = used, resulting in errors during MIB compilation. This needs to be = rectified, or is the MIB compiler giving the worng error ? Ruchir Malhotra ------=_NextPart_000_01E0_01BFA63E.2C24B6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In many notification types, objects = with MAX-ACCESS=20 not-accessible are used, resulting in errors during MIB compilation. = This needs=20 to be rectified, or is the MIB compiler giving the worng error = ?
 
Ruchir = Malhotra
------=_NextPart_000_01E0_01BFA63E.2C24B6D0-- From owner-ipsec@lists.tislabs.com Fri Apr 14 21:18: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 VAA03077; Fri, 14 Apr 2000 21:18:00 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA22134 Fri, 14 Apr 2000 23:05:24 -0400 (EDT) From: rks@cisco.com Date: Fri, 14 Apr 2000 20:11:17 -0700 (PDT) Message-Id: <200004150311.UAA25156@miranda-ultra.cisco.com> To: ruchir@broadpac.com Cc: ipsec@lists.tislabs.com Subject: Re: ipsec flow monitoring mib Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: "Ruchir" >Date: Fri, 14 Apr 2000 18:20:54 -0700 >In many notification types, objects >with MAX-ACCESS not-accessible are >used, resulting in errors during >MIB compilation. This needs to be >rectified, or is the MIB compiler >giving the worng error ? That's correct - some notifications are not defined correctly. (There are other problems too: the MIB allows IKE SAs to abort due to "sequence number overflow"). We've fixed these problems and will be updating this draft soon. (Btw, I'd like to know how well this MIB fits your IPSec implementation, if you do have one). Thanks, Rk From owner-ipsec@lists.tislabs.com Sun Apr 16 20:20:16 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16014; Sun, 16 Apr 2000 20:20:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA28573 Sun, 16 Apr 2000 21:27:33 -0400 (EDT) Date: Mon, 17 Apr 2000 09:32:47 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@arizona To: ipsec@lists.tislabs.com Subject: Win2k IKE In-Reply-To: <003501bf9f30$8abc3520$fa811818@we.mediaone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Does anyone know whether IKE and IPsec are supported in all Win2k versions, that is professional, server, and advanced server versions? Thanks. Jianying Zhou From owner-ipsec@lists.tislabs.com Mon Apr 17 02:33: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 CAA26124; Mon, 17 Apr 2000 02:33:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA29560 Mon, 17 Apr 2000 04:07:33 -0400 (EDT) Message-Id: <01BFA872.9056A9C0.ruheenar@future.futsoft.com> From: Ruheena Rashid Reply-To: "ruheenar@future.futsoft.com" To: "'dharkins@cisco.com'" , "'Joern Sierwald'" , "'Markku Savela'" , "'carrel@ipsec.org'" , "'kent@bbn.com'" , "'rja@corp.home.net'" Cc: "'ipsec@lists.tislabs.com'" Subject: Query : IPSEC SA lifetime Date: Mon, 17 Apr 2000 13:40:55 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello I have a query regarding the lifetime of an IPSEC SA. RFC 2409 states that - "Lifetime of this Security Association may be expressed as a time or byte count, or a simultaneous use of both, the first lifetime to expire taking precedence. A compliant implementation MUST support both types of lifetimes, and must support a simultaneous use of both." Does this mean that an entry in the SAD for an IPSEC SA can have 2 entries for lifetime (provided my implementation supports simultaneous use of both lifetimes) ? For example, lifetime_sec1 and lifetime_sec2 -- for time count, and lifetime_byte1 and lifetime_byte2 -- for byte count Is this possible ? But RFC 2409 states that - "For a given "Life Type" the value of the "Life Duration" attribute defines the actual length of the SA life-either a number of seconds, or a number of kbytes protected." Which means that either of the two can be used. How will IKE pass on the information for both types of lifetime to IPSEC because IKE supports any one only ? Is this not contradictory ? Please clarify. Regards Ruheena Rashid. From owner-ipsec@lists.tislabs.com Mon Apr 17 06:47: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 GAA02144; Mon, 17 Apr 2000 06:47:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00593 Mon, 17 Apr 2000 08:40:55 -0400 (EDT) Message-ID: <20000414070849.46307.qmail@hotmail.com> X-Originating-IP: [196.1.109.11] From: "sudha malhotra" To: ipsec@lists.tislabs.com Date: Fri, 14 Apr 2000 07:08:49 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi friends, I want to start reading RFC's related to ISAKMP. According to u which one should I read first? ISAKMP IKE OAkley DOI regards Sudha ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-ipsec@lists.tislabs.com Mon Apr 17 06:47: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 GAA02150; Mon, 17 Apr 2000 06:47:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00575 Mon, 17 Apr 2000 08:35:04 -0400 (EDT) Message-Id: <01BFA897.F35DC4C0.ruheenar@future.futsoft.com> From: Ruheena Rashid Reply-To: "ruheenar@future.futsoft.com" To: "'ddp@network-alchemy.com'" Cc: "ipsec@lists.tislabs.com" Subject: Query : RFC 2407 Date: Mon, 17 Apr 2000 18:08:35 +0530 Organization: future software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello RFC 2407 states that - "The Identification Payload is used to identify the initiator of the Security Association. The identity of the initiator SHOULD be used by the responder to determine the correct host system security policy requirement for the association. For example, a host might choose to require authentication and integrity without confidentiality (AH) from a certain set of IP addresses and full authentication with confidentiality (ESP) from another range of IP addresses. The Identification Payload provides information that can be used by the responder to make this decision. During Phase I negotiations, the ID port and protocol fields MUST be set to zero or to UDP port 500." Does this mean that in phase 2 negotiations, the port and protocol fields can be set to some value other than UDP port 500, which can be used for phase 2 negotiation ? Regards Ruheena Rashid. From owner-ipsec@lists.tislabs.com Mon Apr 17 06:47: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 GAA02148; Mon, 17 Apr 2000 06:47:32 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00624 Mon, 17 Apr 2000 08:44:55 -0400 (EDT) Message-ID: From: "Mouser, Kay" To: "'ipsec@lists.tislabs.com'" Subject: IPSec Date: Fri, 14 Apr 2000 08:34:43 -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 looking to implement IPSec between a TimeStep VPN edge device and a CheckPoint firewall. If anyone has any experience or lessons learned in an implementation such as this, I would appreciate any information. Thanks, Kay Mouser Ft. Knox, KY From owner-ipsec@lists.tislabs.com Mon Apr 17 06:50:54 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02235; Mon, 17 Apr 2000 06:50:54 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA00643 Mon, 17 Apr 2000 08:47:21 -0400 (EDT) Message-ID: <310508EDF557D31188FA0050DA0A37522CC14E@CAT01S2> From: Tim Jenkins To: "'Ruchir'" , ipsec@lists.tislabs.com, l2tp@ipsec.org Subject: RE: IPsecMIB Date: Mon, 17 Apr 2000 08:54:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA86C.0CB107E0" 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_01BFA86C.0CB107E0 Content-Type: text/plain; charset="iso-8859-1" The MIB asked about is not the version that is currently being advanced under standards track. Technically, it's an application specific MIB that includes everything else. The standards track MIBs for IPsec are the following: Textual Conventions: < http://search.ietf.org/internet-drafts/draft-ietf-ipsec-doi-tc-mib-02.txt > IPsec Monitoring: < http://search.ietf.org/internet-drafts/draft-ietf-ipsec-monitor-mib-02.txt > ISAKMP DOI-ind. Monitoring: < http://search.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-di-mon-mib-01 .txt > IKE Monitoring: < http://search.ietf.org/internet-drafts/draft-ietf-ipsec-ike-monitor-mib-00.t xt > New versions of all should be available within a couple of months at the latest (hopefully). The authors of the MIB referred to below were asked if they were interested in modifying it to use the base MIBs listed above; I don't recall there being any response to that. -----Original Message----- From: Ruchir [mailto:ruchir@broadpac.com] Sent: Friday, April 14, 2000 7:16 PM To: ipsec@lists.tislabs.com; l2tp@ipsec.org Subject: IPsecMIB Hi The IPsecMIB module is defined in the draft draft-ietf-ipsec-flow-monitoring-mib-00.txt ---------------------------------------------------------------------------- -------------- IPsecMIB MODULE-IDENTITY LAST-UPDATED "9911040000Z" ORGANIZATION "Tivoli Systems and Cisco Systems" CONTACT-INFO "Tivoli Systems Research Triangle Park, NC Cisco Systems San Jose, CA" DESCRIPTION "This is the MIB Module for objects to manage the IP Security Protocol." ::= { enterprises ibm(2) ibmProd(6) tivoliNma(168) IPsecMgmt(1) IPsecMgmtT1(1) 1 } ---------------------------------------------------------------------------- -------- Why is this MIB under the "enterprises" node ? Its not a proprietary MIB, right ? where i.e. under which node, is IETF planning to put it ? Ruchir Malhotra ------_=_NextPart_001_01BFA86C.0CB107E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The=20 MIB asked about is not the version that is currently being advanced = under=20 standards track. Technically, it's an application specific MIB that = includes=20 everything else. The standards track MIBs for IPsec are the=20 following:
 
Textual Conventions: <http://search.ietf.org/internet-drafts/draft-ietf-ipsec-doi-t= c-mib-02.txt>
IPsec Monitoring:=20 <http://search.ietf.org/internet-drafts/draft-ietf-ipsec-moni= tor-mib-02.txt>
ISAKMP=20 DOI-ind. Monitoring: = <http://search.ietf.org/internet-drafts/draft-ietf-ipse= c-isakmp-di-mon-mib-01.txt>
IKE Monitoring:=20 <http://search.ietf.org/internet-drafts/draft-ietf-ipsec-= ike-monitor-mib-00.txt>
 
New = versions of all=20 should be available within a couple of months at the latest=20 (hopefully).
 
The authors of the MIB referred to below = were asked if=20 they were interested in modifying it to use the base MIBs listed above; = I don't=20 recall there being any response to=20 that.
-----Original Message-----
From: Ruchir=20 [mailto:ruchir@broadpac.com]
Sent: Friday, April 14, 2000 = 7:16=20 PM
To: ipsec@lists.tislabs.com; = l2tp@ipsec.org
Subject:=20 IPsecMIB

Hi
    The IPsecMIB = module is defined=20 in the draft draft-ietf-ipsec-flow-monitoring-mib-00.txt
 
---------------------------------------------------------------= ---------------------------
IPsecMIB=20 MODULE-IDENTITY
       LAST-UPDATED=20 "9911040000Z"
       ORGANIZATION = "Tivoli=20 Systems and Cisco Systems"
      =20 = CONTACT-INFO
          = "Tivoli=20 = Systems
           = Research Triangle Park, NC
 
           = Cisco=20 = Systems
           = San=20 Jose, CA"
      =20 DESCRIPTION
          = "This is=20 the MIB Module for objects=20 to
           = manage the=20 IP Security Protocol."
       ::=3D = {=20 enterprises ibm(2) ibmProd(6)=20 = tivoliNma(168)
         =             =             =          =20 = IPsecMgmt(1)
         &n= bsp;           &n= bsp;           &n= bsp;        =20 IPsecMgmtT1(1) 1 }
 
---------------------------------------------------------------= ---------------------
 
Why is this MIB under the = "enterprises" node=20 ? Its not a proprietary MIB, right ? where i.e. under which node, is = IETF=20 planning to put it ?
 
Ruchir=20 Malhotra
------_=_NextPart_001_01BFA86C.0CB107E0-- From owner-ipsec@lists.tislabs.com Mon Apr 17 09:03: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 JAA04626; Mon, 17 Apr 2000 09:03:47 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01218 Mon, 17 Apr 2000 10:48:17 -0400 (EDT) Message-ID: <19398D273324D3118A2B0008C7E9A56908BD2536@SIT.platinum.corp.microsoft.com> From: Brian Swander To: "'Jianying Zhou'" , ipsec@lists.tislabs.com Subject: RE: Win2k IKE Date: Mon, 17 Apr 2000 07:47:07 -0700 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 ike and ipsec are in all flavors of win2k. bs -----Original Message----- From: Jianying Zhou [mailto:jyzhou@krdl.org.sg] Sent: Sunday, April 16, 2000 6:33 PM To: ipsec@lists.tislabs.com Subject: Win2k IKE Hi, Does anyone know whether IKE and IPsec are supported in all Win2k versions, that is professional, server, and advanced server versions? Thanks. Jianying Zhou From owner-ipsec@lists.tislabs.com Mon Apr 17 13:30: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 NAA08724; Mon, 17 Apr 2000 13:30:33 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02786 Mon, 17 Apr 2000 15:17:29 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Hoffman'" , "'Theodore Y. Ts'o'" , Subject: RE: XAUTH question Date: Mon, 17 Apr 2000 15:21:35 -0400 Message-Id: <002a01bfa8a2$262dd750$59daa8c0@andrewktest.timestep.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <4.3.2.20000414154822.00e34350@mail.vpnc.org> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, Actually, I don't believe there is a consensus among WG members that adding a new mode is actually a change to IKE. This has always been a hotly debated issue. Several questions arise: What exactly is a "change" to IKE? Does it differ from an "extension" to IKE? Does it differ from a change/extension to ISAKMP? IKE stands for Internet Key Exchange. How far do we want to stretch this? If someone defines a new ISAKMP mode that has nothing to do with exchanging keys, then why would it be considered a change to IKE? 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 Paul Hoffman > Sent: Friday, April 14, 2000 6:52 PM > To: Theodore Y. Ts'o; ipsec@lists.tislabs.com > Subject: Re: XAUTH question > > > At 03:02 PM 4/14/00 -0400, Theodore Y. Ts'o wrote: > >It is currently *not* an IPSEC working group work item, as the > >functionality discussed is in the domain of the IPSRA (IPSEC Remote > >Access) working group. > > Er, no it's not. IPSRA is prohibited in our charter from > solutions that > require changes to IKE. A new mode is pretty clearly a change > to IKE. XAUTH > and mode-cfg are thus now forced out of both WGs. This may be > a non-optimal > situation. > > --Paul Hoffman, Director > --VPN Consortium > > From owner-ipsec@lists.tislabs.com Mon Apr 17 13:32: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 NAA08758; Mon, 17 Apr 2000 13:32:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02832 Mon, 17 Apr 2000 15:31:40 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Theodore Y. Ts'o'" , "'Stephane Beaulieu'" Cc: "'Cary Y. Tsai'" , Subject: RE: XAUTH question Date: Mon, 17 Apr 2000 15:35:45 -0400 Message-Id: <002b01bfa8a4$20eed850$59daa8c0@andrewktest.timestep.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <200004141902.PAA27701@tsx-prime.MIT.EDU> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > (BTW, the same goes for the heartbeats proposal --- I am > still not sure > I'm seeing strong consensus that we actually need do need to > standardize > a heartbeat protocol. Hi Ted, At the meeting I know you said that you didn't think a heartbeat protocol was necessary and a few people from Cisco did as well, but probably most people would disagree. That is why most of the discussion on the list has concerned the format of the protocol and not whether it is needed. IP is not connection-oriented but IPsec is. Since we are violating modularity by creating a virtual link layer, we need to provide link layer services within IPsec. 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 Theodore Y. Ts'o > Sent: Friday, April 14, 2000 3:02 PM > To: Stephane Beaulieu > Cc: Cary Y. Tsai; ipsec@lists.tislabs.com > Subject: Re: XAUTH question > > > From: "Stephane Beaulieu" > Date: Fri, 14 Apr 2000 09:12:40 -0400 > > The draft expired a short time ago. It will be > republished shortly. Sorry > for the inconvenience. > > If you're referring to the following draft: > > >Internet Engineering Task Force R. Pereira, > TimeStep Corp. > >IP Security Working Group S. Anand, > Microsoft Corp. > >Internet Draft B. Patel, > Intel Corp. > >Expires in six months > > > August 17, 1999 > > > > The ISAKMP Configuration Method > > > > > It is currently *not* an IPSEC working group work item, as the > functionality discussed is in the domain of the IPSRA (IPSEC Remote > Access) working group. They're currently working on > requirements to see > what's the best way of solving that set of issues, of which ISAKMP > Configuration Method is but one contender. > > If you want to base something on ISAKMP Configuration Method which is > not in the IPSRA domain, that can certainly be discussed, although any > expansion of the IPSEC wg's charter requires the approval of the > Security Area Directors, and they have a marked bias towards > *not* make > IPSEC protocol suite more complicated at this time. However, > if there's > strong consensus in the working group do work on such an item, we can > certainly take that request to the AD's. > > (BTW, the same goes for the heartbeats proposal --- I am > still not sure > I'm seeing strong consensus that we actually need do need to > standardize > a heartbeat protocol. There's still discussion going on about > *whether* some new protocol is needed to solve this problem, > and if so, > what the general shape of that protocol should be. I encourage that > discussion to continue, especially focused on that first point, since > we'll need strong arguments to take to the IESG to approve letting us > expand our charter to take on this new work item.) > > - Ted > From owner-ipsec@lists.tislabs.com Mon Apr 17 13:40: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 NAA08863; Mon, 17 Apr 2000 13:40:52 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02881 Mon, 17 Apr 2000 15:41:31 -0400 (EDT) Message-Id: <4.3.2.20000417123854.04e3a560@mail.vpnc.org> X-Sender: phoffvpnc@mail.vpnc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 17 Apr 2000 12:49:48 -0700 To: , "'Theodore Y. Ts'o'" , From: Paul Hoffman Subject: RE: XAUTH question In-Reply-To: <002a01bfa8a2$262dd750$59daa8c0@andrewktest.timestep.com> References: <4.3.2.20000414154822.00e34350@mail.vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:21 PM 4/17/00 -0400, Andrew Krywaniuk wrote: >Actually, I don't believe there is a consensus among WG members that adding >a new mode is actually a change to IKE. This has always been a hotly debated >issue. As I have said before, it's not up to the WG: it's up to the Area Directors. The actual words in the IPSRA charter are: "The WG strongly prefers mechanisms that require no changes to AH, ESP or IKE protocols. If such changes are deemed necessary, the IPSec WG is contracted to carry out such changes. Pursuing this approach is most likely to produce mechanisms that are easy to implement and deploy." >What exactly is a "change" to IKE? There is no exact definition of change. As you say, some people think that adding a mode doesn't change IKE. Note that many others disagree. >Does it differ from an "extension" to IKE? This is splitting hairs. >Does it differ from a change/extension to ISAKMP? This is splitting hairs even thinner. >IKE stands for Internet Key Exchange. How far do we want to stretch this? If >someone defines a new ISAKMP mode that has nothing to do with exchanging >keys, then why would it be considered a change to IKE? Good question. But, before we spend more time answering it, please remember that the reason we're at this point at all is that the IPsec WG is trying to wind down. The endless debates in the IPsec WG about how to make IPsec-as-a-system work for remote access users has delayed the WG from closing. Thus, the IPSRA WG was formed. When you form a WG in such circumstances, it is wise to require that we try really, really hard to avoid the previous mess. If the IPSRA WG can't come up with a solution that is as good as any of the many competing solutions that were debated in the IPSEC WG, we can go back to the Area Director and ask for a charter change. Speaking as one of the two co-chairs, I don't believe that we are there yet. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Apr 17 13: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 NAA09242; Mon, 17 Apr 2000 13:54:29 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA02951 Mon, 17 Apr 2000 15:54:03 -0400 (EDT) Message-ID: <004201bfa8a7$80cb5fc0$695545ab@cisco.com> From: "S Ramakrishnan" To: , , "Tim Jenkins" , "Leo Temoshenko" References: <310508EDF557D31188FA0050DA0A37522CC14E@CAT01S2> Subject: Re: IPsecMIB Date: Mon, 17 Apr 2000 12:59:55 -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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi - From: Tim Jenkins Sent: Monday, April 17, 2000 5:54 AM >Textual Conventions: >IPsec Monitoring: >ISAKMP DOI-ind. Monitoring: >IKE Monitoring: >The authors of the MIB referred to below were asked if they >were interested in modifying it to use the base MIBs listed above; >I don't recall there being any response to that. I do not recall a discussion to this effect in this list. Perhaps I missed it. What specific changes would you suggest? We have included the TCs proposed in draft-ietf-ipsec-doi-tc-mib-02.txt. Thanks, Rk From owner-ipsec@lists.tislabs.com Mon Apr 17 14:13: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 OAA09572; Mon, 17 Apr 2000 14:13:25 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03093 Mon, 17 Apr 2000 16:17:00 -0400 (EDT) Message-ID: <38FB7298.FDB80500@redcreek.com> Date: Mon, 17 Apr 2000 13:22:48 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: akrywani@newbridge.com CC: "'Paul Hoffman'" , "'Theodore Y. Ts'o'" , ipsec@lists.tislabs.com Subject: Re: XAUTH question References: <002a01bfa8a2$262dd750$59daa8c0@andrewktest.timestep.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Comments below. Andrew Krywaniuk wrote: > > Hi Paul, > > Actually, I don't believe there is a consensus among WG members that adding > a new mode is actually a change to IKE. This has always been a hotly debated > issue. > > Several questions arise: > > What exactly is a "change" to IKE? > Does it differ from an "extension" to IKE? > Does it differ from a change/extension to ISAKMP? > > IKE stands for Internet Key Exchange. How far do we want to stretch this? If > someone defines a new ISAKMP mode that has nothing to do with exchanging > keys, then why would it be considered a change to IKE? If someone defined a new ISAKMP mode which had nothing to do with exchanging ipsec-related keys, this would obviously have nothing to do with IKE. However, both mode-cfg and xauth have *much* to do with exchanging ipsec-related keys. The bottom line? mode-cfg duplicates dhcp functionality at the expense of increasing the complexity of IKE (and for no good reason), and hence is not required. It is not clear whether an xauth-like mechanism is required for remote access or not, but if it is, there is certainly no justification for binding it to an unneeded extension such as mode-cfg. It has been clear for some time now that modifications to IKE for the purpose of remote access have not been entirely ruled out, but that rather, if the ipsra wg deems that such an extension is the best way to proceed, such extending will be done under the auspices of the ipsec working group. Scott From owner-ipsec@lists.tislabs.com Mon Apr 17 14:18: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 OAA09619; Mon, 17 Apr 2000 14:18:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA03132 Mon, 17 Apr 2000 16:19:31 -0400 (EDT) Message-ID: <310508EDF557D31188FA0050DA0A37522CC155@CAT01S2> From: Tim Jenkins To: "'S Ramakrishnan'" , ipsec@lists.tislabs.com, Leo Temoshenko Subject: RE: IPsecMIB Date: Mon, 17 Apr 2000 16:26:33 -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 [I've removed l2tp from the response; feel free to add it back if necessary...] Here are my original comments on the first release of the flow monitoring MIB. See the last full paragraph. Ted was the only one who responded to this mail, other than some agreement that we need an application specific MIB. ==> To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-flow-monitoring-mib-00.txt From: Tim Jenkins Date: Thu, 25 Nov 1999 15:03:01 -0500 Sender: owner-ipsec@lists.tislabs.com ---------------------------------------------------------------------------- ---- I have a number of concerns about this document, right from the process level down to the detailed. First, there was concern that the WG should even be doing an application specific MIB for IPsec. I believe there was a vote, but unfortunately, I can't remember the exact question that Ted asked, but I believe there was no clear consensus on whatever it was. Therefore, before I make further comments on this document, I'd like to re-open the question (Ted, stop me if I shouldn't be doing this). Should the WG be developing a VPN/Remote Access application-specific MIB for IPsec? (I choose VPN/remote access since they seem to be the primary applications for IPsec and they're the primary focus of this document, and also of the one I presented over a year ago.) If so, then we need to decide on the features and requirements. I believe this document at a high level is a good start, but I also believe it is missing some things that will make it useful for both VPN and remote access. Then, if the WG is to proceed, I'd like to ask the authors of this document to consider adapting this document to use the textual conventions, IPsec, ISAKMP and IKE monitoring MIBs already in development, in addition to modifying it to add any features the WG thinks are missing. Comments? Tim --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 <== I also spoke publicly about this when it was first presented at an IETF. > -----Original Message----- > From: S Ramakrishnan [mailto:rks@cisco.com] > Sent: Monday, April 17, 2000 4:00 PM > To: l2tp@ipsec.org; ipsec@lists.tislabs.com; Tim Jenkins; Leo > Temoshenko > Subject: Re: IPsecMIB > > > Hi - > > From: Tim Jenkins > Sent: Monday, April 17, 2000 5:54 AM > > >Textual Conventions: > >IPsec Monitoring: >ISAKMP DOI-ind. Monitoring: >IKE Monitoring: >The authors of the MIB referred to below were asked if they >were interested in modifying it to use the base MIBs listed above; >I don't recall there being any response to that. I do not recall a discussion to this effect in this list. Perhaps I missed it. What specific changes would you suggest? We have included the TCs proposed in draft-ietf-ipsec-doi-tc-mib-02.txt. Thanks, Rk From owner-ipsec@lists.tislabs.com Mon Apr 17 17:34: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 RAA11971; Mon, 17 Apr 2000 17:34:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03747 Mon, 17 Apr 2000 19:25:26 -0400 (EDT) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Hoffman'" , "'Theodore Y. Ts'o'" , Subject: RE: XAUTH question Date: Mon, 17 Apr 2000 19:29:36 -0400 Message-Id: <002e01bfa8c4$cbfe24b0$59daa8c0@andrewktest.timestep.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <4.3.2.20000417123854.04e3a560@mail.vpnc.org> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Paul, It is for exactly these reasons -- 1. the IPsec WG is supposed to be winding down 2. related WGs don't have permission to change IKE (and by extension ISAKMP) 3. we can't all agree on what exactly constitutes a change to IKE -- that we need to have a standardized generic attribute exchange like Config Mode available. If this means taking Config Mode, stripping out all the DHC stuff and calling it something like Negotiation Mode or Attribute Exchange Mode then we should do that. If adding a mode automatically represents a change to IKE then we need to do this before the WG disbands. That way, we can add non-KE-related attributes without changing ISAKMP syntactically (and then we can argue about whether they change IKE operationally). It is almost a given that any DHC mechanism is going to change IKE operationally. Presumably, the ADs are going to interpret the clause in the IPSRA charter as meaning changing IKE syntactically. We need to avoid limiting the scope IPSRA solutions by adding an attribute exchange mode ahead of time. By doing this now, we allow the possibility for IPSRA hosts to exchange information without having to change any of the IPsec drafts. We could even take a range of numbers from the attribute number space and call them "reserved to IPSRA". (Or we could create a separate DOI, but that seems like overkill.) Andrew -------------------------------------- Beauty with out truth is insubstantial. Truth without beauty is unbearable. > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Monday, April 17, 2000 3:50 PM > To: akrywani@newbridge.com; 'Theodore Y. Ts'o'; > ipsec@lists.tislabs.com > Subject: RE: XAUTH question > > > At 03:21 PM 4/17/00 -0400, Andrew Krywaniuk wrote: > >Actually, I don't believe there is a consensus among WG > members that adding > >a new mode is actually a change to IKE. This has always been > a hotly debated > >issue. > > As I have said before, it's not up to the WG: it's up to the Area > Directors. The actual words in the IPSRA charter are: > > "The WG strongly prefers mechanisms that require no changes > to AH, ESP or > IKE protocols. If such changes are deemed necessary, the IPSec WG is > contracted to carry out such changes. Pursuing this approach > is most likely > to produce mechanisms that are easy to implement and deploy." > > >What exactly is a "change" to IKE? > > There is no exact definition of change. As you say, some > people think that > adding a mode doesn't change IKE. Note that many others disagree. > > >Does it differ from an "extension" to IKE? > > This is splitting hairs. > > >Does it differ from a change/extension to ISAKMP? > > This is splitting hairs even thinner. > > >IKE stands for Internet Key Exchange. How far do we want to > stretch this? If > >someone defines a new ISAKMP mode that has nothing to do > with exchanging > >keys, then why would it be considered a change to IKE? > > Good question. But, before we spend more time answering it, > please remember > that the reason we're at this point at all is that the IPsec > WG is trying > to wind down. The endless debates in the IPsec WG about how to make > IPsec-as-a-system work for remote access users has delayed > the WG from > closing. Thus, the IPSRA WG was formed. When you form a WG in such > circumstances, it is wise to require that we try really, > really hard to > avoid the previous mess. If the IPSRA WG can't come up with a > solution that > is as good as any of the many competing solutions that were > debated in the > IPSEC WG, we can go back to the Area Director and ask for a > charter change. > Speaking as one of the two co-chairs, I don't believe that we > are there yet. > > --Paul Hoffman, Director > --VPN Consortium > > From owner-ipsec@lists.tislabs.com Tue Apr 18 08:59: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 IAA05498; Tue, 18 Apr 2000 08:59:42 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08784 Tue, 18 Apr 2000 10:25:30 -0400 (EDT) From: antonio.barrera@nokia.com Message-ID: <0B3F42CA1FB6D2118FE50008C7894B0A02E37345@eseis06nok> To: ipsec@lists.tislabs.com Subject: RE: Query : RFC 2407 Date: Tue, 18 Apr 2000 17:31:13 +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 Yes. In phase 2. Port and protocol are used to negotiated specific SAs for a port of Protocol. For example negotiate a SA to send encrypted TCP packets only would define protocol TCP(6) The same for the port. If you want an SA to protect HTTP trafic then you would define the port used by HTTP (8080 I think) BR, Toni Barrera -----Original Message----- From: EXT Ruheena Rashid [mailto:ruheenar@future.futsoft.com] Sent: 17. April 2000 15:39 To: 'ddp@network-alchemy.com' Cc: ipsec@lists.tislabs.com Subject: Query : RFC 2407 Hello RFC 2407 states that - "The Identification Payload is used to identify the initiator of the Security Association. The identity of the initiator SHOULD be used by the responder to determine the correct host system security policy requirement for the association. For example, a host might choose to require authentication and integrity without confidentiality (AH) from a certain set of IP addresses and full authentication with confidentiality (ESP) from another range of IP addresses. The Identification Payload provides information that can be used by the responder to make this decision. During Phase I negotiations, the ID port and protocol fields MUST be set to zero or to UDP port 500." Does this mean that in phase 2 negotiations, the port and protocol fields can be set to some value other than UDP port 500, which can be used for phase 2 negotiation ? Regards Ruheena Rashid. From owner-ipsec@lists.tislabs.com Tue Apr 18 09:28: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 JAA05894; Tue, 18 Apr 2000 09:28:16 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09002 Tue, 18 Apr 2000 11:12:12 -0400 (EDT) Message-ID: <07E816C410ECD311BBEE00C04FA14BCF0C5DF5@BRISCO> From: "Baugher, Mark" To: ipsec@lists.tislabs.com Subject: RE: XAUTH question Date: Tue, 18 Apr 2000 08:19: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 Hi > > It is for exactly these reasons -- > > 1. the IPsec WG is supposed to be winding down > 2. related WGs don't have permission to change IKE (and by > extension ISAKMP) IKAKMP is intended to be changed for new applications. How can there be such a prohibition on ISAKMP? Mark From owner-ipsec@lists.tislabs.com Tue Apr 18 18:56: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 SAA22550; Tue, 18 Apr 2000 18:56:21 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11607 Tue, 18 Apr 2000 20:26:31 -0400 (EDT) Message-ID: <38FCFEBF.3EDB190E@cisco.com> Date: Tue, 18 Apr 2000 20:33:03 -0400 From: Nalini Kumar Danda Reply-To: dnkumar@cisco.com Organization: Cisco Systems Inc X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: solaris8 ipsec Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Can anyone help me in configuring solaris 8 box for ipsec ? I could not install encrkey using "ipseckey" command. I tried the following example that was given at the end of ipseckey man pages in solaris 8. add esp spi 0x2112 src me.domain.com dst you.domain.com \ authalg md5 authkey bde359723576fdea08e56cbe876e24ad \ encralg des encrkey be02938e7def2839 hard_usetime 28800 add esp spi 0x5150 src you.domain.com dst me.domain.com \ authalg md5 authkey 930987dbe09743ade09d92b4097d9e93 \ encralg des encrkey 8bd4a52e10127deb hard_usetime 28800 it shows an error, 'one of entered the values is incorrect'. System error on the line that has 'encralg' in the above example. I am running beta version of Solaris8. thanks, -Nalini Kumar. From owner-ipsec@lists.tislabs.com Tue Apr 18 19:05: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 TAA23684; Tue, 18 Apr 2000 19:05:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11614 Tue, 18 Apr 2000 20:28:30 -0400 (EDT) X-Virus-Scanned: Tue, 18 Apr 2000 17:08:25 -0700 Nokia Silicon Valley Email Exploit Scanner Message-ID: <38FCFF2B.886569B1@iprg.nokia.com> Date: Tue, 18 Apr 2000 17:34:51 -0700 From: Marc Solsona Palomar X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: antonio.barrera@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: Query : RFC 2407 References: <0B3F42CA1FB6D2118FE50008C7894B0A02E37345@eseis06nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Oh, guru! default HTTP port = 80. antonio.barrera@nokia.com wrote: > > Yes. > In phase 2. Port and protocol are used to negotiated specific SAs for a port > of Protocol. > For example negotiate a SA to send encrypted TCP packets only would define > protocol TCP(6) > The same for the port. If you want an SA to protect HTTP trafic then you > would define the port used by HTTP (8080 I think) > BR, > > Toni Barrera > > -----Original Message----- > From: EXT Ruheena Rashid [mailto:ruheenar@future.futsoft.com] > Sent: 17. April 2000 15:39 > To: 'ddp@network-alchemy.com' > Cc: ipsec@lists.tislabs.com > Subject: Query : RFC 2407 > > Hello > > RFC 2407 states that - > "The Identification Payload is used to identify the initiator of the > Security Association. The identity of the initiator SHOULD be used by the > responder to determine the correct host system security policy requirement > for the association. For example, a host might choose to require > authentication and integrity without confidentiality (AH) from a certain > set of IP addresses and full authentication with confidentiality (ESP) from > another range of IP addresses. The Identification Payload provides > information that can be used by the responder to make this decision. > During Phase I negotiations, the ID port and protocol fields MUST be set to > zero or to UDP port 500." Does this mean that in phase 2 negotiations, the > port and protocol fields can be set to some value other than UDP port 500, > which can be used for phase 2 negotiation ? > > Regards > Ruheena Rashid. From owner-ipsec@lists.tislabs.com Wed Apr 19 20:25: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 UAA03405; Wed, 19 Apr 2000 20:25:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA16496 Wed, 19 Apr 2000 21:42:38 -0400 (EDT) Date: Thu, 20 Apr 2000 09:47:58 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@arizona To: Brian Swander cc: ipsec@lists.tislabs.com Subject: RE: Win2k IKE In-Reply-To: <19398D273324D3118A2B0008C7E9A56908BD2536@SIT.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks, Brian. A further question. What are the functions or API used in Win2k for IPSec encryption and hash operations? Jianying Zhou On Mon, 17 Apr 2000, Brian Swander wrote: > ike and ipsec are in all flavors of win2k. > > bs > > -----Original Message----- > From: Jianying Zhou [mailto:jyzhou@krdl.org.sg] > Sent: Sunday, April 16, 2000 6:33 PM > To: ipsec@lists.tislabs.com > Subject: Win2k IKE > > > Hi, > > Does anyone know whether IKE and IPsec are supported in all Win2k versions, > that is professional, server, and advanced server versions? > > Thanks. > > Jianying Zhou > From owner-ipsec@lists.tislabs.com Thu Apr 20 06:34: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 GAA01697; Thu, 20 Apr 2000 06:34:20 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18325 Thu, 20 Apr 2000 08:18:27 -0400 (EDT) Date: Thu, 20 Apr 2000 00:56:25 -0700 (PDT) From: Jeffrey Lo To: ipsec@lists.tislabs.com cc: jlo@ccrl.sj.nec.com Subject: Responding to Phase 2 request Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have the following questions, please kind me clarify them. Q1. Suppose I have a network configured as such H1 H2 G1 H3---SG1=========SG2----G2 H4 G3 H5 The security policy of SG1 is configured such that communication between all H* and G* must be protected by DES-ESP. Security policy of SG2 is configured such that communication between all H* and G* must also be protected by DES-ESP except that it denies communication between H* and G1. When SG1 initiates a phase 2 exchange on behalf of subnet H, i.e. with ID information having subnet of H* as src subnet and subnet of G* as dest subnet, which of the following should SG2 do? 1. Deny the request, since G1 is not allowed to communicate with H* and SG1 is negotiating on behalf of H*. 2. Accept the request and respond with a response message having the ID information which is a subset of that request, i.e. src subnet H* but dest subnet (G1 and G2)? Q2. In addition to the conditions of Q1, suppose security policy on SW2 dictates that communication between G2 and H* must use 3DES. Upon receiving the phase 2 request, should SG2 1. Deny the request, again for the same reason as above. 2. Accept the request and respond with a response message having the ID information which consist of src subnet H* but dest subnet (only G1) since to SG2, communication between G2 and H* cannot fall under the protection level requested by SG1. Please clarify. Thanks. Jeffrey Lo From owner-ipsec@lists.tislabs.com Thu Apr 20 10:09:23 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05387; Thu, 20 Apr 2000 10:09:22 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA19127 Thu, 20 Apr 2000 11:51:15 -0400 (EDT) Message-ID: <38FF2935.D2663665@redcreek.com> Date: Thu, 20 Apr 2000 08:58:45 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Lo CC: ipsec@lists.tislabs.com Subject: Re: Responding to Phase 2 request References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jeffrey, Good questions. Comments below. Jeffrey Lo wrote: > > Hi, > > I have the following questions, please kind me clarify them. > > Q1. > Suppose I have a network configured as such > > H1 > H2 G1 > H3---SG1=========SG2----G2 > H4 G3 > H5 > > The security policy of SG1 is configured such that communication between > all H* and G* must be protected by DES-ESP. > > Security policy of SG2 is configured such that communication between all > H* and G* must also be protected by DES-ESP except that it denies > communication between H* and G1. > > When SG1 initiates a phase 2 exchange on behalf of subnet H, i.e. with > ID information having subnet of H* as src subnet and subnet of G* as dest > subnet, which of the following should SG2 do? > > 1. Deny the request, since G1 is not allowed to communicate with H* and > SG1 is negotiating on behalf of H*. > 2. Accept the request and respond with a response message having the > ID information which is a subset of that request, i.e. src subnet H* but > dest subnet (G1 and G2)? To be strictly compliant, I think that (1) would be the correct response. If IKE were able to negotiate lists of ip addresses and/or lists of subnets (or some sort of subnet notch filter), this would not be the case. Since it is not currently permissible for the responder to alter the proposal, I don't think (2) would fly. On the other hand, there is nothing which prevents SG2 from sending a notify message which details the policy mismatch. An alternative which is not currently compliant, but which solves this problem from a practical standpoint, would be to have a rule on SG2's inside interface which blocks traffic from G1, and then accept the subnet on the outer interface. In this case, if a packet from G1 emerged from the tunnel, it would be blocked prior to exiting onto H*. > Q2. > In addition to the conditions of Q1, suppose security policy on SW2 > dictates that communication between G2 and H* must use 3DES. Upon > receiving the phase 2 request, should SG2 > > 1. Deny the request, again for the same reason as above. > 2. Accept the request and respond with a response message having the ID > information which consist of src subnet H* but dest subnet (only G1) since > to SG2, communication between G2 and H* cannot fall under the protection > level requested by SG1. > Again, I think that a desire for strict compliance would force you to select (1). This is one of the reasons I'd like to see IKE re-opened in the ipsec group. Quite some time ago I suggested (along with others) that address lists, subnet lists, notch filters and other identity aggregators would be very useful in IKE. Scott From owner-ipsec@lists.tislabs.com Thu Apr 20 12:06: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 MAA06883; Thu, 20 Apr 2000 12:06:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19611 Thu, 20 Apr 2000 13:46:19 -0400 (EDT) Message-ID: <38FF4434.AEBDC274@redcreek.com> Date: Thu, 20 Apr 2000 10:53:56 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Lo CC: ipsec@lists.tislabs.com Subject: Re: Responding to Phase 2 request References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Jeffrey, Jeffrey Lo wrote: > > Scott, > > Thanks for the response. > > You mentioned having SG2 sending a notify message to SG1 regarding the > policy mismatch. What is such a notify message to be sent? Is there one > defined? > > Jeffrey Lo There is one defined in http://www.ietf.org/internet-drafts/draft-ietf-ipsec-notifymsg-02.txt In this case, you would send NO_PROPOSAL_CHOSEN. The draft suggests the following for the notify data: o Notification Data - SHOULD contain the message ID of the offending negotiation, and MAY contain error text describing the problem. MAY also contain a proposal suggestion. Note that no formal definition has been given to the "proposal suggestion" at this time. If there is sufficient interest in this, we could more completely define this. Scott From owner-ipsec@lists.tislabs.com Thu Apr 20 12:08:07 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06917; Thu, 20 Apr 2000 12:08:04 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19635 Thu, 20 Apr 2000 13:49:36 -0400 (EDT) Message-ID: <38FF44F2.DD28E592@redcreek.com> Date: Thu, 20 Apr 2000 10:57:06 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Lo CC: ipsec@lists.tislabs.com Subject: Re: Responding to Phase 2 request References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As a matter of clarification, I said > An alternative which is not currently compliant, but which solves this > problem from a practical standpoint, would be to have a rule on SG2's > inside interface which blocks traffic from G1, and then accept the > subnet on the outer interface. In this case, if a packet from G1 emerged > from the tunnel, it would be blocked prior to exiting onto H*. After giving this some more thought, I don't see any reason why this approach would not be compliant with RFC2401. Scott From owner-ipsec@lists.tislabs.com Thu Apr 20 12:19: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 MAA07064; Thu, 20 Apr 2000 12:19:13 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19780 Thu, 20 Apr 2000 14:15:48 -0400 (EDT) From: "Jeffrey Lo" To: "Scott G. Kelly" Cc: Subject: RE: Responding to Phase 2 request Date: Thu, 20 Apr 2000 10:37:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <38FF2935.D2663665@redcreek.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott, Thanks for the response. You mentioned having SG2 sending a notify message to SG1 regarding the policy mismatch. What is such a notify message to be sent? Is there one defined? Jeffrey Lo -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Thursday, April 20, 2000 8:59 AM To: Jeffrey Lo Cc: ipsec@lists.tislabs.com Subject: Re: Responding to Phase 2 request Hi Jeffrey, Good questions. Comments below. Jeffrey Lo wrote: > > Hi, > > I have the following questions, please kind me clarify them. > > Q1. > Suppose I have a network configured as such > > H1 > H2 G1 > H3---SG1=========SG2----G2 > H4 G3 > H5 > > The security policy of SG1 is configured such that communication between > all H* and G* must be protected by DES-ESP. > > Security policy of SG2 is configured such that communication between all > H* and G* must also be protected by DES-ESP except that it denies > communication between H* and G1. > > When SG1 initiates a phase 2 exchange on behalf of subnet H, i.e. with > ID information having subnet of H* as src subnet and subnet of G* as dest > subnet, which of the following should SG2 do? > > 1. Deny the request, since G1 is not allowed to communicate with H* and > SG1 is negotiating on behalf of H*. > 2. Accept the request and respond with a response message having the > ID information which is a subset of that request, i.e. src subnet H* but > dest subnet (G1 and G2)? To be strictly compliant, I think that (1) would be the correct response. If IKE were able to negotiate lists of ip addresses and/or lists of subnets (or some sort of subnet notch filter), this would not be the case. Since it is not currently permissible for the responder to alter the proposal, I don't think (2) would fly. On the other hand, there is nothing which prevents SG2 from sending a notify message which details the policy mismatch. An alternative which is not currently compliant, but which solves this problem from a practical standpoint, would be to have a rule on SG2's inside interface which blocks traffic from G1, and then accept the subnet on the outer interface. In this case, if a packet from G1 emerged from the tunnel, it would be blocked prior to exiting onto H*. > Q2. > In addition to the conditions of Q1, suppose security policy on SW2 > dictates that communication between G2 and H* must use 3DES. Upon > receiving the phase 2 request, should SG2 > > 1. Deny the request, again for the same reason as above. > 2. Accept the request and respond with a response message having the ID > information which consist of src subnet H* but dest subnet (only G1) since > to SG2, communication between G2 and H* cannot fall under the protection > level requested by SG1. > Again, I think that a desire for strict compliance would force you to select (1). This is one of the reasons I'd like to see IKE re-opened in the ipsec group. Quite some time ago I suggested (along with others) that address lists, subnet lists, notch filters and other identity aggregators would be very useful in IKE. Scott From owner-ipsec@lists.tislabs.com Mon Apr 24 12:45: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 MAA09301; Mon, 24 Apr 2000 12:45:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02978 Mon, 24 Apr 2000 14:04:52 -0400 (EDT) Message-ID: From: "Linn, John" To: ipsec@lists.tislabs.com Subject: RE: AES draft query Date: Mon, 24 Apr 2000 14:11:59 -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 Last month, Hilarie wrote, excerpting: > > These issues are discussed in > draft-orman-public-key-lengths-00.txt > on which commentary is solicited. > > Hilarie > > >>> "Linn, John" 03/16/00 11:17AM >>> > Jesse, > ... > An RSA Laboratories paper with further > analysis on > key size issues is now being finalized for web publication, > probably within > the next couple of weeks; I'll post a citation when it's available. > > --jl > This is indeed an important area for consideration and discussion; my thanks to Hilarie and Paul for their work on it in draft-orman-public-key-lengths-00.txt. As another input, I'd like to point out that the RSA Laboratories paper I forward-referenced earlier on this thread, "A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths", by Robert Silverman, is now available on http://www.rsasecurity.com/rsalabs/bulletins/index.html as Bulletin #13. Among other aspects, it seeks to evaluate the costs of factoring attacks as a combination of processor time and memory requirements; for example, its comparison indicates that the NFS sieving phase for a 1024-bit number should take 7 million times the processor effort as did RSA-512, on a network of processors each equipped with 2650 times the memory needed for RSA-512 sieving, or about 170 Gbytes. --jl From owner-ipsec@lists.tislabs.com Tue Apr 25 06:42:35 2000 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06396; Tue, 25 Apr 2000 06:42:34 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06768 Tue, 25 Apr 2000 08:11:42 -0400 (EDT) Date: Mon, 24 Apr 2000 22:22:06 -0400 From: Jerome Etienne To: ipsec@lists.tislabs.com Subject: attack on ip header mutable fields ? Message-ID: <20000424222206.A915@long-haul.net> Reply-To: jetienne@arobas.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi I would like to know if there is any attack based on how AH process the ip header, expecially the mutable fields ? What are the consequences/dangers if an attacker change this mutable field ? If this has been studied i am interested in any reference you may give me. thanks From owner-ipsec@lists.tislabs.com Tue Apr 25 07:11: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 HAA06793; Tue, 25 Apr 2000 07:10:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06899 Tue, 25 Apr 2000 09:06:50 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: jetienne@arobas.net Cc: ipsec@lists.tislabs.com Subject: Re: attack on ip header mutable fields ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Apr 2000 09:13:55 -0400 Message-Id: <20000425131356.DA72235DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20000424222206.A915@long-haul.net>, Jerome Etienne writes: >Hi > >I would like to know if there is any attack based on how AH process the >ip header, expecially the mutable fields ? What are the consequences/dangers >if an attacker change this mutable field ? If this has been studied i am >interested in any reference you may give me. I doubt that there are any useful attacks *unless* the attacker uses source routing and you use address-based authentication for trust and don't match the IP address against the certificate. Of course, as many people on this list know, I don't think it's important to protect any of the fields in the IP header is useful, so leaving a few unprotected doesn't matter to me. --Steve Bellovin From owner-ipsec@lists.tislabs.com Wed Apr 26 07:25: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 HAA13709; Wed, 26 Apr 2000 07:25:01 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA13430 Wed, 26 Apr 2000 08:49:10 -0400 (EDT) Message-ID: <20000426080025.20994.qmail@hotmail.com> X-Originating-IP: [196.1.109.11] From: "sudha malhotra" To: ipsec@lists.tislabs.com Date: Wed, 26 Apr 2000 08:00:25 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi friends, Here r some questions 1. Aggerssive mode of IKE maps to Aggressive exchange in ISAKMP. Last message of aggressive exchange is encrypted but in IKE It is not encrypted. why is it so? 2. Situation field is present in ISAKMP header. There r three types integrity, secrecy, identity. I can have all of these right? or one of them? and whether I ahve to specify it in policy? I mean from where value for this field is taken? Thanks ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-ipsec@lists.tislabs.com Wed Apr 26 07:42: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 HAA14005; Wed, 26 Apr 2000 07:42:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA13689 Wed, 26 Apr 2000 09:28:14 -0400 (EDT) Message-ID: <001101bfaf83$eac4b600$2fcd09c0@cdac.ernet.in> Reply-To: "pradnya kulkarni" From: "pradnya kulkarni" To: Subject: What info goes in KE payload when using authenticatoin using pre-shared key in ike (phase1- main mode)? Date: Wed, 26 Apr 2000 19:02:45 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01BFAFB2.01749400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000C_01BFAFB2.01749400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IKE phase 1 : Authentication using pre-shared key main mode : RFC says exchanges are initiator responder HDR, SA - -> < -- HDR, SA HDR , KE, NI ---> HDR, KE, Nr, and other messages follows.. Now my question is what info goes in Key Exchange (KE) payload? Is it nessary to negotiate KE payload in first place since it is pre = shared key=20 authentication keys are with initiator and responder ?=20 ------=_NextPart_000_000C_01BFAFB2.01749400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IKE phase 1 : Authentication using = pre-shared=20 key
main mode :
RFC says exchanges are
initiator     =    =20             =    =20         responder
 HDR, SA    -=20 ->
       =20            <=20 --            =    =20     HDR, SA
HDR , KE, NI  = --->
       =20             =    =20             =    =20     HDR, KE, Nr,
 
and other messages = follows..
 
Now my question is what info goes in = Key Exchange=20 (KE) payload?
Is it nessary to negotiate KE payload = in first=20 place since it is pre shared key
authentication keys are with initiator = and=20 responder ?
 
------=_NextPart_000_000C_01BFAFB2.01749400-- From owner-ipsec@lists.tislabs.com Wed Apr 26 09:34: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 JAA15644; Wed, 26 Apr 2000 09:34:09 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA14092 Wed, 26 Apr 2000 11:12:26 -0400 (EDT) Message-Id: <200004261521.KAA05174@jumpsrv.stp.securecomputing.com> X-Mailer: exmh version 1.6.9 8/22/96 To: ipsec@lists.tislabs.com Subject: Default and Variable Key Lengths Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Apr 2000 10:21:55 -0500 From: Mike Carney Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We ran into an interoperability issue with CAST 128 and key lengths that we would like to run past the group. RFC 2451 (ESP CBC-MODE Cipher Algorithms) list default key lengths for the variable key sized algorithms, what is this to be used for? RFC 2407 (IPSEC DOI) under Section 4.5 Security attributes has the following: Key Length Reserved 0 There is no default value for Key Length, as it must be specified for transforms using ciphers with variable key lengths. For fixed length ciphers, the Key Length attribute MUST NOT be sent. The interoperabiltiy issue was that the vendor interpreted 2451's default key length to be: If no key length is sent for the QM exchange, use the default value per 2451 Is this the generally accepted practice? We intend to modify our implementation to accept this interpretation in responder role, but unless this is the defacto standard behavior we do not intend to modify our specification of key length in initator role. (We are aware of the rekeying issues that this may raise) Regards, Michael Carney - Secure Computing Corporation From owner-ipsec@lists.tislabs.com Thu Apr 27 07:18: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 HAA14757; Thu, 27 Apr 2000 07:18:19 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18753 Thu, 27 Apr 2000 08:31:37 -0400 (EDT) Message-ID: <001601bfaffe$0ff54730$2fcd09c0@cdac.ernet.in> Reply-To: "pradnya kulkarni" From: "pradnya kulkarni" To: Subject: 1.Aggerssive mode of IKE maps to Aggressive exchange in ISAKMP Last msg of aggresive exchange is encrypted but in IKe it is not encrpyed why is so?. Date: Thu, 27 Apr 2000 09:37:04 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01BFB02C.25D3F280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0013_01BFB02C.25D3F280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1.Aggressive mode of IKE maps to Aggressive exchange in ISAKMP. Last message of aggressive exchange is encrypted but in IKE=20 It is not encrypted. why is it so? 2. Situation field is present in ISAKMP header. There r three types integrity, secrecy, identity. I can have all of these right?=20 ------=_NextPart_000_0013_01BFB02C.25D3F280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
1.Aggressive mode of IKE maps to = Aggressive=20 exchange in ISAKMP.
Last message of aggressive exchange is encrypted = but in=20 IKE
It is not encrypted. why is it so?
 
2. Situation field is present in ISAKMP = header.
There r three types integrity, secrecy, identity.
I can = have all=20 of these right?
------=_NextPart_000_0013_01BFB02C.25D3F280-- From owner-ipsec@lists.tislabs.com Thu Apr 27 07:18: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 HAA14758; Thu, 27 Apr 2000 07:18:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA18739 Thu, 27 Apr 2000 08:30:38 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 X-Exmh-Isig-CompType: unknown X-Exmh-Isig-Folder: to-smb From: Steve Bellovin To: cryptography@c2.net Subject: key agility and IPsec Cc: ipsec@lists.tislabs.com Reply-To: cryptography@c2.net Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1097001440" Date: Wed, 26 Apr 2000 19:50:10 -0400 Message-Id: <20000426235010.4A04A35DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart MIME message. --==_Exmh_1097001440 Content-Type: text/plain (Note to ipsec@ readers -- this is a follow-up to a discussion on the cryptography list a week or so ago. To spare folks who subscribe to both, I've directed followups to the cryptography list ONLY. Subscription to it is via majordomo@c2.net.) ---- Following my exchange of notes with Ron Rivest on key agility for IPsec, I decided to gather some real data. I used a monitoring station on the plaintext side of one of our IPsec gateways to gather 7,000,000 packets in three sessions, two afternoon and one evening. Note carefully that this experiment is preliminary and small-scale. That particular gateway is a Linux box running FreeSWAN; it serves about 180 homes running Linux IPsec appliances (for details on the setup, see http://www.quintillion.com/moat/lisa-moat.ps or .pdf). Most of our endpoints have high-quality (i.e., short path) connections to the gateway. Packet headers were captured via tcpdump; lacking access to the ciphertext (and hence the SPI), I intuited the SA from the remote IP address and knowledge of our address assignment plan. Thus, since most people are assigned /29s, I assumed that I could mask off the low-order three bits of IP addresses in that range and get the security association. I split the received traffic depending on whether the gateway was encrypting or decrypting the packet. Users of this gateway typically have either a non-Windows machine or more than one machine on a home LAN. (People with a single Windows machine generally use a software client, and are homed on a different gateway.) I picked up converstations to about 145 home networks, and about 300 different machines. I made no attempt to account for rekeying; that should be infrequent enough that it wouldn't affect key agility requirements. The network behavior was about as expected. There were more packets to the home than from it (4,189,877 vs. 2,810,123) and many more bytes (1,705,033,395 vs. 297,915,963), for an average of 406 bytes/packet downstream and 106 bytes/packet upstream. While I haven't yet analyzed packet size distributions for upstream vs. downstream, the different average sizes certainly suggest that a larger percentage of the upstream packets are made up of tinygrams. To assess the key agility requirements, I simulated an LRU cache of infiite depth. The number of cache hits at a given depth should then indicate how large a cache would be needed to avoid a new key schedule calculation. (Note: I think that this approach is reasonable -- does anyone disagree?) I could have, but didn't, discard cache entries when too much time had elapsed since the last use, thus indicating a likely rekeying operation. To achieve an 80% hit rate, a cache size of 5 entries is needed for the encrypt (to the home) side, while a 8-element cache would be needed for decryption. To achieve a 95% hit rate, 11 and 17 element caches would be needed. The cache size differences agree with intuition. The gateway decrypt side requires a bigger cache than the encrypt side to achieve the same hit rate; this is probably a function of the mechanisms I suggested a few days ago: smaller packets which allow for more interleaving, delayed ACK strategies, and some lack of "packet trains". IPsec decryption is in some sense more demanding than encryption; since MAC-checking can be done in parallel with decryption, multiple packets can be decrypted back-to-back, without needing to reuse the data path for serial encrypt/MAC generation. On the other hand, the upstream data rate was considerably less, allowing more time for key-switching. I did some preliminary analysis of packet train lengths. Downstream packets show some evidence of packet clustering, though not as much as I had expected -- 60% of the trains downstream were of length 1, compared with 70% of upstream trains. I'm not sure what further analyses I should perform on this data. I do caution people that these are small-scale measurements from one site; I would be very interested to see data from other sites with IPsec gateways, especially big gateways. As I noted, I saw less than 150 SAs; it is not clear to me what would happen with 1500 or 15,000 SAs. For actual assessment of key agility requirements, a larger study is needed. I've attached the output summary files. The first column is the LRU depth; the second is the number of hits at that depth, and the third is the cumulative packet percentage for that depth. (The first line is the number of different SAs, and while it does figure into the cumulative percentages, its effect is obviously minimal.) --==_Exmh_1097001440 Content-Type: text/plain ; name="encrypt-all" Content-Description: encrypt-all Content-Disposition: attachment; filename="encrypt-all" 0 147 0.00 0 1791239 42.76 1 712719 59.77 2 470323 70.99 3 298255 78.11 4 203250 82.96 5 149886 86.54 6 116415 89.32 7 92641 91.53 8 73355 93.28 9 58140 94.67 10 44887 95.74 11 33712 96.54 12 24349 97.12 13 17899 97.55 14 12586 97.85 15 9314 98.07 16 7020 98.24 17 5638 98.37 18 4471 98.48 19 3560 98.57 20 3011 98.64 21 2641 98.70 22 2317 98.76 23 2037 98.81 24 1768 98.85 25 1492 98.88 26 1441 98.92 27 1416 98.95 28 1269 98.98 29 1207 99.01 30 1119 99.04 31 1046 99.06 32 1059 99.09 33 962 99.11 34 970 99.13 35 945 99.16 36 934 99.18 37 910 99.20 38 897 99.22 39 839 99.24 40 785 99.26 41 853 99.28 42 776 99.30 43 782 99.32 44 774 99.34 45 720 99.35 46 713 99.37 47 753 99.39 48 726 99.41 49 709 99.42 50 695 99.44 51 763 99.46 52 708 99.47 53 676 99.49 54 683 99.51 55 641 99.52 56 685 99.54 57 698 99.55 58 627 99.57 59 650 99.59 60 670 99.60 61 554 99.61 62 617 99.63 63 549 99.64 64 591 99.66 65 509 99.67 66 554 99.68 67 514 99.69 68 498 99.71 69 476 99.72 70 438 99.73 71 486 99.74 72 463 99.75 73 460 99.76 74 446 99.77 75 432 99.78 76 471 99.79 77 384 99.80 78 369 99.81 79 355 99.82 80 320 99.83 81 276 99.83 82 270 99.84 83 289 99.85 84 231 99.85 85 250 99.86 86 271 99.87 87 250 99.87 88 250 99.88 89 252 99.88 90 240 99.89 91 255 99.90 92 250 99.90 93 229 99.91 94 240 99.91 95 168 99.92 96 174 99.92 97 172 99.92 98 155 99.93 99 159 99.93 100 137 99.94 101 150 99.94 102 152 99.94 103 162 99.95 104 172 99.95 105 178 99.95 106 162 99.96 107 160 99.96 108 153 99.97 109 146 99.97 110 133 99.97 111 117 99.98 112 116 99.98 113 125 99.98 114 106 99.98 115 112 99.99 116 82 99.99 117 73 99.99 118 74 99.99 119 49 99.99 120 47 99.99 121 40 100.00 122 37 100.00 123 33 100.00 124 38 100.00 125 27 100.00 126 20 100.00 127 7 100.00 128 14 100.00 129 6 100.00 130 2 100.00 131 2 100.00 132 1 100.00 133 1 100.00 134 1 100.00 135 0 100.00 136 0 100.00 137 1 100.00 138 0 100.00 139 0 100.00 140 0 100.00 141 0 100.00 142 0 100.00 143 0 100.00 144 1 100.00 --==_Exmh_1097001440 Content-Type: text/plain ; name="decrypt-all" Content-Description: decrypt-all Content-Disposition: attachment; filename="decrypt-all" 0 142 0.01 0 942192 33.53 1 367564 46.61 2 269794 56.21 3 217387 63.95 4 175852 70.21 5 145346 75.38 6 120891 79.68 7 100418 83.26 8 81884 86.17 9 64991 88.48 10 50992 90.30 11 40071 91.72 12 30991 92.83 13 23835 93.67 14 18649 94.34 15 14680 94.86 16 11926 95.28 17 10169 95.65 18 8753 95.96 19 8172 96.25 20 7317 96.51 21 6738 96.75 22 6129 96.97 23 5637 97.17 24 4988 97.34 25 4558 97.51 26 4208 97.66 27 3865 97.79 28 3574 97.92 29 3250 98.04 30 2767 98.14 31 2575 98.23 32 2372 98.31 33 2279 98.39 34 2100 98.47 35 1943 98.54 36 1750 98.60 37 1657 98.66 38 1477 98.71 39 1381 98.76 40 1274 98.80 41 1196 98.85 42 1116 98.89 43 1106 98.93 44 1100 98.97 45 980 99.00 46 904 99.03 47 890 99.06 48 825 99.09 49 803 99.12 50 765 99.15 51 743 99.18 52 729 99.20 53 680 99.23 54 681 99.25 55 705 99.28 56 617 99.30 57 623 99.32 58 637 99.34 59 602 99.36 60 651 99.39 61 580 99.41 62 660 99.43 63 598 99.45 64 564 99.47 65 554 99.49 66 556 99.51 67 524 99.53 68 525 99.55 69 522 99.57 70 498 99.59 71 530 99.60 72 521 99.62 73 468 99.64 74 482 99.66 75 480 99.67 76 442 99.69 77 444 99.71 78 398 99.72 79 393 99.73 80 369 99.75 81 356 99.76 82 297 99.77 83 301 99.78 84 266 99.79 85 264 99.80 86 272 99.81 87 272 99.82 88 222 99.83 89 262 99.84 90 266 99.85 91 221 99.85 92 254 99.86 93 213 99.87 94 211 99.88 95 208 99.88 96 173 99.89 97 162 99.90 98 160 99.90 99 166 99.91 100 169 99.91 101 147 99.92 102 141 99.92 103 140 99.93 104 161 99.94 105 190 99.94 106 158 99.95 107 141 99.95 108 134 99.96 109 129 99.96 110 128 99.97 111 126 99.97 112 127 99.98 113 101 99.98 114 113 99.98 115 80 99.99 116 65 99.99 117 62 99.99 118 44 99.99 119 52 99.99 120 30 100.00 121 35 100.00 122 30 100.00 123 27 100.00 124 16 100.00 125 11 100.00 126 11 100.00 127 5 100.00 128 2 100.00 129 0 100.00 130 0 100.00 131 1 100.00 132 1 100.00 133 0 100.00 134 0 100.00 135 0 100.00 136 0 100.00 137 0 100.00 138 0 100.00 139 1 100.00 --==_Exmh_1097001440 From owner-ipsec@lists.tislabs.com Fri Apr 28 10:10: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 KAA18237; Fri, 28 Apr 2000 10:10:28 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA23664 Fri, 28 Apr 2000 11:16:22 -0400 (EDT) Date: Fri, 28 Apr 2000 18:23:32 +0300 (EET DST) From: Markku Savela Message-Id: <200004281523.SAA23647@anise.tte.vtt.fi> To: ipsec@lists.tislabs.com Subject: IPSEC SA lifetime, bytes counting? Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Has it really been nailed down somewhere, what exactly is counted for bytes for phase 2 SA lifetimes? I'm asking because, what I interpreted for ESP was count only the bytes that were actually encrypted However, Kame (stable rel. 2000.02.14) appears to count them as follows outbound, counts the full IP packet length (including IP header) inboud, counts the encrypted bytes + authentication digest legth (usually 12 bytes) (apparently the same is true for 2000.04.25) I think this should be nailed down so that what is counted is exactly speficied. One may think that due to packet loss, the accuracy doesn't mean much, but I think it is important because, if both sides count the bytes same way, we can *ALWAYS* know that in SA going from A to B, the A always expires first. If count algorithms differ, then it is possible that B side expires first. It would be advantage, if the expiration situation are always guaranteed to be so that the source expires first. Destination end expiring first means some interop error, incorrect and wrong lifetimes (different one on A and B). -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ From owner-ipsec@lists.tislabs.com Fri Apr 28 10:22: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 KAA18362; Fri, 28 Apr 2000 10:22:27 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23850 Fri, 28 Apr 2000 12:14:46 -0400 (EDT) To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: ipsec@lists.tislabs.com In-reply-to: msa's message of Fri, 28 Apr 2000 18:23:32 +0300. <200004281523.SAA23647@anise.tte.vtt.fi> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPSEC SA lifetime, bytes counting? From: itojun@iijlab.net Date: Sat, 29 Apr 2000 01:21:48 +0900 Message-ID: <22047.956938908@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Has it really been nailed down somewhere, what exactly is counted for >bytes for phase 2 SA lifetimes? >I'm asking because, what I interpreted for ESP was > count only the bytes that were actually encrypted >However, Kame (stable rel. 2000.02.14) appears to count them as >follows > outbound, counts the full IP packet length (including IP > header) > inboud, counts the encrypted bytes + authentication digest > legth (usually 12 bytes) >(apparently the same is true for 2000.04.25) actually, we (KAME) think it is a problem in our implementation that we count them differently - we filed a PR for it. http://orange.kame.net/dev/query-pr.cgi?pr=181 we are still not really sure which one is correct, though. >I think this should be nailed down so that what is counted is exactly >speficied. One may think that due to packet loss, the accuracy doesn't >mean much, but I think it is important because, if both sides count >the bytes same way, we can *ALWAYS* know that in SA going from A >to B, the A always expires first. >If count algorithms differ, then it is possible that B side expires >first. It would be advantage, if the expiration situation are always >guaranteed to be so that the source expires first. Destination end >expiring first means some interop error, incorrect and wrong >lifetimes (different one on A and B). I personally think byte lifetime is not very useful. - Consider any packet loss and retransmission. Sender side will expire earlier than the receiver side. - SA will never expire if, for example, rekey happens and new SA is chosen for future transmission (how to do rekey is not the point, the point is that there can be SAs that will never expire, if you set byte lifetime only). itojun From owner-ipsec@lists.tislabs.com Fri Apr 28 10:25: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 KAA18393; Fri, 28 Apr 2000 10:25:58 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23888 Fri, 28 Apr 2000 12:27:16 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14601.48533.514232.265898@xedia.com> Date: Fri, 28 Apr 2000 12:34:29 -0400 (EDT) To: msa@hemuli.tte.vtt.fi Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC SA lifetime, bytes counting? References: <200004281523.SAA23647@anise.tte.vtt.fi> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Markku" == Markku Savela writes: Markku> Has it really been nailed down somewhere, what exactly is Markku> counted for bytes for phase 2 SA lifetimes? Markku> I'm asking because, what I interpreted for ESP was Markku> count only the bytes that were actually encrypted "Bytes protected" seems like the logical definition and I believe this is stated somewhere. For authentication, that would include the ESP header. Markku> However, Kame (stable rel. 2000.02.14) appears to count them Markku> as follows Markku> outbound, counts the full IP packet length (including IP Markku> header) Markku> inboud, counts the encrypted bytes + authentication digest Markku> legth (usually 12 bytes) Markku> (apparently the same is true for 2000.04.25) That seems somewhat illogical, but I can't see a reason to worry much about it. Markku> I think this should be nailed down so that what is counted is Markku> exactly speficied. One may think that due to packet loss, the Markku> accuracy doesn't mean much, but I think it is important Markku> because, if both sides count the bytes same way, we can Markku> *ALWAYS* know that in SA going from A to B, the A always Markku> expires first. Not if the network duplicated packets, which I think an IP network is permitted to do (though it should not happen often). paul From owner-ipsec@lists.tislabs.com Fri Apr 28 10:27: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 KAA18420; Fri, 28 Apr 2000 10:27:06 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23922 Fri, 28 Apr 2000 12:30:50 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14601.48748.704095.700654@xedia.com> Date: Fri, 28 Apr 2000 12:38:04 -0400 (EDT) To: msa@hemuli.tte.vtt.fi Cc: ipsec@lists.tislabs.com Subject: Re: IPSEC SA lifetime, bytes counting? References: <200004281523.SAA23647@anise.tte.vtt.fi> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Markku" == Markku Savela writes: Markku> ... Markku> I think this should be nailed down so that what is counted is Markku> exactly speficied. One may think that due to packet loss, the Markku> accuracy doesn't mean much, but I think it is important Markku> because, if both sides count the bytes same way, we can Markku> *ALWAYS* know that in SA going from A to B, the A always Markku> expires first. Never mind packet duplication... if packets are not all the same size and they are reordered in the network -- which of course an IP network is definitely allowed to do -- then B might also expire first. So as far I can see, while it's worth documenting the desired behavior, you cannot deduce from this that a particular side will expire first. Any protocol assumptions that depend on such ordering are a bad idea. paul From owner-ipsec@lists.tislabs.com Fri Apr 28 10:32: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 KAA18485; Fri, 28 Apr 2000 10:32:03 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA23905 Fri, 28 Apr 2000 12:29:03 -0400 (EDT) Message-Id: <200004281635.e3SGZtb22379@adk.gr> To: itojun@iijlab.net Cc: msa@hemuli.tte.vtt.fi (Markku Savela), ipsec@lists.tislabs.com Subject: Re: IPSEC SA lifetime, bytes counting? In-reply-to: Your message of "Sat, 29 Apr 2000 01:21:48 +0900." <22047.956938908@coconut.itojun.org> Date: Fri, 28 Apr 2000 12:35:55 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <22047.956938908@coconut.itojun.org>, itojun@iijlab.net writes: > > - SA will never expire if, for example, rekey happens and new SA is > chosen for future transmission (how to do rekey is not the point, > the point is that there can be SAs that will never expire, if > you set byte lifetime only). The whole point of using a traffic volume-based expiration counter is to make sure you don't use the same key to process "too much" data. IMNSHO, it is supposed to be used in conjunction with a time expiration (so you bound the lifetime of the SA in terms of both time and "space"). Seen in that light, it doesn't matter what exactly it is you're counting; assuming that whoever proposed the byte-based expiration knows what they're counting, it's irrelevant whether the other side is counting more or less bytes/packet (if it's counting more, "our" counter will expire first; if it's counting less, theirs will which still meets our safety requirements) -- as long as they're not horribly different (which they're not likely to be). -Angelos From owner-ipsec@lists.tislabs.com Fri Apr 28 10:52: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 KAA18808; Fri, 28 Apr 2000 10:52:31 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA24037 Fri, 28 Apr 2000 12:51:32 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: "Angelos D. Keromytis" Cc: itojun@iijlab.net, msa@hemuli.tte.vtt.fi (Markku Savela), ipsec@lists.tislabs.com Subject: Re: IPSEC SA lifetime, bytes counting? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Apr 2000 12:58:46 -0400 Message-Id: <20000428165847.5414535DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200004281635.e3SGZtb22379@adk.gr>, "Angelos D. Keromytis" writes: > >In message <22047.956938908@coconut.itojun.org>, itojun@iijlab.net writes: >> >> - SA will never expire if, for example, rekey happens and new SA is >> chosen for future transmission (how to do rekey is not the point, >> the point is that there can be SAs that will never expire, if >> you set byte lifetime only). > >The whole point of using a traffic volume-based expiration counter is >to make sure you don't use the same key to process "too much" >data. IMNSHO, it is supposed to be used in conjunction with a time >expiration (so you bound the lifetime of the SA in terms of both time >and "space"). Seen in that light, it doesn't matter what exactly it is >you're counting; assuming that whoever proposed the byte-based >expiration knows what they're counting, it's irrelevant whether the >other side is counting more or less bytes/packet (if it's counting >more, "our" counter will expire first; if it's counting less, theirs >will which still meets our safety requirements) -- as long as they're >not horribly different (which they're not likely to be). Absolutely. As long as we're using a cipher with 64-bit blocks, there is leakage likely after encrypting 2^32 blocks. That's true for 3DES as well as DES. We'll have to switch to a 128-bit block cipher, such as AES, for the byte counter to become irrelevant. --Steve Bellovin From owner-ipsec@lists.tislabs.com Fri Apr 28 11:11: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 LAA19013; Fri, 28 Apr 2000 11:11:45 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA24131 Fri, 28 Apr 2000 13:07:35 -0400 (EDT) Message-ID: <3909C779.64AF574B@redcreek.com> Date: Fri, 28 Apr 2000 10:16:41 -0700 From: "Scott G. Kelly" Organization: RedCreek Communications X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: Markku Savela , ipsec@lists.tislabs.com Subject: Re: IPSEC SA lifetime, bytes counting? References: <22047.956938908@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk itojun@iijlab.net wrote: > I personally think byte lifetime is not very useful. > - Consider any packet loss and retransmission. Sender side will > expire earlier than the receiver side. But still, byte lifetime insures that an attacker can collect at most n bytes of ciphertext under the given key. Given that some attacks improve with larger amounts of ciphertext to work with, this seems useful. > - SA will never expire if, for example, rekey happens and new SA is > chosen for future transmission (how to do rekey is not the point, > the point is that there can be SAs that will never expire, if > you set byte lifetime only). Yes, and this is why many have said that for all practical purposes, a kbyte lifetime should only be used together with a seconds lifetime. Scott From owner-ipsec@lists.tislabs.com Fri Apr 28 12:32: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 MAA20058; Fri, 28 Apr 2000 12:32:26 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24384 Fri, 28 Apr 2000 14:17:18 -0400 (EDT) Message-Id: <200004281824.SAA16773@orchard.arlington.ma.us> To: Paul Koning cc: msa@hemuli.tte.vtt.fi, ipsec@lists.tislabs.com Subject: Re: IPSEC SA lifetime, bytes counting? In-Reply-To: Message from Paul Koning of "Fri, 28 Apr 2000 12:34:29 EDT." <14601.48533.514232.265898@xedia.com> Date: Fri, 28 Apr 2000 14:24:10 -0400 From: Bill Sommerfeld Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Not if the network duplicated packets, which I think an IP network is > permitted to do (though it should not happen often). if you're either running without replay detection, or counting replayed packets against the SA lifetime, something's wrong.. - Bill From owner-ipsec@lists.tislabs.com Fri Apr 28 12:57: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 MAA20349; Fri, 28 Apr 2000 12:57:39 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24493 Fri, 28 Apr 2000 14:49:07 -0400 (EDT) From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14601.57046.533925.598712@xedia.com> Date: Fri, 28 Apr 2000 14:56:22 -0400 (EDT) To: sommerfeld@orchard.arlington.ma.us Cc: msa@hemuli.tte.vtt.fi, ipsec@lists.tislabs.com Subject: Re: IPSEC SA lifetime, bytes counting? References: <14601.48533.514232.265898@xedia.com> <200004281824.SAA16773@orchard.arlington.ma.us> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Bill" == Bill Sommerfeld writes: >> Not if the network duplicated packets, which I think an IP network >> is permitted to do (though it should not happen often). Bill> if you're either running without replay detection, or counting Bill> replayed packets against the SA lifetime, something's wrong.. Oops. Of course I can weasel out of this one :-) In spite of Steve Bellovin's nice explanation why it's dangerous, the standard does allow you to run without authentication. That means no replay checking... paul From owner-ipsec@lists.tislabs.com Fri Apr 28 16:10: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 QAA22229; Fri, 28 Apr 2000 16:10:50 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25158 Fri, 28 Apr 2000 17:46:32 -0400 (EDT) Date: Fri, 28 Apr 2000 16:52:05 -0500 (CDT) From: Tylor Allison X-Sender: allison@stpsowk45.sctc.com To: ietf-ipsra@vpnc.org, ipsec@lists.tislabs.com Subject: Mode-Config Questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For those of you who have implemented Mode-Config, I have a few questions... o First of all, Mode-Config allows a client to request the IP addresses of DHCP Servers from the edge device. Is it expected that once the client has obtained it's address via Mode-Config, that it will then use DHCP to manage that address (DHCP lease renewal)? Or is it expected that the client will contact the DHCP for network parameters not supplied via mode-config (via DHCP inform)? o Assuming that the client does not manage it's dynamically-assigned IP address via DHCP, how and when does lease expiration get handled? The mode-config draft mentions that the IP address is valid until the expiry time defined via the INTERNAL_ADDRESS_EXPIRY attribute, or until the ISAKMP SA expires. Is it the client's responsibility to recognize lease expiration, and to perform a new mode-config exchange? Can the edge-device force a new mode-config exchange via a SET/ACK protocol to extend the lease? o Finally, I'd be very interested in hearing anyone's thoughts on implementing mode-config for a gateway application. In particular, is the typical method to implement a thin DHCP client interface within the gateway's ISAKMP server to interact with a separate DHCP server behind the gateway? Or are people just implementing a private pool of addresses within ISAKMP? From my understanding of the DHCP standard, there are problems with having ISAKMP act as a DHCP client on behalf of the remote VPN client. This is especially true with the renewal of IP address leases, which requires the server to unicast replies back to the client address for which the lease is being renewed. Just wondering if anyone has tackled these issues already... or if there is documentation out there which discusses solutions. I've searched the archives, and really didn't find anything relating to these questions... but if this has been previously discussed, could someone point me to the thread. Thanks in advance. --- Tylor Allison tylor_allison@securecomputing.com Secure Computing Corporation From owner-ipsec@lists.tislabs.com Sat Apr 29 14:55: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 OAA13535; Sat, 29 Apr 2000 14:54:59 -0700 (PDT) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27598 Sat, 29 Apr 2000 16:19:37 -0400 (EDT) Reply-To: From: "Bernard Aboba" To: "'Tylor Allison'" , , Subject: RE: Mode-Config Questions Date: Sat, 29 Apr 2000 13:26:46 -0700 Message-ID: <000001bfb219$3edd72d0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Is it expected that once the >client has obtained it's address via Mode-Config, that it will then >use DHCP to manage that address (DHCP lease renewal)? This won't work because the chaddr/client-identifier used to renew won't be the same as the one under which the address was obtained. Also, so as not to confuse the DHCP server, a unique client-identifier must be included in each DHCP request (although the hytpe/chaddr will be the same). >Or is it expected that the client will contact the DHCP for network parameters >not supplied via mode-config (via DHCP inform)? This could work assuming that the client doesn't obtain conflicting parameters via Mode-Config. > From my understanding of the DHCP standard, there are problems with > having ISAKMP act as a DHCP client on behalf of the remote VPN client. Yes, there are. If ISAKMP acts as a DHCP client, then it must renew the leases itself via unicast to the DHCP server. This in turn means that it must be able to filter incoming DHCP packets addressed to itself and treat these specially. As a result, implementations often act as a DHCP relay instead, including the client htype/chaddr and client-identifier (typically set to the chaddr) in the initial DHCPDISCOVER and setting the gateway address in the giaddr field. This in turn implies that the DHCP leases are being acquired along with the Mode-Cfg negotiation. It is harder to use this approach along with address pool management. There is an ongoing discussion on the DHC WG mailing list relating to this issue.