From owner-ipsec@lists.tislabs.com Tue Jan 2 06:53:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27025; Tue, 2 Jan 2001 06:53:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA08485 Tue, 2 Jan 2001 07:52:13 -0500 (EST) Date: Mon, 1 Jan 2001 20:47:25 -0800 (PST) From: Avram Shacham X-Sender: shacham@zev.net To: ippcp@external.cisco.com cc: ipsec@lists.tislabs.com Subject: FYI: rfc2393(bis) webpage Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Following the conclusion of the ippcp wg some two years ago, there was no active webpage for efforts related to RFC2393(bis). Now, http://www.shacham.net/ipcomp/ provides such information, for example * The latest and archived rfc2393bis I-D versions along with incremental change reports that were posted to the mailing lists. * The draft interoperability report. * Some ippcp wg history. avram From owner-ipsec@lists.tislabs.com Tue Jan 2 15:43:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01942; Tue, 2 Jan 2001 15:43:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00956 Tue, 2 Jan 2001 16:54:56 -0500 (EST) Message-ID: <3A5235CB.28A5C949@sparta.com> Date: Tue, 02 Jan 2001 15:10:51 -0500 From: Howard Weiss Reply-To: hsw@columbia.sparta.com Organization: SPARTA, Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: IPSEC Ciphers? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At Minneapolis and later in Oslo, there were discussions in the IPSEC and SAAG mtgs to deprecate DES in favor of 3DES - and later AES for use with IKE (at least according to my notes the Minneapolis discussion was to change from DES to 3DES in Phase I of IKE). In Oslo, there was a discussion of 3DES vs. AES and it was decided to wait until the AES winner was announced - but in the meantime, 3DES was to replace DES as the IPSEC mandated cipher. Is there an updated RFC, ID, IESG, or IAB note stating this to be the case that can be referenced? All I can find are RFCs 2451 (CBC Ciphers), 2405 (DES w/explict IV), and 1851 (3DES - experimental) - but nothing that says use DES in place of 3DES. Thanks, Howie -- ____________________________________________________________________ Howard Weiss phone (410) 381-9400 x201 SPARTA, Inc. (301) 621-8145 x201 (DC) 9861 Broken Land Parkway fax: (410) 381-5559 Columbia, MD 21046 email: hsw@columbia.sparta.com ____________________________________________________________________ From owner-ipsec@lists.tislabs.com Tue Jan 2 15:47:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02195; Tue, 2 Jan 2001 15:47:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00957 Tue, 2 Jan 2001 16:54:56 -0500 (EST) Message-ID: <29752A74B6C5D211A4920090273CA3DC01D28699@new-exc1.ctron.com> From: "Waters, Stephen" To: "'ipsec@lists.tislabs.com'" Subject: RE: Fw: IPSec vs. SSL Date: Tue, 2 Jan 2001 18:05:05 -0000 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 guess, if the browser vendors wanted to, they could load IPSEC e-commerce as silently as SSL was added. For e-shopping, the client would then first need to buy a useful certificate, but the browser could make that simple too. This would then allow the name/address of the certificate owner to be linked to the name on the credit card used, and thus reduce the man-in-the-middle exposure of SSL. I am not familiar with SSL, but rumour has it that there is a sniff tool that can crack it. Is this because the data key generation/exchange is not linked to the authentication of the server? If this is the case, it would not be necessary for a man-in-the-middle attacker to acquire a trusted 'server' certificate, they could just intercept client connections, start their own server connection, and forward any server authentication to the real client. Can an SSL expert comment on this please. Thanks, Steve. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, December 27, 2000 9:30 PM To: Rick Smith at Secure Computing Cc: ipsec@lists.tislabs.com Subject: Re: Fw: IPSec vs. SSL Much of this SSL vs. IPsec discussion has been based on unarticulated assumptions, and there have been some explicit technical errors, further confusing the debate. One fair observation is that SSL configuration, from a client perspective, is much easier than for IPsec precisely because SSL does not address access control issues. Even at the server side, access control is an add on, outside scope of SSL. This relates to the observation made earlier re pre-configured CAs in SSL clients. This is a convenience feature that works fairly well for the public access to server model that SSL is designed to support. It is less attractive in an intranet environment, as it creates more opportunities for spoofing. But, even this is not a criticism of SSL, because SSL does not embody any notion of root CAs in clients. All fo that is outside the SSL spec, and is not standardized. So, let's keep in mind the differences between standards and implementations when comparing SSL and IPsec. There are legitimate differences in services and functional requirements between these protocols, and many of these differences relate to the contexts for which each was designed. In some cases they might be competitors, in other cases one offers features that make it incomparable to the other. Steve From owner-ipsec@lists.tislabs.com Wed Jan 3 13:15:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06200; Wed, 3 Jan 2001 13:15:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05306 Wed, 3 Jan 2001 14:06:29 -0500 (EST) From: Mohan Parthasarathy Message-Id: <200101031822.f03IMev18323@locked.eng.sun.com> Subject: Mobile IPv6 - IPsec interaction. To: ipsec@lists.tislabs.com Date: Wed, 3 Jan 2001 10:22:40 -0800 (PST) CC: Francis.Dupont@enst-bretagne.fr, Mohan Parthasarathy X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, We have been discussing an IPsec issue in the Mobile IP mailing list which we thought would get some input from this mailing list. It looks like some of the existing VPN solutions may have addressed this. Mobile IPv6 allows a mobile node to move from one link to another without changing the mobile node's IP address (Home address). As it moves from one link to another, it configures a new address on the link known as the care of Address (CoA). When a mobile node configures a new care-of address, the mobile node registers this new binding with its home agent and correspondent nodes by sending a Binding Update. Binding Update thus creates a binding between the Home Address and the CoA. This information is used to route packets directly to the Mobile node. Binding updates MUST be protected by IPsec AH. Following are the details of the Key exchange to get an IPsec SA to protect the binding update : 1) In Main Mode, it uses the Care of Address as the source address ( it can't use the Home Address yet as the other end either has a stale binding or no bindings and hence we can't get the reply back) and uses an appropriate authentication mechanism to establish the Phase I SA. 2) In Quick Mode, we want the IPsec SA to be bound to the mobile node's Home Address. This is acheived by using the Identification payload with Home Address in it. (All selector checks will happen against the home address) In step (2), there is nothing that prevents a mobile node from using the home address of some other mobile node. How does the other end (the home agent or the correspondent node) verify that the mobile node is using the right home address ? This issue looks similar to the case mentioned in 4.6.3 of RFC2401, where a road warrior tries to connect to some host in the corporate network through a security gateway. How does one verify whether a given SG is authorized to represent a given host ? Similarly, how do we verify whether the Mobile node is authorized to use a given Home Address ? How does the existing VPN solutions solve this problem ? I am hoping that similar solution would help this case. Comments ? -thanks mohan From owner-ipsec@lists.tislabs.com Wed Jan 3 18:15:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14070; Wed, 3 Jan 2001 18:15:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06278 Wed, 3 Jan 2001 19:32:22 -0500 (EST) X-Authentication-Warning: taulu.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14931.50459.97820.546977@taulu.hel.fi.ssh.com> Date: Thu, 4 Jan 2001 02:34:35 +0200 From: Tero Kivinen To: Mohan Parthasarathy Cc: ipsec@lists.tislabs.com, Francis.Dupont@enst-bretagne.fr Subject: Mobile IPv6 - IPsec interaction. In-Reply-To: <200101031822.f03IMev18323@locked.eng.sun.com> References: <200101031822.f03IMev18323@locked.eng.sun.com> X-Mailer: VM 6.88 under Emacs 20.7.2 Organization: SSH Communications Security Oy X-Edit-Time: 14 min X-Total-Time: 15 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mohan Parthasarathy writes: > 1) In Main Mode, it uses the Care of Address as the source address ( > it can't use the Home Address yet as the other end either has > a stale binding or no bindings and hence we can't get the reply > back) and uses an appropriate authentication mechanism > to establish the Phase I SA. It cannot use care of address as its identity in phase I. The care of address does not have any meaning to the home agent. It needs to use something in the phase I that will identify the mobile node to the home agent. This could be username@host.name (user@fqdn), fixed.domain.name.at.home (fqdn) or distinguished name. Using of those also rules out using of main mode with pre-shared keys, thus the best would be using certificates (signatures). Another possibility would be aggressive mode (either with signatures or with pre-shared keys). > 2) In Quick Mode, we want the IPsec SA to be bound to the mobile node's > Home Address. This is acheived by using the Identification payload > with Home Address in it. (All selector checks will happen > against the home address) > > In step (2), there is nothing that prevents a mobile node from using > the home address of some other mobile node. How does the other > end (the home agent or the correspondent node) verify that the > mobile node is using the right home address ? It verifies that the identity sent in the phase I matches its policy database. Example: My laptop (kaakeli.ssh.fi) has a home address of 11.22.33.44. I also have certificate that is bound to this machine having names DN = "C=Fi, O=SSH Communications Security, CN=Tero Kivinen", user@fqdn = "kivinen@ssh.fi", fqdn = "kaakeli.ssh.fi" and ip = "11.22.33.44" in it. When my laptop moves out from the local network and needs to send binding update, it connects to the home agent at 11.22.1.1 from its care of address 4.5.6.7. In the phase I can use any of the names inside the certificate as my identity and the home agent can then know that only my laptop is able to create that IKE SA. Thus after phase I succeeds it knows that it is my laptop at the other end of that IKE SA. Using my home address (11.22.33.44) as an identity of the phase I is a bad idea, because some implementations check that IKE src address matches the phase I id. Thus it would be better using either user@fqdn or fqdn instead. In the phase II my laptop will create tunnel between 11.22.33.44 and the home agent, and now the home agent knows that this IKE SA connection is bound to my laptop which then is bound to home address of 11.22.33.44, thus this operation can succeed. You have to remeber that authentication of the remote end happens in the Phase I, and after that you know who is on the other end of that IKE SA. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Jan 4 06:47:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12157; Thu, 4 Jan 2001 06:47:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA08259 Thu, 4 Jan 2001 07:23:57 -0500 (EST) Message-Id: <200101041225.HAA02139@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-09.txt Date: Thu, 04 Jan 2001 07:25:52 -0500 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 : DHCPv4 Configuration of IPSEC Tunnel Mode Author(s) : B. Patel, B. Aboba, S. Kelly, V. Gupta Filename : draft-ietf-ipsec-dhcp-09.txt Pages : 15 Date : 03-Jan-01 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-09.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-09.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-09.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: <20010103133503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-dhcp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-dhcp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010103133503.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Jan 4 11:50:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05193; Thu, 4 Jan 2001 11:50:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09469 Thu, 4 Jan 2001 13:05:12 -0500 (EST) From: Franck.Le@nokia.com Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B028DBD4C@daeis07nok> To: kivinen@ssh.fi, Mohan.Parthasarathy@Eng.Sun.COM Cc: ipsec@lists.tislabs.com, Francis.Dupont@enst-bretagne.fr Subject: RE: Mobile IPv6 - IPsec interaction. Date: Thu, 4 Jan 2001 12:02:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mohan Parthasarathy writes: > 1) In Main Mode, it uses the Care of Address as the source address ( > it can't use the Home Address yet as the other end either has > a stale binding or no bindings and hence we can't get the reply > back) and uses an appropriate authentication mechanism > to establish the Phase I SA. >It cannot use care of address as its identity in phase I. The care of >address does not have any meaning to the home agent. It needs to use >something in the phase I that will identify the mobile node to the >home agent. >This could be username@host.name (user@fqdn), >fixed.domain.name.at.home (fqdn) or distinguished name. Using of those >also rules out using of main mode with pre-shared keys, thus the best >would be using certificates (signatures). Why using user@fqdn,fixed.domain.name.at.home (fqdn) or distinguished name rules out using main mode with pre-shared keys ? Thank you. From owner-ipsec@lists.tislabs.com Thu Jan 4 11:50:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05202; Thu, 4 Jan 2001 11:50:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09502 Thu, 4 Jan 2001 13:13:50 -0500 (EST) X-Authentication-Warning: taulu.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14932.48611.805665.534420@taulu.hel.fi.ssh.com> Date: Thu, 4 Jan 2001 20:16:03 +0200 From: Tero Kivinen To: Mohan Parthasarathy Cc: ipsec@lists.tislabs.com, Francis.Dupont@enst-bretagne.fr Subject: Re: Mobile IPv6 - IPsec interaction. In-Reply-To: <200101041759.f04HxhM18798@locked.eng.sun.com> References: <200101041759.f04HxhM18798@locked.eng.sun.com> X-Mailer: VM 6.88 under Emacs 20.7.2 Organization: SSH Communications Security Oy X-Edit-Time: 20 min X-Total-Time: 13 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mohan Parthasarathy writes: > > It cannot use care of address as its identity in phase I. The care of > > address does not have any meaning to the home agent. It needs to use > > something in the phase I that will identify the mobile node to the > > home agent. > Agreed. I did not mean to use the care of address as the identity. > I meant that one can't use the home address in phase I. If it > could have used the home address, then there is no problem Actually you can. The identity used in the phase I does not have to match the ip address of the originating packet. It must match the identity of the remote host. > > It verifies that the identity sent in the phase I matches its policy > > database. > You mean to say that during phase II, you link the phase I identity > and the IP address used in the ID payload of phase II and match it > with that is in the certificate. Not really. The Phase I identity is checked against the certificate, and that identity is also used to search for the policy rules allowed for the host. And that policy rule must then allow for that host to create tunnel between those two hosts. The ip-number does not have to be in the certificate (it can be and you can use that to verify that it is correct), it can also be in the external policy mapping saying that kivinen@ssh.fi can use home addresses of 11.22.33.44 or 11.22.33.45 (lets say I have my laptop and also my cellular phone, and both of them are using the certificate I have on the smartcard to authenticate themselves). > > Example: > > > > My laptop (kaakeli.ssh.fi) has a home address of 11.22.33.44. I also > > have certificate that is bound to this machine having names DN = > > "C=Fi, O=SSH Communications Security, CN=Tero Kivinen", > > user@fqdn = "kivinen@ssh.fi", fqdn = "kaakeli.ssh.fi" and ip = > > "11.22.33.44" in it. > > > So, for every cell phone assume i have such a certificate issued. I think that is the only way to do it... Pre-shared keys are just out of question in that case... > Assume i am using this to connect to some web site. As i keep > moving, i keep sending binding updates to the server that > i am connected to. Is it practical to assume that any > arbitrary server that i connect to, will be able to get to > these certificates and do these policy checks ? How > does the server get to this policy information ? If I understand correctly you send those binding updates to your home agent, not to each web server. If you really need to have SA between two random hosts in the internet, then you need global PKI. We do not have such yet. DNSsec might provide one, or we might end up having some kind of global X.509 PKI. Anyways that is completely different problem than protecting the connection between two know hosts, mobile user and home agent. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Jan 4 11:50:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05232; Thu, 4 Jan 2001 11:50:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09512 Thu, 4 Jan 2001 13:16:19 -0500 (EST) X-Authentication-Warning: taulu.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14932.48761.459157.12156@taulu.hel.fi.ssh.com> Date: Thu, 4 Jan 2001 20:18:33 +0200 From: Tero Kivinen To: Franck.Le@nokia.com Cc: Mohan.Parthasarathy@Eng.Sun.COM, ipsec@lists.tislabs.com, Francis.Dupont@enst-bretagne.fr Subject: RE: Mobile IPv6 - IPsec interaction. In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B028DBD4C@daeis07nok> References: <7B5C0390ACE7D211BC9C0008C7EABA2B028DBD4C@daeis07nok> X-Mailer: VM 6.88 under Emacs 20.7.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Franck.Le@nokia.com writes: > Why using user@fqdn,fixed.domain.name.at.home (fqdn) or distinguished name > rules out using main mode with pre-shared keys ? If you use main mode and pre-shared keys, you need to know the pre-shared key based on the ip-address. If the ip-address is random then there is no way for the gateway to know which pre-shared key to use to decrypt the identity sent by the other host. In main mode you need to select the pre-shared key before you can see the identity of the other end, because you need that pre-shared key to decrypt the identity the other end sent. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Jan 4 11:50:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05244; Thu, 4 Jan 2001 11:50:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09489 Thu, 4 Jan 2001 13:12:27 -0500 (EST) Date: Thu, 4 Jan 2001 09:59:43 -0800 (PST) From: Mohan Parthasarathy Message-Id: <200101041759.f04HxhM18798@locked.eng.sun.com> To: Mohan.Parthasarathy@Eng.Sun.COM, kivinen@ssh.fi Subject: Re: Mobile IPv6 - IPsec interaction. Cc: ipsec@lists.tislabs.com, Francis.Dupont@enst-bretagne.fr X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Mohan Parthasarathy writes: > > 1) In Main Mode, it uses the Care of Address as the source address ( > > it can't use the Home Address yet as the other end either has > > a stale binding or no bindings and hence we can't get the reply > > back) and uses an appropriate authentication mechanism > > to establish the Phase I SA. > > It cannot use care of address as its identity in phase I. The care of > address does not have any meaning to the home agent. It needs to use > something in the phase I that will identify the mobile node to the > home agent. > Agreed. I did not mean to use the care of address as the identity. I meant that one can't use the home address in phase I. If it could have used the home address, then there is no problem > This could be username@host.name (user@fqdn), > fixed.domain.name.at.home (fqdn) or distinguished name. Using of those > also rules out using of main mode with pre-shared keys, thus the best > would be using certificates (signatures). > > Another possibility would be aggressive mode (either with signatures > or with pre-shared keys). > > > 2) In Quick Mode, we want the IPsec SA to be bound to the mobile node's > > Home Address. This is acheived by using the Identification payload > > with Home Address in it. (All selector checks will happen > > against the home address) > > > > In step (2), there is nothing that prevents a mobile node from using > > the home address of some other mobile node. How does the other > > end (the home agent or the correspondent node) verify that the > > mobile node is using the right home address ? > > It verifies that the identity sent in the phase I matches its policy > database. > You mean to say that during phase II, you link the phase I identity and the IP address used in the ID payload of phase II and match it with that is in the certificate. > Example: > > My laptop (kaakeli.ssh.fi) has a home address of 11.22.33.44. I also > have certificate that is bound to this machine having names DN = > "C=Fi, O=SSH Communications Security, CN=Tero Kivinen", > user@fqdn = "kivinen@ssh.fi", fqdn = "kaakeli.ssh.fi" and ip = > "11.22.33.44" in it. > So, for every cell phone assume i have such a certificate issued. Assume i am using this to connect to some web site. As i keep moving, i keep sending binding updates to the server that i am connected to. Is it practical to assume that any arbitrary server that i connect to, will be able to get to these certificates and do these policy checks ? How does the server get to this policy information ? thanks -mohan > When my laptop moves out from the local network and needs to send > binding update, it connects to the home agent at 11.22.1.1 from its > care of address 4.5.6.7. > > In the phase I can use any of the names inside the certificate as my > identity and the home agent can then know that only my laptop is able > to create that IKE SA. Thus after phase I succeeds it knows that it is > my laptop at the other end of that IKE SA. > > Using my home address (11.22.33.44) as an identity of the phase I is a > bad idea, because some implementations check that IKE src address > matches the phase I id. Thus it would be better using either user@fqdn > or fqdn instead. > > In the phase II my laptop will create tunnel between 11.22.33.44 and > the home agent, and now the home agent knows that this IKE SA > connection is bound to my laptop which then is bound to home address > of 11.22.33.44, thus this operation can succeed. > > You have to remeber that authentication of the remote end happens in > the Phase I, and after that you know who is on the other end of that > IKE SA. > -- > kivinen@ssh.fi Work : +358 303 9870 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Thu Jan 4 12:49:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08705; Thu, 4 Jan 2001 12:49:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09719 Thu, 4 Jan 2001 14:00:46 -0500 (EST) To: Tero Kivinen Cc: Mohan Parthasarathy , ipsec@lists.tislabs.com, Francis.Dupont@enst-bretagne.fr Subject: Re: Mobile IPv6 - IPsec interaction. References: <200101041759.f04HxhM18798@locked.eng.sun.com> <14932.48611.805665.534420@taulu.hel.fi.ssh.com> From: Derek Atkins Date: 04 Jan 2001 14:02:34 -0500 In-Reply-To: Tero Kivinen's message of "Thu, 4 Jan 2001 20:16:03 +0200" Message-ID: Lines: 37 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Indeed, in this case you would have an IPSec association between your mobile host (using your Home Address) and the web server. Since your home address never changes, you don't need to rebuild the connection to the web server when you move. You only need to rebuild IPSec SAs between the mobile host and the home agent. -derek Tero Kivinen writes: > > Assume i am using this to connect to some web site. As i keep > > moving, i keep sending binding updates to the server that > > i am connected to. Is it practical to assume that any > > arbitrary server that i connect to, will be able to get to > > these certificates and do these policy checks ? How > > does the server get to this policy information ? > > If I understand correctly you send those binding updates to your home > agent, not to each web server. > > If you really need to have SA between two random hosts in the > internet, then you need global PKI. We do not have such yet. DNSsec > might provide one, or we might end up having some kind of global X.509 > PKI. Anyways that is completely different problem than protecting the > connection between two know hosts, mobile user and home agent. > -- > kivinen@ssh.fi Work : +358 303 9870 > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jan 4 13:30:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11621; Thu, 4 Jan 2001 13:30:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09866 Thu, 4 Jan 2001 14:39:58 -0500 (EST) Message-Id: <200101041940.f04JetO11974@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. In-reply-to: Your message of Thu, 04 Jan 2001 02:34:35 +0200. <14931.50459.97820.546977@taulu.hel.fi.ssh.com> Date: Thu, 04 Jan 2001 20:40:55 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > In step (2), there is nothing that prevents a mobile node from using > the home address of some other mobile node. How does the other > end (the home agent or the correspondent node) verify that the > mobile node is using the right home address ? It verifies that the identity sent in the phase I matches its policy database. => can you give more details about what you can find in the policy database in your IKE implementation (I can't get enough public documentation)? Example: In the phase I can use any of the names inside the certificate as my identity and the home agent can then know that only my laptop is able to create that IKE SA. Thus after phase I succeeds it knows that it is my laptop at the other end of that IKE SA. => this (identification+authentication) is known to be not enough for the proper authorization. Using my home address (11.22.33.44) as an identity of the phase I is a bad idea, because some implementations check that IKE src address matches the phase I id. => I agree: I know some of them and this check doesn't seem to be very paranoic. Thus it would be better using either user@fqdn or fqdn instead. => it will be hard to find a good reason to use something else in this case (ie. the mobile node case). In the phase II my laptop will create tunnel between 11.22.33.44 and the home agent, and now the home agent knows that this IKE SA connection is bound to my laptop which then is bound to home address of 11.22.33.44, thus this operation can succeed. => the "then is bound to" is our point: how is it done? You have to remeber that authentication of the remote end happens in the Phase I, and after that you know who is on the other end of that IKE SA. => we agree, the issue is an authorization (only!) issue. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Jan 4 13:40:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11882; Thu, 4 Jan 2001 13:40:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09898 Thu, 4 Jan 2001 15:00:53 -0500 (EST) Message-Id: <200101042002.f04K24O12044@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen cc: Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. In-reply-to: Your message of Thu, 04 Jan 2001 20:16:03 +0200. <14932.48611.805665.534420@taulu.hel.fi.ssh.com> Date: Thu, 04 Jan 2001 21:02:04 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Not really. The Phase I identity is checked against the certificate, and that identity is also used to search for the policy rules allowed for the host. And that policy rule must then allow for that host to create tunnel between those two hosts. The ip-number does not have to be in the certificate (it can be and you can use that to verify that it is correct), it can also be in the external policy mapping saying that kivinen@ssh.fi can use home addresses of 11.22.33.44 or 11.22.33.45 (lets say I have my laptop and also my cellular phone, and both of them are using the certificate I have on the smartcard to authenticate themselves). => if I have understood you said that the proved phase I identity is used for the policy lookup and the policy says this peer can use this and this home address. And the policy can be coded in the certificate (I can see for addresses but not for the permission itself) or in the external policy or both. Can you give more details how this can be done (or how it *is* done)?` > So, for every cell phone assume i have such a certificate issued. I think that is the only way to do it... Pre-shared keys are just out of question in that case... => I don't believe certificates are mandatory (the key for policy lookup is the phase I identity) but of course they make the world easier. > Assume i am using this to connect to some web site. As i keep > moving, i keep sending binding updates to the server that > i am connected to. Is it practical to assume that any > arbitrary server that i connect to, will be able to get to > these certificates and do these policy checks ? How > does the server get to this policy information ? If I understand correctly you send those binding updates to your home agent, not to each web server. => to setup SAs with the home agent is critical, to setup SAs with each web server is not but to fail to do this will kill the routing optimization which is the mobile IPv6 main argument (ie. this is not a "must" but a strong "should". Of course this is not easy :-). If you really need to have SA between two random hosts in the internet, then you need global PKI. => this was my first answer to this issue but fortunately in the future/expected common case for mobile IPv6 the nodes are not really random (ie. replace some web site by a well known web proxy: easier, isn't it?) Thanks Francis.Dupont@enst-bretagne.fr PS: our target is to prove the authorization issue of mobile IPv6 can be solved. Of course a constructive proof would be very fine and perhaps there is already one from VPN area. From owner-ipsec@lists.tislabs.com Thu Jan 4 13:49:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12200; Thu, 4 Jan 2001 13:49:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09940 Thu, 4 Jan 2001 15:15:26 -0500 (EST) To: Francis Dupont Cc: Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. References: <200101041940.f04JetO11974@givry.rennes.enst-bretagne.fr> From: Derek Atkins Date: 04 Jan 2001 15:17:39 -0500 In-Reply-To: Francis Dupont's message of "Thu, 04 Jan 2001 20:40:55 +0100" Message-ID: Lines: 68 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > => can you give more details about what you can find in the policy database > in your IKE implementation (I can't get enough public documentation)? The exact contents and format of the SPD is implementation dependent. There are some minimal requirements required by 2401. But basically, you would have something that says: mobile-host 11.22.33.44 uses i-d fqdn.mobile.host with rsa-key XXX > => this (identification+authentication) is known to be not enough for > the proper authorization. Why? identification + authentication is sufficient to lookup the Policy and provide authorization. The client (mobile host) doesn't prove that they are authorized, they prove that they have a particular ID. Then the server (home agent) looks up that ID in the database and can be assured that the (requested) home address actually belongs to that mobile host. > In the phase II my laptop will create tunnel between 11.22.33.44 and > the home agent, and now the home agent knows that this IKE SA > connection is bound to my laptop which then is bound to home address > of 11.22.33.44, thus this operation can succeed. > > => the "then is bound to" is our point: how is it done? Phase-II is _ALWAYS_ bound to phase-I, because the phase-II negotiation is completed within the protection of a phase-I SA. That gives you the binding between phase-I and phase-II. The two phases are _NOT_ independent. You cannot complete a phase-II without having a completed (and valid) phase-I. > You have to remeber that authentication of the remote end happens in > the Phase I, and after that you know who is on the other end of that > IKE SA. > > => we agree, the issue is an authorization (only!) issue. Authorization is a function of the server, and is completed by the following steps: 1) Client identifies itself 2) Client authenticates as identity 3) Server verifies authentication and returns an error if it fails 4) Client makes a request for a mobile-host binding <-- action 5) Server looks up identity in policy database a) verifies that binding matches policy b) if not, return an error c) if binding matches policy db, perform the binding Steps 1, 2, and 3 are already done by IPSec. Steps 4 and 5 are somewhat IPSec and somewhat MobileIP. > Thanks You're welcome > Francis.Dupont@enst-bretagne.fr -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jan 4 14:57:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15298; Thu, 4 Jan 2001 14:57:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10151 Thu, 4 Jan 2001 16:33:50 -0500 (EST) Message-Id: <200101042134.f04LYNO12362@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Derek Atkins cc: Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. In-reply-to: Your message of 04 Jan 2001 15:17:39 EST. Date: Thu, 04 Jan 2001 22:34:23 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: The exact contents and format of the SPD is implementation dependent. There are some minimal requirements required by 2401. But basically, you would have something that says: mobile-host 11.22.33.44 uses i-d fqdn.mobile.host with rsa-key XXX => do you know an implementation which provides or will provide this (BTW I think the "with rsa-key XXX" is not needed, ie. this is done by the certificate and relies on the PKI config). > => this (identification+authentication) is known to be not enough for > the proper authorization. Why? => because a policy must be involved. Phase I doesn't do the policy, it just estiblishes the context for the policy/authorization stuff. identification + authentication is sufficient to lookup the Policy and provide authorization. The client (mobile host) doesn't prove that they are authorized, they prove that they have a particular ID. Then the server (home agent) looks up that ID in the database and can be assured that the (requested) home address actually belongs to that mobile host. => we agree but some people want to see the corresponding running code (perhaps this is too much but this is a good thing for future interoperability so I agree that "add the authorization word in specs" is not enough for the real world). > In the phase II my laptop will create tunnel between 11.22.33.44 and > the home agent, and now the home agent knows that this IKE SA > connection is bound to my laptop which then is bound to home address > of 11.22.33.44, thus this operation can succeed. > > => the "then is bound to" is our point: how is it done? Phase-II is _ALWAYS_ bound to phase-I, because the phase-II negotiation is completed within the protection of a phase-I SA. That gives you the binding between phase-I and phase-II. The two phases are _NOT_ independent. You cannot complete a phase-II without having a completed (and valid) phase-I. => but you justifies only the "this IKE SA connection is bound to my laptop", not the second binding. > You have to remeber that authentication of the remote end happens in > the Phase I, and after that you know who is on the other end of that > IKE SA. > > => we agree, the issue is an authorization (only!) issue. Authorization is a function of the server, and is completed by the following steps: 1) Client identifies itself 2) Client authenticates as identity 3) Server verifies authentication and returns an error if it fails 4) Client makes a request for a mobile-host binding <-- action 5) Server looks up identity in policy database a) verifies that binding matches policy b) if not, return an error c) if binding matches policy db, perform the binding Steps 1, 2, and 3 are already done by IPSec. Steps 4 and 5 are somewhat IPSec and somewhat MobileIP. => my concerns are steps 4 and 5: IPsec doesn't really explain how they are done and Mobile IP only requires them... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Jan 4 15:12:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15660; Thu, 4 Jan 2001 15:12:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10264 Thu, 4 Jan 2001 17:01:12 -0500 (EST) To: Francis Dupont Cc: Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. References: <200101042134.f04LYNO12362@givry.rennes.enst-bretagne.fr> From: Derek Atkins Date: 04 Jan 2001 17:03:23 -0500 In-Reply-To: Francis Dupont's message of "Thu, 04 Jan 2001 22:34:23 +0100" Message-ID: Lines: 123 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: > In your previous mail you wrote: > > The exact contents and format of the SPD is implementation dependent. > There are some minimal requirements required by 2401. But basically, > you would have something that says: > > mobile-host 11.22.33.44 uses i-d fqdn.mobile.host with rsa-key XXX > > => do you know an implementation which provides or will provide this > (BTW I think the "with rsa-key XXX" is not needed, ie. this is done by > the certificate and relies on the PKI config). Well, that again depends on the implementation. On Linux FreeS/WAN, for example, the policy contains the RSA Key to be used (and the identification is just a hint to make sure you use the right key). Unfortunately there is no standard certificate exchange format for IPSec (yet?). But you are right, if you have a real certificate with a real i-d binding, then yes, you don't need to include the key in the policy, the identification is sufficient. > > => this (identification+authentication) is known to be not enough for > > the proper authorization. > > Why? > > => because a policy must be involved. Phase I doesn't do the policy, > it just estiblishes the context for the policy/authorization stuff. Right, phase-I is the authentication. The policy is checked and enforced by phase-II. And yes, that _IS_ done today, by selectors and such. > => we agree but some people want to see the corresponding running code > (perhaps this is too much but this is a good thing for future > interoperability so I agree that "add the authorization word in specs" > is not enough for the real world). I think any IPSec implementation that supports selectors "corresponds to running code". This does exist today. It might not be integrated with everything, but the code is there. I've seen it working. > > In the phase II my laptop will create tunnel between 11.22.33.44 and > > the home agent, and now the home agent knows that this IKE SA > > connection is bound to my laptop which then is bound to home address > > of 11.22.33.44, thus this operation can succeed. > > > > => the "then is bound to" is our point: how is it done? > > Phase-II is _ALWAYS_ bound to phase-I, because the phase-II > negotiation is completed within the protection of a phase-I SA. That > gives you the binding between phase-I and phase-II. The two phases > are _NOT_ independent. You cannot complete a phase-II without having > a completed (and valid) phase-I. > > => but you justifies only the "this IKE SA connection is bound to my laptop", > not the second binding. Wrong. Phase-I binds "this IKE SA is bound to my laptop." Phase-II leverages off that binding. The home agent knows that "your laptop" owns home address 11.22.33.44, so it will authorize the phase-II SA for your home address based upon the authentication in phase-I. This is just standard tunnel mode, and it exists today. Remember that the internal address of the tunnel need not be the same as the external address of the tunnel. Your policy defines what internal addresses are allowed through a tunnel based on your endpoint authentication from phase-I. > 1) Client identifies itself > 2) Client authenticates as identity > 3) Server verifies authentication and returns an error if it fails > 4) Client makes a request for a mobile-host binding <-- action > 5) Server looks up identity in policy database > a) verifies that binding matches policy > b) if not, return an error > c) if binding matches policy db, perform the binding > > Steps 1, 2, and 3 are already done by IPSec. Steps 4 and 5 are > somewhat IPSec and somewhat MobileIP. > > => my concerns are steps 4 and 5: IPsec doesn't really explain how they > are done and Mobile IP only requires them... That's why we're writing standards -- they don't just magically appear! But snide comments aside, you _can_ do this today: you set your policy to build a tunnel that authorizes your mobile host (based on some identification) to tunnel packets as your home address. Seriously, it is that simple. I admit that _how_ you set your policy is IPSec implementation specific. However, _what_ you need to setup isn't. For example, you want to configure your tunnel something like this: On the mobile host: type=tunnel server=11.22.0.1 server_id=server.my.site <- used to authenticate home agent my_inside_addr=11.22.33.44 my_auth_id=laptop.my.site <- my authentication ID On the home agent: type=tunnel client_id=laptop.my.site <- used to authenticate mobile host client_inside_addr=11.22.33.44 my_auth_id=server.my.site <- my authentication ID > Thanks You're welcome. > Francis.Dupont@enst-bretagne.fr -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jan 4 17:50:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19097; Thu, 4 Jan 2001 17:50:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA10526 Thu, 4 Jan 2001 19:23:26 -0500 (EST) Message-Id: <200101050025.f050P5O12949@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Derek Atkins cc: Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. In-reply-to: Your message of 04 Jan 2001 17:03:23 EST. Date: Fri, 05 Jan 2001 01:25:05 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: But snide comments aside, you _can_ do this today: you set your policy to build a tunnel that authorizes your mobile host (based on some identification) to tunnel packets as your home address. Seriously, it is that simple. I admit that _how_ you set your policy is IPSec implementation specific. However, _what_ you need to setup isn't. For example, you want to configure your tunnel something like this: On the mobile host: type=tunnel server=11.22.0.1 server_id=server.my.site <- used to authenticate home agent my_inside_addr=11.22.33.44 my_auth_id=laptop.my.site <- my authentication ID On the home agent: type=tunnel client_id=laptop.my.site <- used to authenticate mobile host client_inside_addr=11.22.33.44 my_auth_id=server.my.site <- my authentication ID => so your proposal is to use the manual setup. At least one free implementation has this, in FreeS/WAN this gives on the home agent: conn my_laptop type=transport auth=ah authby=rsasig auto=add left=%any leftid=@laptop.my.site leftsubnet=/128 right= rightid=@server.my.site rightsubnet=/128 (I don't use Linux or FreeS/WAN but this should work according to the documentation). So we can say the issue is solved for the home agent but of course manual config doesn't scale and won't work for random correspondents, ie. we should look for an automatical and standardized way to do this... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Jan 4 19:31:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA20923; Thu, 4 Jan 2001 19:31:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA10827 Thu, 4 Jan 2001 21:15:53 -0500 (EST) To: Francis Dupont Cc: Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. References: <200101050025.f050P5O12949@givry.rennes.enst-bretagne.fr> From: Derek Atkins Date: 04 Jan 2001 21:18:05 -0500 In-Reply-To: Francis Dupont's message of "Fri, 05 Jan 2001 01:25:05 +0100" Message-ID: Lines: 50 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont writes: [my example snipped] > => so your proposal is to use the manual setup. At least one free > implementation has this, in FreeS/WAN this gives on the home agent: No, I was just giving that as an example of one way of doing it. You could just as easily use DNSSec to do key distribution. [freeswan example snipped] > So we can say the issue is solved for the home agent but of course > manual config doesn't scale and won't work for random correspondents, > ie. we should look for an automatical and standardized way to do this... Well, as I said, you don't need to use manual config. Well, that's not true -- the home agent does need to be configured with it's mobile hosts, so frankly requiring some "manual" configuration is not asking a lot. However, you could still use DNSSec for keying information. Indeed, the home agent could just assume that all hosts within its domain are reasonable mobile hosts and use DNSSec keying appropriately. There, no manual keying :) As for random correspondants who aren't using the home address, you have a much harder problem. Personally, I would punt on IPSec to solve that problem and just build a signed message that contains the home address, care-of address, current time, and ttl (and maybe other information). Then you can send that binding message to anyone you wish. Correspondant nodes can obtain keys from DNSSec to verify the message, based on the home address. The only problem with this approach is that you cannot prove that you are authorized to use that care-of address. The only way to solve _that_ problem is to require the foreign agent to sign the binding update as well. But then corresponding nodes need to know that the foreign agent is authoritative for its domain. I don't know how you can do that, but you could probably build that into DNSSec as well, perhaps as a TXT record. > Thanks > > Francis.Dupont@enst-bretagne.fr -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Jan 5 05:02:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10431; Fri, 5 Jan 2001 05:01:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12296 Fri, 5 Jan 2001 06:17:23 -0500 (EST) Message-Id: <200101051118.f05BIVO25712@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Derek Atkins cc: Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. In-reply-to: Your message of 04 Jan 2001 21:18:05 EST. Date: Fri, 05 Jan 2001 12:18:31 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Francis Dupont writes: [my example snipped] > => so your proposal is to use the manual setup. At least one free > implementation has this, in FreeS/WAN this gives on the home agent: No, I was just giving that as an example of one way of doing it. You could just as easily use DNSSec to do key distribution. => the problem of key distribution is a bit different. Today DNSSEC is not really available and X.509v3 certificates are used (this raises two issues: - no common PKI - no standardized way to bind the identity to the home address (DNS has builtin name-address binding so DNSSEC is far better, unfortunately I should have written "will be far better")). [freeswan example snipped] > So we can say the issue is solved for the home agent but of course > manual config doesn't scale and won't work for random correspondents, > ie. we should look for an automatical and standardized way to do this... Well, as I said, you don't need to use manual config. Well, that's not true -- the home agent does need to be configured with it's mobile hosts, so frankly requiring some "manual" configuration is not asking a lot. => I agree for the home agent but this argument doesn't work for "random" correspondents. As for random correspondants who aren't using the home address, you have a much harder problem. Personally, I would punt on IPSec to solve that problem and just build a signed message that contains the home address, care-of address, current time, and ttl (and maybe other information). => this kind of message will be sent by the mobility code but after SAs are established. The order of operations are: - the mobile initiates a phase I using its care-of address (ie. using direct communication as a "road warrior") - the mobile establishes SAs in phase II for its home address - the mobile sends a mobile "binding update" which must be authenticated, checked for integrity and protected against replay (both by IPsec and an internal sequence number). From a IPsec point of view, the binding update message seems to come from the home address. The issue is to solve the authorization in phase II and mobile IPv6 relies on IPsec policy to do this so the issue is how to express this kind of policy. We have proved that manual config works but we need a more scalable way (DNSSEC seems to be a good proposal because it knows how to bind securely a name to an address but we should write down details and wait for DNSSEC if we'd like to deploy this solution). Then you can send that binding message to anyone you wish. Correspondant nodes can obtain keys from DNSSec to verify the message, based on the home address. => we should write down the details, for instance what is used for DNSSEC lookup (a name from phase I identity or the home address). The only problem with this approach is that you cannot prove that you are authorized to use that care-of address. => this doesn't matter: this is a visited network problem. The only way to solve _that_ problem is to require the foreign agent to sign the binding update as well. => there is no foreign agent in mobile IPv6... Thanks Francis.Dupont@enst-bretagne.fr PS: is there other IPsec implementation usage of DNSSEC than FreeS/WAN experimental key distribution? PPS: a raw proposal is to encode the phase I identity into a DNS name (easy for FQDN :-) and to put an A/A6/AAAA RR to the home address signed with a SIGN RR using the mobile node private key. From owner-ipsec@lists.tislabs.com Fri Jan 5 05:03:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10514; Fri, 5 Jan 2001 05:03:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA12316 Fri, 5 Jan 2001 06:19:53 -0500 (EST) Message-ID: <3A55ADF1.828381E2@nomadiclab.com> Date: Fri, 05 Jan 2001 13:20:17 +0200 From: Pekka Nikander X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mohan Parthasarathy CC: ipsec@lists.tislabs.com, Richard Draves Subject: Re: Mobile IPv6 - IPsec interaction. References: <200101042134.f04LYNO12362@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let me try to summarize some of the discussion concerning IKE and IPSEC to create SA's for MIPv6 BUs, and state some underlying assumptions that I consider problems. I've stated the underlying assumptions only in the very end of this message; thus, you might want to skip directly there. First background for those that have not followed: The original question was raised at the mobileip mailing list, where Richard Draves proposed a change to draft-ieft-mobile-ipv6-13.txt, stating that "The security association protecting a Binding Update MUST explictly authorize the mobile node to use the affected Home Address. Simply authenticating the mobile node to the correspondent node is not sufficient." This proposal was followed by some confusion about what IPSEC can do and should do. Finally, the discussion was moved to ipsec mailing list. After some discussion on this mailing list, it seems like the following undestanding has emerged. (Note that in all of the following, the term "MIP6 SA" refers to an IPSEC security association that is used to protect MIP6 signalling, i.e., binding updates and acknowledgements.) 1. The security requirements for the MIP6 SA are different depending on whether it is used a) between a MN and its (primary) HA b) between a MN and a CN Personally, I'd like to add a third item to this list c) between a MN, and a temporary HA as of MIP6 draft sec 10.9 Establishing Forwarding from a Previous Care-of Address 2. In each case, the server (HA or CN) needs to have some local policy that allows it to determine if the MN is allowed to use the Home Address, and therefore allowed to create the MIP6 SA that is bound to the particular home address. To slightly reword the algorithm Derek Atkins outlined, the server does the following checks: In IKE Phase I 1) The client hands the server some identifier (e.g. FQDN) 2) The client authenticates itself, i.e., provides cryptographic evidence that is knows a particular private key (or a pre-shared key). 3) The server verifies the authentication. To do this, it needs to have some credentials proving that the client authentication really corresponds with the identifier given by the client. Typically, the credentials are passed in the form of a certificate, but already them could be based on a local policy. In IKE Phase II 4) The client requests the MIP6 SA to be created, i.e., asks for an SA between its home address and the server address 5) The server decides, based on its local policy, whether it is OK to create the SA. Typically, the identifier verified in step 2 is used as an index to do the lookup in the policy database. The real problem is in step 5, in defining the requirements for the local policy. 3. For the MN - HA case (case a), the situation seems to be clear for the most part. In general, the consensus seems to be that most home agents want to know their mobile hosts, and therefore they need to be manually configured to recognize those hosts. Thus, that manual configuration can also easily take care of defining the local policy. 4. The use of IPSEC SA between a MN and a CN is another issue. Some people suggest that a global PKI (like DNSSEC) could be used to solve the problem, some propose not using IPSEC, etc. -------- Now we get to the underlying assumptions, or to the question why the authorization is needed in the first place. I agree that we do need authorization, but the exact reasons for the need seems to be unclear to me. Let me try to analyze a little bit. I'll consider the three cases above, MN--HA, MN--CN and MN--temporary HA separately. (Please note that I _must_ include some trivial issues below; it is often in the unstated assumptions where the problems lie.) 1. MN--HA Everybody seems to want to limit which hosts are able to use their "own" home agent. But why? In the IPv4 world, this mostly makes sense since IP addresses are scarce, most firewalls filter traffic based on IP addresses, and many hosts partially base their access control decisions on IP addresses. But, IMHO, the IPv6 world _should_ be different. IN IPv6, addresses are abundant and dynamic; especially, if you use random host ID's (the privacy extension), your addresses will change all the time. Thus, in many cases firewalls and host access control cannot any more be based on addresses alone; on the other hand, routing prefixes can often be used to do filtering, but I personally would consider that bad practice (see below). Based on this, there seems to be at least the following four reasons for limiting the hosts' ability to use a particular home agent: a) to make sure that whenever I send a packet to a particular address, it really goes to the host I suppose it is going to b) to limit the ability to use a particular routing prefix so that a firewall or other access control system can do its job c) to limit resource consumption d) to allow a charge to be applied on use, or otherwise limit the use for administrative reasons Of these, the use of routing prefixes for access control (reason b) seems like a bad approach. To me, it seems like that in IPv6 world even the routing prefixes will be somewhat dynamic (consider e.g. router renumbering), and there are a number of mechanisms that require IPSEC in order to authenticate legitimite usage of a particular address. That is, in addition to MIP6 Binding Updates there are, at least, the routing extension and the generic packet tunneling specification. And then we have all the problems found in current IPv4 based VPN tunneling. Furthermore, due to the dynamic nature of IP addresses, the address uniqueness requirement (reason a) may not be that important either. That is, you definitely want to keep your home address once you've got it, at least for some time, but you don't necessarily care what happens to it once you let it go. IMHO, the situation is very similar to the current case of using DHCP assigned addresses. 2. MN--CN In the typical MN--CN case, the MN and CN belong to different organizations. In that case, the CN does not really care which home address (and home agent) the MN claims to use. If it wants to do access control, it should base it on IP addresses anyway, but on other means (e.g. IPSEC or SSL). Therefore, it seems like the only reason why the CN should be interested in the home address is reachability. That is, the CN wants to know if it really can reach the MN through the claimed home address, and that is all. (Are there any other reasons?) Actually, the CN is more interested in knowing that it can reach the same host through the consequtive care-of- addresses that it will be receiving in BUs. Home address is not so different for the CN: it is only used if the CN loses track of the current COA or if the MN returns home. 3. MN--temporary HA In section 10.9 of the MIP6 draft, a method is specified where a MN creates a temporary registration on a HA on the previously visited network. The purpose of this registration is to forward packets that are sent with the old COA. I think this situation is the most interesting one from security point of view. A basic security problem here is someone may want to try to create a temporary HA registration just in order to divert your traffic. Thus, to me, it seems like the most important issue here is to bind the HA registration to the original care-of-address assignment. Now, in MIP6 CoA assignment may be based on either stateless or statefull (DHCPv6) autoconfiguration (MIP6 sec 10.5). Typically, neither of these methods provide any security other than requiring physical access to the link. Thus, the current standards and drafts do not seem to appropriately solve this problem. One possible direction for seeking for a solution would be to create a SA between the MN and the visited network HA already _before_ the MN leaves the link. In that case, the SA creation could use link local addresses, thereby providing assurance that the MN really has access to the link and really is using the stated host ID at the link. --Pekka Nikander From owner-ipsec@lists.tislabs.com Fri Jan 5 06:12:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13805; Fri, 5 Jan 2001 06:12:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12667 Fri, 5 Jan 2001 07:38:02 -0500 (EST) Message-Id: <200101042211.f04MBSO06187@cis.upenn.edu> To: Derek Atkins Cc: Francis Dupont , Tero Kivinen , Mohan Parthasarathy , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. In-reply-to: Your message of "04 Jan 2001 17:03:23 EST." Date: Thu, 04 Jan 2001 17:11:28 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Derek Atkins writes: > >Unfortunately there is no standard certificate exchange format for >IPSec (yet?). But you are right, if you have a real certificate with >a real i-d binding, then yes, you don't need to include the key in the >policy, the identification is sufficient. Even PKIX is sufficient for *that* (use the SubjAltName), and most implementations (not FreeSWAN) support that. >But snide comments aside, you _can_ do this today: you set your policy >to build a tunnel that authorizes your mobile host (based on some >identification) to tunnel packets as your home address. Seriously, it >is that simple. I admit that _how_ you set your policy is IPSec >implementation specific. However, _what_ you need to setup isn't. Absolutely. I know OpenBSD supports this, and I believe KAME does as well. I'd be surprised if major vendors can't do this as well. -Angelos From owner-ipsec@lists.tislabs.com Fri Jan 5 13:55:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA14138; Fri, 5 Jan 2001 13:55:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16939 Fri, 5 Jan 2001 15:19:34 -0500 (EST) Message-ID: <3A562DF5.E302DA36@nomadiclab.com> Date: Fri, 05 Jan 2001 22:26:29 +0200 From: Pekka Nikander X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fi MIME-Version: 1.0 To: Francis Dupont Cc: Mohan Parthasarathy , Richard Draves , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. References: <200101051616.f05GFvO45203@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Francis, I am sending this to the list, as well. I wish you do not get upset. I'd prefer to have this discussion open.] > (Note that in all of the > following, the term "MIP6 SA" refers to an IPSEC security > association that is used to protect MIP6 signalling, i.e., > binding updates and acknowledgements.) > > => in fact it is a SA pair. I stand corrected. I agree that if you want to have your binding updates acknowledged (and you do), you need to have a pair of IPSEC SAs. > 1. The security requirements for the MIP6 SA are different > depending on whether it is used > > => security requirements themselves are not different but the context > where they can be provided is very different. Well, what I was trying to say, _fundamentally_, is that the even the security _requirements_ are different, depending on the party are considering. The different parties have different interest, and therefore their security requirements are different. > Now we get to the underlying assumptions, or to the question > why the authorization is needed in the first place. I agree > that we do need authorization, but the exact reasons for the > need seems to be unclear to me. > > => mobility signaling is the best impersonating tool you can imagine. I agree. It is one of the best impersonating tools. Unfortunately, IPv6 offers you a number of almost equally good alternatives, including the routing extension header and generic tunneling. > 1. MN--HA > > a) to make sure that whenever I send a packet to a > particular address, it really goes to the host I > suppose it is going to > > c) to limit resource consumption > > => I believe main reasons are points a (impersonate attack) and c (DoS). I do agree with DoS resistance. However, IMHO, in the IPv6 it will be _much_ harder to "know" the host a certain address belongs to, at the given moment fo time, than in the current IPv4 world. As I tried to argument, it seems like most addresses will no longer be static. Sure, there will be also static addresses like the addresses of root name servers and many big web and corporate servers. But the majority of clients will use stateless autoconfiguration, and may be using series of different addresses. Thus, if you have an address, you do not necessarily know for sure whom packets sent to it will reach. Thus, I think that we could divide the point a) into two subpoints. a1) During a certain period, i.e., address lifetime, I want to have _some_ assurance that the packets sent to a certain address will be received by the very same host. It seems like a typical _client_ address lifetime will range from tens of minutes to a few days. If I want to have _high_level_ assurance that the the same host is all the time receiving the packets, I need to use IPSEC or SSL anyway. (Yes, I know, some people strongly disagree with me. They want the client addresses to be static. But I don't believe that they ever will.) a2) Ethernally (or at least for a long time like months or years), I want _high_level_ assurance that the packets send to a certain address will be received by the very same host, all the time. I, personally, would consider these two requirements _very_ different. Basically, my argument is that we want to have a1), and that it is practically impossible to provide a2), at least without explicit IPSEC, anyway. Thus, I would consider the following point of yours to be covered by requirement a1).... > => even if you wouldn't care of previous addresses you should like > to be the only node using your current address, ie. be protected > against connection thefts (and in this case (MN--HA) one can > steal many connections). ... thus, I basically agree with you. Fortunately, providing the requirement a1) does not necessarily need manual configuration. It is only the other requirements that need manual configuration. > 2. MN--CN > > In the typical MN--CN case, the MN and CN belong to different > organizations. In that case, the CN does not really care which > home address (and home agent) the MN claims to use. If it wants > to do access control, it should base it on IP addresses anyway, > but on other means (e.g. IPSEC or SSL). > > => I disagree, the MN cares that the CN cares (for existing connections > or for new connections, of course for the second case you'd like > to mandate DNSSEC too). Well, let us see. If we assume that the CN is a typical web server, I cannot imagine how it could possibly care? To the web server, the important thing is to get the content delivered. I really can't see how its administrators would be careful enough to configure it to check that an arbitrary mobile host is really entitled to use a certain home address. For them, it is the MN's business, anyway. On the other hand, I can easily imagine that the OS vendors, for the sake of Internet integrity, would include some default mechanisms in their IPv6 implementation. One of these mechanisms could be checking the reachability of the MN through the claimed home address. For example, when the MN hands over the home address in IKE Phase II, the CN could reply using the home address (thereby making the packet to be tunneled by the Home Agent). If the MN indeed gets the packet, and replies to it, the CN knows that the MN is able to use receive packets through the home address. I think that something like this is the best we can ask for without a global PKI. Thus, the basic distinction here is that a global PKI is hard to establish, and requires care by the administrators. On the other hand, a simple home address reachability test can be engineered into the IPv6 implementations. > 3. MN--temporary HA > > In section 10.9 of the MIP6 draft, a method is specified where a > MN creates a temporary registration on a HA on the previously > visited network. The purpose of this registration is to forward > packets that are sent with the old COA. I think this situation > is the most interesting one from security point of view. > > => this is less interesting if the SA is built before to move, ie > with the current CoA which will take the home address role > (phase I & II identities will be the same, no authorization problem). Right. Creating the SA before the move simplifies things. Thus, maybe we should rewrite this section of the MIP6 draft? Currently it suggest that the SA is created only after the move. On the other hand, unfortunately I disagree with you in that there would be no authorization problems. Let me think about this for a while, and I am sure I can come up with some kind of an attack. At least if you allow globally routable addresses to be used, and if you do not assume a global PKI, and maybe even if you do assume a global PKI. :-) > A basic security problem here is someone may want to try to > create a temporary HA registration just in order to divert > your traffic. Thus, to me, it seems like the most important > issue here is to bind the HA registration to the original > care-of-address assignment. Now, in MIP6 CoA assignment > may be based on either stateless or statefull (DHCPv6) > autoconfiguration (MIP6 sec 10.5). Typically, neither of > these methods provide any security other than requiring > physical access to the link. Thus, the current standards > and drafts do not seem to appropriately solve this problem. > > => the visited network security is another problem which is > in the AAA scope. Well, I think that there are two separate problems. The first one is the visited network access control problem, i.e., the problem whether the MN should be given an address in the visited network. That definitely belongs to the AAA scope. However, I was trying to clarify a separate problem, that is, given that the MN is allowed to have an address in the visited network, how does the HA in the visited network know that the particular MN really was using a particular address in the visted network, and is actually authorized to ask for forwarding? For example, suppose that the visited network has no access control but instead accepts all MNs. In that case, the simples way is to use stateless autoconfiguration, without any security, to give an address to the MN. Now, there really is a problem when and how the HA in the visited network should allow temporary forwarding. > One possible direction for seeking for a solution would be > to create a SA between the MN and the visited network HA > already _before_ the MN leaves the link. > > => of course you should do that! But, as I said, the current draft tells you to do otherwise. > => to use link-local addresses will only make things more complex. Maybe. But they give you an added level of security. You _know_ that the peer is actually connected to the same link. Yours, --Pekka Nikander From owner-ipsec@lists.tislabs.com Fri Jan 5 18:29:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA18075; Fri, 5 Jan 2001 18:29:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28575 Fri, 5 Jan 2001 19:57:46 -0500 (EST) Message-ID: <10C8636AE359D4119118009027AE9987064C41AC@FMSMSX34> From: "Walker, Jesse" To: ipsec@lists.tislabs.com Subject: Aggressive/Base Mode Signature Queries Date: Fri, 5 Jan 2001 16:59:31 -0800 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 Suppose you share CAs C1 and C2 with some peer B. C1 issues you a certificate Cert(A1,C1) under the name A1, and C2 issues you a certificate Cert(A2,C2) under the name A2, with A1 != A2. Similar B gets certificates Cert(B1,C1) issued by C1 and Cert(B2,C2) issued by C2. If you believe you share both CAs with B, then for aggressive mode you might as well use either of your certificates to authenticate yourself, say the cert issued by C1. So you send the first agressive mode message: (1) HDR, SA, KE, Ni, IDii(A1), CertReq(C1) ----> Here the notation IDii(A1) denotes the initiator's ID payload conveying its identity A1, and CertReq(C1) denotes the optional Certificate Request payload requesting a certificate (chain) signed by C1. There seems to be nothing in the protocol preventing the peer from responding (2) <---- Hdr, SA, KE, Nr, IDrr(B1), Cert(B1,C1), Sig(B1), CertReq(C2) Here IDDrr(B1) denotes the peer's ID payload conveying its identity B1 taken from the cert(B1,C1), Sig(B1) B's signatures using the private key corresponding to Cert(B1,C1), and CertReq(C2) is a request for a certificate from you signed by CA C2. B might make such a response, because its local policy says that it should always authenticate initiating peers using certificates issued by C2. In the third message the protocol says you are supposed to send (3) HDR, Sig(A2), Cert(A2,C2) ----> This seems like a problem, because the name A2 from the certificate Cert(A2,C2) does not match the name A1 from the ID payload IDii(A1) from message (1). You'd think B would not want to accept such a message, as if A can get dupe D into computing the signature Sig(D2) using certificate Cert(D2,C2) for him, B would accept A as D: HDR, Sig(D2), Cert(DA2,C2) ----> Since the protocol does not seem to forbid (2) as a response to (1), it will most certainly arise at some time. We can think of a number of potential implementations to address this circumstance. For the responder, some possibilites seem to be: a. B could respond to (1) with (2), as above, or b. B could decide that (1) is not really proper, because it is insisting that initiating peers use certificates issued by C2. In that case, B would respond with a Notify returning INVALID-CERT-AUTHORITY error, or it might ignore (1) entirely. c. B could decide that response (2) is wrong, and respond to (1) only with (2') <---- Hdr, SA, KE, Nr, IDrr(B1), Cert(B1,C1), Sig(B1) or (2'') <---- Hdr, SA, KE, Nr, IDrr(B1), Cert(B1,C1), Sig(B1), CertReq(C1) where C1 is the CA from (1). Alternative a does not appear to be a good idea, since it opened this can of worms in the first place, but it is not precluded by the protocol spec. Alternatives b and c both seem better and are not necessarily mutually exclusive, but neither are required by the protocol in this situation, and it is not evident that either allows full scope to local policy. Some possibilities for the initiator are: d. The initiator could respond as above by sending (3) in response to (2). As indicated, we beleive many implementations will abort the negotiation at this point because A2 != A1. Hence communications will not always be possible with this course. e. The initiator also might abandon the original negotiation on the receipt of (2). Instead, it restarts the dialog with a new message (1') HDR, SA, KE, Ni, IDii(A2), CertReq(C2) ----> since B has expressed a preference for certificates issued by C2. This should work, but it introduces a bit of computational overhead in the responder for returning such a pig-headed response; people get what they pay for. But what if the initiator's local policy might be to authenticate all responders using CA C1 and never CA C2? Nope; wrong again. f. The initiator could try to insert a new ID payload in its third message, even though ISAKMP and IKE don't give us any reason to think this is allowed: (3') HDR, Sig(A2), IDii(A2), Cert(A2,C2) ----> and we don't see why B would have any reason for accepting this, either, since A1 != A2. g. The initiator might try to circumvent the whole problem by sending "duplicate" requests in (1): (1'') HDR, SA, KE, Ni, IDii(A1), CertReq(C1) ----> HDR, SA, KE, Ni, IDii(A2), CertReq(C2) ----> and then respond to the first response it receives. It looks like any alternative the initiator pursues (at least any we've thought of) is a bad idea. Another possibility is to require every implementation supporting more than one CA to provide policy parameters allowing the administrator to specify which behavior(s) a-g to use in this circumstance. This does not appear to be a winning strategy, in part because administrators could never figure out how to set the parameters. Yet another possibility is to try to eliminate the whole problem by declaring this is a non-issue, because the initiator must be configured to use the right certificate and that it should have sent HDR, SA, KE, Ni, IDii(A2), CertReq(C1) ----> instead of (1) to begin with. However, the specification does not mandate this, either, and again requiring yet more configuration does not appear to be a winning strategy for getting the world to adopt certificate-based authentication and IPsec. Yet another possibility is just not to support Agressive mode with digital signatures. Maybe there are other alternatives we've overlooked. Since we want our implementation to interoperate with others, the question is how do other implementations handle this situation? A similar question obtains for Base mode. -- Jesse Walker From owner-ipsec@lists.tislabs.com Sat Jan 6 16:01:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17976; Sat, 6 Jan 2001 16:01:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA20963 Sat, 6 Jan 2001 16:40:38 -0500 (EST) X-Authentication-Warning: taulu.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14935.37215.469058.355427@taulu.hel.fi.ssh.com> Date: Sat, 6 Jan 2001 23:42:55 +0200 From: Tero Kivinen To: "Walker, Jesse" Cc: ipsec@lists.tislabs.com Subject: Aggressive/Base Mode Signature Queries In-Reply-To: <10C8636AE359D4119118009027AE9987064C41AC@FMSMSX34> References: <10C8636AE359D4119118009027AE9987064C41AC@FMSMSX34> X-Mailer: VM 6.88 under Emacs 20.7.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Walker, Jesse writes: > (1) HDR, SA, KE, Ni, IDii(A1), CertReq(C1) ----> > (2) <---- Hdr, SA, KE, Nr, IDrr(B1), Cert(B1,C1), Sig(B1), CertReq(C2) > In the third message the protocol says you are supposed to send > (3) HDR, Sig(A2), Cert(A2,C2) ----> No. You are supposed to send (3) HDR, Sig(A1), Cert(A1,C1) ----> The signature must be using the certificate that matches the identity you already sent. If the responder does not trust the C1, then it will reject the negotiation. If it trusts C1, then the negotiation will succeed. If you selecteded wrong CA in the first place, then you need to use main mode instead of aggressive mode. Aggressive mode does not offer you an option to negotiate which CA to use. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Jan 7 13:05:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01834; Sun, 7 Jan 2001 13:05:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13665 Sun, 7 Jan 2001 14:01:07 -0500 (EST) Message-Id: <200101071902.f07J2dO66629@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: Mohan Parthasarathy , Richard Draves , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. In-reply-to: Your message of Fri, 05 Jan 2001 22:26:29 +0200. <3A562DF5.E302DA36@nomadiclab.com> Date: Sun, 07 Jan 2001 20:02:39 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > => mobility signaling is the best impersonating tool you can imagine. I agree. It is one of the best impersonating tools. Unfortunately, IPv6 offers you a number of almost equally good alternatives, including the routing extension header and generic tunneling. => I disagree about routing header and tunneling because mobility changes the ultimate destination itself. > 1. MN--HA > > a) to make sure that whenever I send a packet to a > particular address, it really goes to the host I > suppose it is going to > > c) to limit resource consumption > > => I believe main reasons are points a (impersonate attack) and c (DoS). I do agree with DoS resistance. However, IMHO, in the IPv6 it will be _much_ harder to "know" the host a certain address belongs to, at the given moment fo time, than in the current IPv4 world. As I tried to argument, it seems like most addresses will no longer be static. => I disagree (I can see a far more static situation than you) but we don't know what will happen. Sure, there will be also static addresses like the addresses of root name servers and many big web and corporate servers. => only root name servers must have a static address. Other addresses will be rather static only because this is easier to manage static addresses than highly dynamic addresses. But the majority of clients will use stateless autoconfiguration, => stateless autoconfig gives always the same address if: - the prefix is not renumbered (even if renumbering is possible with IPv6 I can't see good reasons to renumber more often than every some months) - the MAC address (ie. the hardware) is not changed (and if you swap your Ethernet board every hours statefull autoconfig will provide a static address to you). The only case with frequent address changes is for privacy (ie. draft-ietf-ipngwg-addrconf-privacy-xx.txt) but in this case you don't want incoming connection or be registered in the DNS too. and may be using series of different addresses. Thus, if you have an address, you do not necessarily know for sure whom packets sent to it will reach. => "for sure" will need IPsec. Thus, I think that we could divide the point a) into two subpoints. a1) During a certain period, i.e., address lifetime, I want to have _some_ assurance that the packets sent to a certain address will be received by the very same host. It seems like a typical _client_ address lifetime will range from tens of minutes to a few days. => this will kill the DNS for sure. If I want to have _high_level_ assurance that the the same host is all the time receiving the packets, I need to use IPSEC or SSL anyway. (Yes, I know, some people strongly disagree with me. They want the client addresses to be static. But I don't believe that they ever will.) => I want the address to be as static as possible because to get dynamic addresses makes incoming connections too hard. Some ISPs use dynamic IPv4 addresses today because they have not enough addresses, this of course will be different with IPv6. a2) Ethernally (or at least for a long time like months or years), I want _high_level_ assurance that the packets send to a certain address will be received by the very same host, all the time. I, personally, would consider these two requirements _very_ different. Basically, my argument is that we want to have a1), and that it is practically impossible to provide a2), at least without explicit IPSEC, anyway. Thus, I would consider the following point of yours to be covered by requirement a1).... > => even if you wouldn't care of previous addresses you should like > to be the only node using your current address, ie. be protected > against connection thefts (and in this case (MN--HA) one can > steal many connections). ... thus, I basically agree with you. Fortunately, providing the requirement a1) does not necessarily need manual configuration. It is only the other requirements that need manual configuration. > 2. MN--CN > > In the typical MN--CN case, the MN and CN belong to different > organizations. In that case, the CN does not really care which > home address (and home agent) the MN claims to use. If it wants > to do access control, it should base it on IP addresses anyway, > but on other means (e.g. IPSEC or SSL). > > => I disagree, the MN cares that the CN cares (for existing connections > or for new connections, of course for the second case you'd like > to mandate DNSSEC too). Well, let us see. If we assume that the CN is a typical web server, I cannot imagine how it could possibly care? To the web server, the important thing is to get the content delivered. => for some contents it will be important to deliver them to the right place. I really can't see how its administrators would be careful enough to configure it to check that an arbitrary mobile host is really entitled to use a certain home address. => I believe its administrators will simply reject arbitrary IKE request (the important thing is not to waste CPU cycles in big number computations :-). For them, it is the MN's business, anyway. On the other hand, I can easily imagine that the OS vendors, for the sake of Internet integrity, would include some default mechanisms in their IPv6 implementation. => for instance use DNSSEC to check the home address or simply reject IKE phase II or the binding update (I expect to have Web servers rejecting binding updates because common sessions are short term). One of these mechanisms could be checking the reachability of the MN through the claimed home address. => this supposes deep changes in IKE on CNs. Perhaps it works but nobody will buy it. For example, when the MN hands over the home address in IKE Phase II, the CN could reply using the home address (thereby making the packet to be tunneled by the Home Agent). If the MN indeed gets the packet, and replies to it, the CN knows that the MN is able to use receive packets through the home address. I think that something like this is the best we can ask for without a global PKI. => for the sake of Internet integrity a global PKI is needed. Of course some people will disagree so let us assume the global PKI issue is solved. Thus, the basic distinction here is that a global PKI is hard to establish, and requires care by the administrators. On the other hand, a simple home address reachability test can be engineered into the IPv6 implementations. => phase I will work with signatures and certificates so some kind of global PKI should be there one day (ASAP :-). > 3. MN--temporary HA > > In section 10.9 of the MIP6 draft, a method is specified where a > MN creates a temporary registration on a HA on the previously > visited network. The purpose of this registration is to forward > packets that are sent with the old COA. I think this situation > is the most interesting one from security point of view. > > => this is less interesting if the SA is built before to move, ie > with the current CoA which will take the home address role > (phase I & II identities will be the same, no authorization problem). Right. Creating the SA before the move simplifies things. Thus, maybe we should rewrite this section of the MIP6 draft? Currently it suggest that the SA is created only after the move. => I disagree, it suggest nothing... On the other hand, unfortunately I disagree with you in that there would be no authorization problems. => there is no authorization problem from mobility because the MN uses and will use its current/local care-of address. Of course to have a local address is not enough to be authorized to do anything, but this is not a mobility issue (ie. this is more in AAA scope). Let me think about this for a while, and I am sure I can come up with some kind of an attack. At least if you allow globally routable addresses to be used, and if you do not assume a global PKI, and maybe even if you do assume a global PKI. :-) => of course they are some kind of attacks or radius/AAA is only for accounting (:-). But they are not from mobility, ie. they are not in the scope of this discussion. > A basic security problem here is someone may want to try to > create a temporary HA registration just in order to divert > your traffic. Thus, to me, it seems like the most important > issue here is to bind the HA registration to the original > care-of-address assignment. Now, in MIP6 CoA assignment > may be based on either stateless or statefull (DHCPv6) > autoconfiguration (MIP6 sec 10.5). Typically, neither of > these methods provide any security other than requiring > physical access to the link. Thus, the current standards > and drafts do not seem to appropriately solve this problem. > > => the visited network security is another problem which is > in the AAA scope. Well, I think that there are two separate problems. The first one is the visited network access control problem, i.e., the problem whether the MN should be given an address in the visited network. That definitely belongs to the AAA scope. => we agree. However, I was trying to clarify a separate problem, that is, given that the MN is allowed to have an address in the visited network, how does the HA in the visited network know that the particular MN really was using a particular address in the visted network, and is actually authorized to ask for forwarding? => we can divide this in two parts: - authorization to establish SA (AAA problem) - authorization to use the local HA for temporary forwarding The simplest answer is to rely on the first part, ie. reject SA establishment after movement and limit the number of visitors with SA to a reasonnable level. For example, suppose that the visited network has no access control but instead accepts all MNs. In that case, the simples way is to use stateless autoconfiguration, without any security, to give an address to the MN. Now, there really is a problem when and how the HA in the visited network should allow temporary forwarding. => without access control you cannot use clever management of ressources (ie. you are limited to basic policies like first-in/first-served with a hard limit). > One possible direction for seeking for a solution would be > to create a SA between the MN and the visited network HA > already _before_ the MN leaves the link. > > => of course you should do that! But, as I said, the current draft tells you to do otherwise. => where? The current draft tells nothing. > => to use link-local addresses will only make things more complex. Maybe. But they give you an added level of security. You _know_ that the peer is actually connected to the same link. => I don't thing this will pay enough for the burden (and I have modified a IKE in order to support link-local addresses in phases I and II so this is not just a feeling :-). Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Sun Jan 7 14:45:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06687; Sun, 7 Jan 2001 14:45:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13972 Sun, 7 Jan 2001 16:06:02 -0500 (EST) Message-Id: <200101072107.f07L7JO67096@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: Mohan Parthasarathy , Richard Draves , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. In-reply-to: Your message of Sun, 07 Jan 2001 22:02:48 +0200. <3A58CB69.9F8A36D2@nomadiclab.com> Date: Sun, 07 Jan 2001 22:07:19 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: [I don't think there is anything _very_ important in this message. I think the important discussion will handle the case of MN-temporary HA, and I will give it a separate thread. => MN-temporary HA is an optimization. The important point is more scalable MN-CN IMHO. This message is more like a number of clarifications for minor points, and may not be that interested for some people. Most of the discussion concerns the disagreement between Francis and me about static vs dynamic IPv6 address assignment skenario.] > Sure, there will be also static addresses like the addresses of > root name servers and many big web and corporate servers. > > => only root name servers must have a static address. Other addresses > will be rather static only because this is easier to manage static > addresses than highly dynamic addresses. I agree to a large degree. Well, maybe I would rather say that IF we do not specify otherwise, a rather static situation is likely, but I would consider it bad. (See below.) > But the majority of clients will use stateless autoconfiguration, ... > => The only case with frequent address changes is for privacy > (ie. draft-ietf-ipngwg-addrconf-privacy-xx.txt) but in this case > you don't want incoming connection or be registered in the DNS too. Well, that is, if you assume that the majority of clients will be static, i.e., non-mobile clients. => a mobile client can get a static address (the home address). I don't believe you can bind mobility and dynamic address this way. I believe that the majority of clients will be mobile clients, and that some of them will not use any home addresses at all. => they will need static/home addresses for incoming calls. But even if we assume that they will use home addresses (a large portion may, anyway), then the question of whether the home addresses will be static or dynamic is a policy question. => I disagree. There are many advantages to have a static home address so users will ask for them. I agree that using a static policy, i.e., always giving out the same home address for the same host, is the easiest and simplest from the engineering point of view. => for the user point of view too. However, from the privacy point of view that may be a disaster. Since this is the ipsec mailing list, I assume that we should care about privacy, as I see privacy as a part of (personal) security. => the privacy is the only argument in favor of dynamic address but you can't have at the same time privacy and strong authentication (so I suggest to put mobility support for private addresses into the further study list because mobility requires strong authentication at least. > a1) During a certain period, i.e., address lifetime, I want to have > _some_ assurance that the packets sent to a certain address > will be received by the very same host. It seems like a > typical _client_ address lifetime will range from tens of > minutes to a few days. > > => this will kill the DNS for sure. How? => because this will require DNS TTL in order of minutes so a lot of DNS traffic and the end of DNS caching. As one approach, already know my laptop is know, at various times, as wsXXX.nomadiclab.com, where the XXX is likely to differ from time to time. => and how you can accept incoming connections? The Internet is an end-to-end network (or should be), not an online service. As the other approach, you can configure W2K to do dynamic DNS registration whenever it gets a new (IPv4) address. => you should not use W2K about what to do with DNS (:-). Seriously the purpose of DynDNS is more to provide an incremental and light weight tool for zone management than to support nomadism (it can do both but not with the same impact on the DNS infrastructure). I may be wrong, but my understanding is that DynDNS registration is not that much heavier than sending a BU to a home agent. => the indirect effect is very different (ie. short term DynDNS registration will make DNS caching inefficient, BUs are burden only for CNs which receive them). (If I am wrong, please educate me and indicate the relevant sections of the drafts/RFCs.) => RFC 1912 section 2.2 about TTL values (one day is considered as too short for the default value in this document). Or any document about DNS configuration... And, you would not be sending DynDNS updates that often; I would guess that the average rate might be something like from one to a few times a day. => the problem of updates is not in their direct traffic but with their indirect (ie. induced) traffic. The current DNS traffic is far higher than it should be, don't make things worse... > (Yes, I know, some people strongly disagree with me. They > want the client addresses to be static. But I don't believe > that they ever will.) > > => I want the address to be as static as possible because to get dynamic > addresses makes incoming connections too hard. Please teach me. I don't see how dynamic addresses will make handling of incoming connections any harder. Well, I can see how it makes address based filtering harder, but as I argued already, address based filtering is bad anyway, and should not be used. But how it will make it harder otherwise? => each time a dynamic address changes you need to update the DNS. In order to get the old address expired in DNS (and application) caches you must use very short TTLs. This makes the job of remote applications very expensive, in fact they should ask the DNS for your address each time they send a packet to you... > .... If we assume that the CN is a typical web server, > I cannot imagine how it could possibly care? To the web server, the > important thing is to get the content delivered. > > => for some contents it will be important to deliver them to the right place. Yes, for some content, sure. But if you want to know where you deliver your content, you need encryption, => no, you need only authentication by definition. and then you need well authenticated (and authorized) IPSEC or SSL for all traffic, not just a (pair of) simple AH SA(s) for authenticating BUs. => I've already seen this argument. Personnally I have nothing but to make as most as possible connections protected by IPsec (I don't like SSL because it is too often misused and it doesn't protect against some attacks like TCP resets, but this is out of the scope). To clarify: I believe that MIP6 BUs could be authenticated with a "low security" SA. The samantics of the low security SA would be "this SA is authorized to send BUs for this Home Address." Such an SA would not necessarily need any global PKI or anything like that. For such an SA, it is not important whom the address belongs to. It is enough to bind the address and the SA (the key). => what you are describing is a policy. On the other hand, if you want to know whom you send you content, you definitely want to know that the recipient is authorized to receive the content. For such a purpose, a "low security" SA is not enough. => again a policy issue. Maybe we should discuss this point separately? => I agree and I don't know if this kind of policies is commonly available/implemented (you have such a thing in SPDs but here you've asked for a phase I / phase II interaction far more complex than the one we need for mobility). > On the other hand, I can easily imagine that the OS vendors, for the > sake of Internet integrity, would include some default mechanisms > in their IPv6 implementation. > > => for instance use DNSSEC to check the home address or simply reject > IKE phase II or the binding update (I expect to have Web servers rejecting > binding updates because common sessions are short term). Good point. I stand corrected. I must reconsider my position wrt. the typical usage skenarios for MIP6. Thank you. => I believe the web CN is not a very good example because MNs will use web proxies. In fact the number of CNs used by a MN will be rather small, even with a static station we use a relay MTA, DNS server, Web proxy, ..., and we have active connections to a small number of nodes, most of them "well-known". Of course this won't be true with a mobile server... Thanks Francis.Dupont@enst-bretagne.fr PS: about MN-temporary HA: this is not an important issue and a potential temporary HA with a lot of MNs should be in a very special situation, likely a part of the design of the temporary HA with nice tools like a working AAA interfaced with IPsec and mobility (ie. we'll be allowed to assume more in this specialized context). From owner-ipsec@lists.tislabs.com Sun Jan 7 14:45:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06700; Sun, 7 Jan 2001 14:45:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13886 Sun, 7 Jan 2001 15:00:59 -0500 (EST) Message-ID: <3A58CB69.9F8A36D2@nomadiclab.com> Date: Sun, 07 Jan 2001 22:02:48 +0200 From: Pekka Nikander X-Mailer: Mozilla 4.76 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont Cc: Mohan Parthasarathy , Richard Draves , ipsec@lists.tislabs.com Subject: Re: Mobile IPv6 - IPsec interaction. References: <200101071902.f07J2dO66629@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [I don't think there is anything _very_ important in this message. I think the important discussion will handle the case of MN-temporary HA, and I will give it a separate thread. This message is more like a number of clarifications for minor points, and may not be that interested for some people. Most of the discussion concerns the disagreement between Francis and me about static vs dynamic IPv6 address assignment skenario.] --------- > I agree. It is one of the best impersonating tools. Unfortunately, > IPv6 offers you a number of almost equally good alternatives, > including the routing extension header and generic tunneling. > > => I disagree about routing header and tunneling because mobility > changes the ultimate destination itself. I don't think this belongs to the discussion about Mobile IPv6 - IPsec interaction. Thus, if you want to learn my argumentation, let's start a separate thread of discussion. --------- > Sure, there will be also static addresses like the addresses of > root name servers and many big web and corporate servers. > > => only root name servers must have a static address. Other addresses > will be rather static only because this is easier to manage static > addresses than highly dynamic addresses. I agree to a large degree. Well, maybe I would rather say that IF we do not specify otherwise, a rather static situation is likely, but I would consider it bad. (See below.) > But the majority of clients will use stateless autoconfiguration, ... > => The only case with frequent address changes is for privacy > (ie. draft-ietf-ipngwg-addrconf-privacy-xx.txt) but in this case > you don't want incoming connection or be registered in the DNS too. Well, that is, if you assume that the majority of clients will be static, i.e., non-mobile clients. I believe that the majority of clients will be mobile clients, and that some of them will not use any home addresses at all. But even if we assume that they will use home addresses (a large portion may, anyway), then the question of whether the home addresses will be static or dynamic is a policy question. I agree that using a static policy, i.e., always giving out the same home address for the same host, is the easiest and simplest from the engineering point of view. However, from the privacy point of view that may be a disaster. Since this is the ipsec mailing list, I assume that we should care about privacy, as I see privacy as a part of (personal) security. --------- > a1) During a certain period, i.e., address lifetime, I want to have > _some_ assurance that the packets sent to a certain address > will be received by the very same host. It seems like a > typical _client_ address lifetime will range from tens of > minutes to a few days. > > => this will kill the DNS for sure. How? As one approach, already know my laptop is know, at various times, as wsXXX.nomadiclab.com, where the XXX is likely to differ from time to time. As the other approach, you can configure W2K to do dynamic DNS registration whenever it gets a new (IPv4) address. I may be wrong, but my understanding is that DynDNS registration is not that much heavier than sending a BU to a home agent. (If I am wrong, please educate me and indicate the relevant sections of the drafts/RFCs.) And, you would not be sending DynDNS updates that often; I would guess that the average rate might be something like from one to a few times a day. ---------- > (Yes, I know, some people strongly disagree with me. They > want the client addresses to be static. But I don't believe > that they ever will.) > > => I want the address to be as static as possible because to get dynamic > addresses makes incoming connections too hard. Please teach me. I don't see how dynamic addresses will make handling of incoming connections any harder. Well, I can see how it makes address based filtering harder, but as I argued already, address based filtering is bad anyway, and should not be used. But how it will make it harder otherwise? ---------- > .... If we assume that the CN is a typical web server, > I cannot imagine how it could possibly care? To the web server, the > important thing is to get the content delivered. > > => for some contents it will be important to deliver them to the right place. Yes, for some content, sure. But if you want to know where you deliver your content, you need encryption, and then you need well authenticated (and authorized) IPSEC or SSL for all traffic, not just a (pair of) simple AH SA(s) for authenticating BUs. To clarify: I believe that MIP6 BUs could be authenticated with a "low security" SA. The samantics of the low security SA would be "this SA is authorized to send BUs for this Home Address." Such an SA would not necessarily need any global PKI or anything like that. For such an SA, it is not important whom the address belongs to. It is enough to bind the address and the SA (the key). On the other hand, if you want to know whom you send you content, you definitely want to know that the recipient is authorized to receive the content. For such a purpose, a "low security" SA is not enough. Maybe we should discuss this point separately? --------- > I really can't see > how its administrators would be careful enough to configure it to > check that an arbitrary mobile host is really entitled to use a > certain home address. > > => I believe its administrators will simply reject arbitrary IKE request > (the important thing is not to waste CPU cycles in big number computations :-). Well, I can't see most people taking that position for many many years. To them, taking that position would most probably mean that they lose business with almost all mobile hosts. Or that they are not able to use BUs and must send all traffic through the home agent, making most benefits of Mobile IPv6 void. But maybe it will be so, anyway, on the light of your next comment. (Yes, I know, IKE is not too DoS resistant today. But that problem should be fixed, anyway.) > On the other hand, I can easily imagine that the OS vendors, for the > sake of Internet integrity, would include some default mechanisms > in their IPv6 implementation. > > => for instance use DNSSEC to check the home address or simply reject > IKE phase II or the binding update (I expect to have Web servers rejecting > binding updates because common sessions are short term). Good point. I stand corrected. I must reconsider my position wrt. the typical usage skenarios for MIP6. Thank you. ---------- >> 3. MN--temporary HA I think that we are entering some very interesting discussion here. Thus, to keep the messages of manageable length, I will reply separately. --Pekka From owner-ipsec@lists.tislabs.com Sun Jan 7 15:39:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07364; Sun, 7 Jan 2001 15:39:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14077 Sun, 7 Jan 2001 17:16:29 -0500 (EST) Message-ID: <003c01c078f7$cd4cedc0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Stephen Kent" Cc: , , References: <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> <20001211082557.A2125@orca.informatik.uni-ulm.de> <3A362BA2.D7EF1481@piuha.net> <3A3F276E.D84D9839@piuha.net> Subject: Re: IPv6 Neighbour Solicitation messages and IPsec Date: Mon, 8 Jan 2001 00:18:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen writes: >I'm not an IPv6 expert, but it seems that the issue here is who emits the message, not just what ICMP >message is being emitted. >An IPsec implementation (gateway or host) has an ability to bypass control traffic that it emits, >irrespective of SPD contents. So, I would expect that ICMP messages used for neighbor solicitation, >advertisement, and autoconfig, etc. would fall into this category. True.Though I'm worried that we don't specify anywhere how to bypass and what, possibly leading to interoperability problems. >Today we provide port-level controls, for UDP and TCP traffic, so adding ICMP-specific controls >represents a significant change. We'll have to evaluate the requirement for this sort of change very > >carefully. Yes, I agree. ICMP-specific controls aren't the only option, by the way. We could also have IPsec implementations hard code the handling of certain messages. I've got a feeling that this is what implementors are doing. (True?) Please note also that it seems like we need to do *something*, i.e. the requested functionality isn't optional nice-to-have features. If we don't either specify the rules regarding some of these ICMPs and we don't give fine-grained control to the user, the chances are that implementation A isn't going to work with implementation B. For instance, in view of the the problems with Neighbour Advertisement messages, implementation A bypasses these messages alltogether (or at least for dynamic policies). Implementation B however chooses to bypass the messages when there is no SA yet, and to require the use of the SA when one has been negotiated. You can get A to talk to B, but if reachability detection kicks in (uses the NA messages too), packets stop flowing! >>Finally, I would propose that everywhere in the ICMPv6 specifications >>where it says "AH", tunnel mode ESP would suffice as well. > >This last suggestion is a topic for a different debate, and I would suggest >not including it in this discussion Yeah. You're right. Jari ---- http://www.arkko.com From owner-ipsec@lists.tislabs.com Mon Jan 8 08:18:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16453; Mon, 8 Jan 2001 08:18:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA16441 Mon, 8 Jan 2001 09:28:38 -0500 (EST) Message-ID: <10C8636AE359D4119118009027AE9987064C41AE@FMSMSX34> From: "Walker, Jesse" To: "'Tero Kivinen'" Cc: ipsec@lists.tislabs.com Subject: RE: Aggressive/Base Mode Signature Queries Date: Mon, 8 Jan 2001 06:30:04 -0800 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 Tero, Thanks for the response, but this answer seems to contradict The responder to the Certificate Request payload MUST send its certificate, if certificates are supported, based on the values contained in the payload. from p 34 Section "3.10 Certificate Request Payload" from RFC 2408, the ISAKMP spec. The peer asked for a cert signed by C2, not C1. I don't follow why the initiator gets to ignore the MUST in the above sentence in this particular circumstance. -- Jesse -----Original Message----- From: Tero Kivinen [mailto:kivinen@ssh.fi] Sent: Saturday, January 06, 2001 1:43 PM To: Walker, Jesse Cc: ipsec@lists.tislabs.com Subject: Aggressive/Base Mode Signature Queries Walker, Jesse writes: > (1) HDR, SA, KE, Ni, IDii(A1), CertReq(C1) ----> > (2) <---- Hdr, SA, KE, Nr, IDrr(B1), Cert(B1,C1), Sig(B1), CertReq(C2) > In the third message the protocol says you are supposed to send > (3) HDR, Sig(A2), Cert(A2,C2) ----> No. You are supposed to send (3) HDR, Sig(A1), Cert(A1,C1) ----> The signature must be using the certificate that matches the identity you already sent. If the responder does not trust the C1, then it will reject the negotiation. If it trusts C1, then the negotiation will succeed. If you selecteded wrong CA in the first place, then you need to use main mode instead of aggressive mode. Aggressive mode does not offer you an option to negotiate which CA to use. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jan 8 08:47:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19713; Mon, 8 Jan 2001 08:47:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16606 Mon, 8 Jan 2001 10:22:28 -0500 (EST) Importance: Normal To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: "David Wierbowski" Date: Mon, 8 Jan 2001 10:24:41 -0500 X-MIMETrack: Serialize by Router on D01MLC83/01/M/IBM(Build V506_11152000.dev01 |November 27, 2000) at 01/08/2001 10:24:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Walker, Jesse writes: >> (1) HDR, SA, KE, Ni, IDii(A1), CertReq(C1) ----> >> (2) <---- Hdr, SA, KE, Nr, IDrr(B1), Cert(B1,C1), Sig(B1), CertReq(C2) >> In the third message the protocol says you are supposed to send >> (3) HDR, Sig(A2), Cert(A2,C2) ----> >No. You are supposed to send >(3) HDR, Sig(A1), Cert(A1,C1) ----> I don't agree. If message 2 contained a CertReq for C2 and you don't have a cert signed by C2 that contains the ID A1, then you should send a Notify containing INVALID-CERT-AUTHORITY error. >Aggressive mode does not offer you an option to negotiate which CA to use. I'm not sure how aggressive mode differs in the ability to negotiate a CA from main mode. I think you are really referring to is ID in this case (which admittedly does impact which CertReq you might be able to honor). In main mode you have the flexibility of sending a different ID. In either case though, "negotiation" of the CA was accomplished via CertReqs. Dave Wierbowski From owner-ipsec@lists.tislabs.com Mon Jan 8 10:11:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22913; Mon, 8 Jan 2001 10:11:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16770 Mon, 8 Jan 2001 11:07:32 -0500 (EST) Message-Id: <200101081609.LAA27669@bcn.East.Sun.COM> Date: Mon, 8 Jan 2001 11:09:48 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: Aggressive/Base Mode Signature Queries To: kivinen@ssh.fi, jesse.walker@intel.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: pbYhJeih4VF2v3TQZd7C/w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Re: Jesse's question Perhaps another way of looking at it is that in Jesse's example A1 and B1 have C1 in common, and A2 and B2 share a CA C2. It's not that A and B share two CAs {C1 and C2}. The different names (A1, A2) are different identities from the protocol viewpoint. So if A doesn't have a cert from C2 for identity A1, and C2 is the only one trusted by B1, then A1 and B1 can't communicate, although if A tries to communicate via identity A2 it will work (assuming B1 trusts CA2). Given Jesse's quote from the spec: The responder to the Certificate Request payload MUST send its certificate, if certificates are supported, based on the values contained in the payload. It doesn't seem right to respond with a certificate from a different CA than was requested by the other side. So in any case, it would seem like the spec is clear that if you don't have a cert from the CA requested by the other side for the identity with which you initiated contact, authentication fails. Perhaps some heuristics might be good, like if A1 asks B1 for a cert from CA1, and B1 has one, AND B1 trusts CA1 (as well as perhaps other CAs), B1 should request a cert from CA1 in preference to any of the other CAs that B1 also trusts. Radia From owner-ipsec@lists.tislabs.com Mon Jan 8 10:19:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23082; Mon, 8 Jan 2001 10:19:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16891 Mon, 8 Jan 2001 11:38:27 -0500 (EST) Message-ID: <8894CA1F87A5D411BD24009027EE7838127FA2@md-exchange1.nai.com> From: "Mason, David" To: "'Radia Perlman - Boston Center for Networking'" , kivinen@ssh.fi, jesse.walker@intel.com Cc: ipsec@lists.tislabs.com Subject: RE: Aggressive/Base Mode Signature Queries Date: Mon, 8 Jan 2001 08:37:19 -0800 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 For certificate based exchanges, I have always believed that the certificate is the best identifier of the peer and that the phase 1 ID payload is generally superfluous dead weight. Although I could see that specifying different parts of the cert within the ID payload for different connection requirements could perhaps be used to indicate something useful. Generally, I believe that the only reason that the phase 1 ID payload has any significance for a certificate based exchange is for the case where a certificate doesn't need to be sent within IKE (cert retrieved via some other means) and for the majority of implementations which prefer the ease of policy lookups based on ID payload (a subset of the certificate) as opposed to policy lookups based on the whole certificate (or a subset of the certificate as determined by local policy and not what is supplied/dictated by the peer - here again the peer's ID payload could possibly be used to indicate which of several "matching" policies should be used). For implementations that base policy decisions on the ID payload, the scenario described will never result in the successful completion of Phase 1 (unless the implementation is broken and doesn't verify that the ID is contained within the cert). For implementations that base policy decisions on actually identity (the cert) as opposed to stated identity (ID payload), phase 1 will complete (assuming B's policy allows A2). -dave -----Original Message----- From: Radia Perlman - Boston Center for Networking [mailto:Radia.Perlman@East.Sun.COM] Sent: Monday, January 08, 2001 11:10 AM To: kivinen@ssh.fi; jesse.walker@intel.com Cc: ipsec@lists.tislabs.com Subject: RE: Aggressive/Base Mode Signature Queries Re: Jesse's question Perhaps another way of looking at it is that in Jesse's example A1 and B1 have C1 in common, and A2 and B2 share a CA C2. It's not that A and B share two CAs {C1 and C2}. The different names (A1, A2) are different identities from the protocol viewpoint. So if A doesn't have a cert from C2 for identity A1, and C2 is the only one trusted by B1, then A1 and B1 can't communicate, although if A tries to communicate via identity A2 it will work (assuming B1 trusts CA2). Given Jesse's quote from the spec: The responder to the Certificate Request payload MUST send its certificate, if certificates are supported, based on the values contained in the payload. It doesn't seem right to respond with a certificate from a different CA than was requested by the other side. So in any case, it would seem like the spec is clear that if you don't have a cert from the CA requested by the other side for the identity with which you initiated contact, authentication fails. Perhaps some heuristics might be good, like if A1 asks B1 for a cert from CA1, and B1 has one, AND B1 trusts CA1 (as well as perhaps other CAs), B1 should request a cert from CA1 in preference to any of the other CAs that B1 also trusts. Radia From owner-ipsec@lists.tislabs.com Mon Jan 8 10:58:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA27310; Mon, 8 Jan 2001 10:58:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17024 Mon, 8 Jan 2001 12:18:53 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Subject: Re: Aggressive/Base Mode Signature Queries Date: Mon, 8 Jan 2001 12:18:44 -0500 Message-Id: <001a01c07997$0ea634d0$1e72788a@andrewk3.ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Suppose you share CAs C1 and C2 with some peer B. C1 issues you a > certificate Cert(A1,C1) under the name A1, and C2 issues you > a certificate > Cert(A2,C2) under the name A2, with A1 != A2. Similar B gets > certificates > Cert(B1,C1) issued by C1 and Cert(B2,C2) issued by C2. Let us file any example with multiple root CAs into the realm of complex topology. I think it is silly to discuss rules for SA negotiation within such a network without asking why the complex topology is necessary. Scenario 1: Alice and Bob belong to corporations Ajax and BazCorp which have a limited partnership. C1 belongs to Ajax and C2 belongs to BazCorp. Alice's policy is expressed relative to C1 but she is also certified with C2. Bob's policy is expressed relative to C2 but he is also certified with C1. (This is perhaps not the best way to cross-certify two corporations, but it is a solution.) Scenario 2: Alice is a client and Bob is a server (or a sgw in front of a server). Alice uses different certificates for different applications. She uses certificate 1 to get her e-mail, but certificate 2 to connect to the bug database. For whatever reason, these two applications are not under the domain of administrative control. Assuming that you actually intend to use the identities in the certificates for authorization, then these two scenarios are very different. (And if you're not then might I ask why you have 2 CAs in the first place.) You can't be satisfied simply with agreeing on one of the two CAs, you also have to choose the correct one. In fact, in scenario 1 you don't want Alice and Bob to use the same CA. Alice should use the id from C2 and Bob should use the id from C1. In scenario 2, it's not good enough to agree on one of the two CAs; you have to choose the correct one for the task. This all goes to prove a point I've tried to make before, which is that you can't negotiate policy, you can only enforce it. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black and white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Mon Jan 8 13:11:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05461; Mon, 8 Jan 2001 13:11:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA17421 Mon, 8 Jan 2001 14:11:13 -0500 (EST) Message-Id: <200101081851.NAA13571@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: ipsec@lists.tislabs.com From: The IESG Subject: Document Action: IPsec Interactions with ECN to Informational Date: Mon, 08 Jan 2001 13:51:22 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IESG has approved the Internet-Draft 'IPsec Interactions with ECN' as a Informational. This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Jeffrey Schiller and Marcus Leech. From owner-ipsec@lists.tislabs.com Mon Jan 8 16:36:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12773; Mon, 8 Jan 2001 16:36:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18280 Mon, 8 Jan 2001 18:07:37 -0500 (EST) Date: Tue, 9 Jan 2001 01:09:54 +0200 (EET) Message-Id: <200101082309.BAA12232@taulu.hel.fi.ssh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Walker, Jesse" Cc: ipsec@lists.tislabs.com Subject: RE: Aggressive/Base Mode Signature Queries In-Reply-To: <10C8636AE359D4119118009027AE9987064C41AE@FMSMSX34> References: <10C8636AE359D4119118009027AE9987064C41AE@FMSMSX34> X-Authentication-Warning: taulu.hel.fi.ssh.com: kivinen set sender to using -f X-Mailer: VM 6.88 under Emacs 20.7.2 X-Edit-Time: 0 min X-Total-Time: 0 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Walker, Jesse writes: > Thanks for the response, but this answer seems to contradict > > The > responder to the Certificate Request payload MUST send its > certificate, if certificates are supported, based on the values > contained in the payload. > > from p 34 Section "3.10 Certificate Request Payload" from RFC 2408, the > ISAKMP spec. The peer asked for a cert signed by C2, not C1. I don't follow > why the initiator gets to ignore the MUST in the above sentence in this > particular circumstance. It did send its certificate, so it did follow the MUST. It can also send another certificate Cert(A2,C2), but I think it will be useless as the certificate is not used in the exchange, but it can do so. The issue here is that the signature generated is tied to the identity it sent, i.e it is going to bi Sig(A1), no matter what certificates are sent or not sent in the exchange. So the acceptable responses are: a) (3) HDR, Sig(A1), Cert(A1, C1), Cert(A2, C2) b) (3) HDR, Sig(A1), Cert(A2, C2) c) (3) HDR, Sig(A1), Cert(A1, C1) etc, i.e anything that contains Sig(A1), and some certificates. Sending Cert(A2,C2) does not gain anything for this exchange, but it might be usefull for the later exchanges, so the preferred reply is propably the case a. I agree that the case c is might be agaist the rfc, as we sent certificate only based some values in the certificate request, not all. The reason I used that is that it is the one that works with most of the implementations. Anyways, the initiator CANNOT reply with (3) HDR, Sig(A2) ... because the Signature A2, does not match the identity sent in the first message. Draft-ietf-ipsec-pki-req-05.txt says in section 6.7: ---------------------------------------------------------------------- 6.7 Matching ID payloads with certificate subjects An IKE implementation that conforms to this profile MUST NOT use an end entity certificate received from an IKE peer for purposes of completing the IKE authentication process unless there is a match in both content and format between the ID payload (IDii or IDir) offered by the peer in the IKE negotiation and at least one of the name forms carried in either the subject or subjectAltName fields in the certificate received. ---------------------------------------------------------------------- There are two basic methods to implement this: 1) Search the certificate based on the ID payload 2) Verify the ID and certificate after successfull signature check. If we use the ID payload to search the certificate, then it does not really matter if we used case a, b, or c. If the certificate can be found we select the correct certificate and use that the verify the signature. In case b it might be that we don't have the Cert(A1, C1), and it might be possible that we don't find it from the ldap or anywhere else, thus the negotiation might fail. For cases a and c the negotiation will succeed. The problem with this method is that if there multiple certificates matching the ID payload then we don't know which of them to use, and we have to do some extra checks for those. This include using all of the certificates to verify the signature and if any of them succeeds then the signature check succeed. Of course there can be all kind of optimizations there, like first trying those certificates the other end actually sent to you, and hope that the other end sent you the one he actually used. This kind of situation, where you have multiple certificates with same ID can happen for example when we have two certificates for the same host having different validity periods. The second case doesn't really specify how to find the certificate in first place, but normally those implementations will assume it is inside the IKE negotiation, and take the first or all certificates inside the IKE negotiation. If they just take first certificate, then case a will fail or succeed depending on the order of certificates. Case b is always going to fail, and case c is always going to succeed. -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jan 8 16:37:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12799; Mon, 8 Jan 2001 16:37:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18291 Mon, 8 Jan 2001 18:11:41 -0500 (EST) X-Authentication-Warning: taulu.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14938.18873.555273.371611@taulu.hel.fi.ssh.com> Date: Tue, 9 Jan 2001 01:14:01 +0200 From: Tero Kivinen To: "Mason, David" Cc: "'Radia Perlman - Boston Center for Networking'" , jesse.walker@intel.com, ipsec@lists.tislabs.com Subject: RE: Aggressive/Base Mode Signature Queries In-Reply-To: <8894CA1F87A5D411BD24009027EE7838127FA2@md-exchange1.nai.com> References: <8894CA1F87A5D411BD24009027EE7838127FA2@md-exchange1.nai.com> X-Mailer: VM 6.88 under Emacs 20.7.2 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mason, David writes: > For certificate based exchanges, I have always believed that the certificate > is the best identifier of the peer and that the phase 1 ID payload is > generally superfluous dead weight. Although I could see that specifying > different parts of the cert within the ID payload for different connection > requirements could perhaps be used to indicate something useful. How do you find that certificate for the peer. The other end might send multiple certificates some of them might be usefull, some of the might not be usefull. Some of them might be certificates for the intermediate CAs etc. It is very easy to assume that the other end only sends exactly one certificate that is their certificate, and then you can remove the ID payload. If you follow the RFCs then the other end can send multiple certificates to you and then you do need the ID payload to verify which certificate to use. Another option is that you take all certificates sent by the other end and try to verify the signature with each of them, but that is not an very efficient option... -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jan 8 18:23:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA14436; Mon, 8 Jan 2001 18:23:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA18545 Mon, 8 Jan 2001 19:45:09 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200101081609.LAA27669@bcn.East.Sun.COM> References: <200101081609.LAA27669@bcn.East.Sun.COM> Date: Mon, 8 Jan 2001 19:42:55 -0500 To: Radia Perlman - Boston Center for Networking From: Stephen Kent Subject: RE: Aggressive/Base Mode Signature Queries Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia, In thinking about your suggestions for heuristics at the end of the message, I just wanted to make an observation: In many (most?) contexts where IPsec is being used, I think trust models (jn the more general sense) will not apply. Companies begin by issuing certs to their employees and to IPsec devices at the company's remote sites to enable remote access and to create intranets. Then, a company may cross certify other companies to enable an extranet. The company should use the name constraints extension in such cross certs, to ensure that the companies who are cross certified cannot issue certs outside their own names spaces (and have them accepted by the cross certifying company). If one follows that sort of model, trust does not enter into the PKI model in the sense that it might if individuals were engaging in this activity among themselves. Steve From owner-ipsec@lists.tislabs.com Tue Jan 9 05:50:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02926; Tue, 9 Jan 2001 05:50:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA20624 Tue, 9 Jan 2001 06:46:33 -0500 (EST) Message-Id: <200101091148.GAA08835@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: smug@cs.umass.edu, msec@securemulticast.org, ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-irtf-smug-gdoi-01.txt Date: Tue, 09 Jan 2001 06:48:48 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Group Domain of Interpretation for ISAKMP Author(s) : M. Baugher, T. Hardjono, B. Weis Filename : draft-irtf-smug-gdoi-01.txt Pages : 42 Date : 08-Jan-01 This document presents an ISAKMP Domain of Interpretation (DOI) for secure group communications. The 'GDOI,' or 'Group ISAKMP,' borrows definitions from GSAKMP [HH], incorporates the Phase 1 SA of the Internet DOI [RFC2407, RFC2409], and proposes new payloads and exchanges according to the ISAKMP standard [RFC2408, p.14]. Group ISAKMP manages group security associations, which are used by security protocols running at the IP [RFC2406] or application layers [AMESP]. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members. Comments on this document should be addressed to smug@cs.umass.edu. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-smug-gdoi-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-irtf-smug-gdoi-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-irtf-smug-gdoi-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010108124829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-irtf-smug-gdoi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-irtf-smug-gdoi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010108124829.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jan 10 16:57:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19082; Wed, 10 Jan 2001 16:57:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29257 Wed, 10 Jan 2001 17:45:23 -0500 (EST) From: Ricky Charlet To: ".ipsec" Message-ID: <3A5CD97A.3565D9AF@redcreek.com> Date: Wed, 10 Jan 2001 14:51:54 -0700 Organization: Redcreek Communications X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: status of Monitor Mibs? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, ISAKMP-DOI-IND-MON-MIB IKE-MON-MIB IPSEC-ISAKMP-IKE-DOI-TC IPSEC-SA-MON-MIB Did these go to last call? Tim, are you still owning and advancing them? Thanks -- Ricky Charlet : Redcreek Communications : usa (510) 795-6903 From owner-ipsec@lists.tislabs.com Sun Jan 14 22:54:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA08976; Sun, 14 Jan 2001 22:54:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA14084 Mon, 15 Jan 2001 00:07:36 -0500 (EST) To: ipsec@lists.tislabs.com Date: Sun, 14 Jan 2001 21:07:22 -0800 Subject: Inbound processing of ESP packet Message-ID: <20010114.210912.-318249.4.shoaib21@juno.com> X-Mailer: Juno 4.0.5 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: Pervaiz Rizvi Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am confused about how the inbound processing of ESP packet is done. [ [SPI] [Seq#] [IV] [encrypted payload] [auth data] ] How does the IPsec stack know the size of the encrypted payload? Or how does it avoid having to know it? Also, since the Auth trailer follows the encrypted payload and since the inbound processing routine does not know the length of the encrypted payload, how does the stack do authenticate the packet prior to encryption? Pervaiz From owner-ipsec@lists.tislabs.com Sun Jan 14 22:54:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA08993; Sun, 14 Jan 2001 22:54:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA14085 Mon, 15 Jan 2001 00:07:36 -0500 (EST) To: ipsec@lists.tislabs.com Date: Sun, 14 Jan 2001 21:09:12 -0800 Subject: Protection of port 500 Message-ID: <20010114.210912.-318249.5.shoaib21@juno.com> X-Mailer: Juno 4.0.5 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: Pervaiz Rizvi Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since IPsec uses UDP500 for key exchange, how does it know to ignore configurations that seek to protect udp/500 with IPsec? If this were allowed, presumably the IPsec stack would go into an unterminating recursion. Please help. Pervaiz. From owner-ipsec@lists.tislabs.com Mon Jan 15 01:55:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA08794; Mon, 15 Jan 2001 01:55:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA14787 Mon, 15 Jan 2001 03:35:20 -0500 (EST) Date: Mon, 15 Jan 2001 00:37:21 -0800 From: Jason R Thorpe To: Pervaiz Rizvi Cc: ipsec@lists.tislabs.com Subject: Re: Protection of port 500 Message-ID: <20010115003721.P475@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , Pervaiz Rizvi , ipsec@lists.tislabs.com References: <20010114.210912.-318249.5.shoaib21@juno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010114.210912.-318249.5.shoaib21@juno.com>; from shoaib21@juno.com on Sun, Jan 14, 2001 at 09:09:12PM -0800 Organization: Zembu Labs, Inc. Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, Jan 14, 2001 at 09:09:12PM -0800, Pervaiz Rizvi wrote: > Since IPsec uses UDP500 for key exchange, > how does it know to ignore configurations > that seek to protect udp/500 with IPsec? > If this were allowed, presumably the IPsec > stack would go into an unterminating recursion. Presumably the IKE daemon would change the policy for the communication endpoints it is using. -- -- Jason R. Thorpe From owner-ipsec@lists.tislabs.com Mon Jan 15 02:16:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA09951; Mon, 15 Jan 2001 02:16:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA14940 Mon, 15 Jan 2001 04:01:10 -0500 (EST) Date: Mon, 15 Jan 2001 10:03:41 +0100 From: Stefan Schlott To: ipsec@lists.tislabs.com Cc: Pervaiz Rizvi Subject: Re: Inbound processing of ESP packet Message-ID: <20010115100341.A10256@orca.informatik.uni-ulm.de> References: <20010114.210912.-318249.4.shoaib21@juno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010114.210912.-318249.4.shoaib21@juno.com>; from shoaib21@juno.com on Sun, Jan 14, 2001 at 09:07:22PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, Jan 14, 2001 at 09:07:22PM -0800, Pervaiz Rizvi wrote: > I am confused about how the inbound processing of ESP > packet is done. > > [ [SPI] [Seq#] [IV] [encrypted payload] [auth data] ] > > How does the IPsec stack know the size of the encrypted payload? > Or how does it avoid having to know it? The encrypted payload contains padding data and the type of data contained within: (...encrypted data...) (padding data) (pad length) (type) Padding is neccessary both for block mode algorithms and 32 bit alignment. So your data length is: Enc.payl.length - pad length - 2 (1 byte pad length info, 1 byte type) > Also, since the Auth trailer follows the encrypted payload > and since the inbound processing routine does not > know the length of the encrypted payload, how does the > stack do authenticate the packet prior to encryption? The auth trailer is calculated _after_ encrypting the payload. Stefan. -- *--- please cut here... -------------------------------------- thanks! ---* |-> E-Mail: stefan.schlott@informatik.uni-ulm.de PGP-Key: 0x2F36F4FE <-| *-------------------------------------------------------------------------* From owner-ipsec@lists.tislabs.com Mon Jan 15 04:02:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA18716; Mon, 15 Jan 2001 04:02:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA15177 Mon, 15 Jan 2001 05:21:02 -0500 (EST) To: Pervaiz Rizvi cc: ipsec@lists.tislabs.com In-reply-to: shoaib21's message of Sun, 14 Jan 2001 21:07:22 PST. <20010114.210912.-318249.4.shoaib21@juno.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Inbound processing of ESP packet From: itojun@iijlab.net Date: Mon, 15 Jan 2001 19:23:25 +0900 Message-ID: <21699.979554205@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >I am confused about how the inbound processing of ESP >packet is done. > [ [SPI] [Seq#] [IV] [encrypted payload] [auth data] ] >How does the IPsec stack know the size of the encrypted payload? >Or how does it avoid having to know it? assume we do not have authentication data. we can know the (unencrypted) payload length by pad length. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Auth. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |erage +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | Payload Data* (variable) | | ^ ~ ~ | | | | |Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | | Padding (0-255 bytes) | |erage* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ >Also, since the Auth trailer follows the encrypted payload >and since the inbound processing routine does not >know the length of the encrypted payload, how does the >stack do authenticate the packet prior to encryption? when both ends agree upon a configuration, they agrees on authentication trailer length. so both ends know authentication trailer length. then you can subtract pad length to know the unencrypted payload length. itojun From owner-ipsec@lists.tislabs.com Mon Jan 15 04:19:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA19094; Mon, 15 Jan 2001 04:19:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA15335 Mon, 15 Jan 2001 05:53:06 -0500 (EST) From: "Fabio Zamparelli" To: Subject: Links to papers about how to calculate Keyed and Hashed AH and ESP payload lenght Date: Mon, 15 Jan 2001 11:57:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk HI, anyone can point me to papers about how to precalculate, starting from the transport payload and header lenght, the AH and ESP header lenght knowing the authentication and encryption choices? For Example: Layer4lenght=12Byte Autenthication and encryption choices= AH [MD5 HMAC] AND ESP[DES NO HMAC] ESPlenght=function1(layer4lenght, DES NO HMAC) AHlenght=function2((layer4lenght+ESPlenght),MD5 HMAC) Forgive my poor english and please, Fabio Zamparelli Universita' Federico II di Napoli Italy From owner-ipsec@lists.tislabs.com Mon Jan 15 09:17:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10842; Mon, 15 Jan 2001 09:17:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA16308 Mon, 15 Jan 2001 10:11:50 -0500 (EST) Message-Id: <200101151513.KAA19712@quark.research.telcordia.com> To: ipsec@lists.tislabs.com Reply-To: gah@research.telcordia.com (Gary A. Hayward) Subject: IPsec, IKE, and Key Management Scaling? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19709.979571628.1@research.telcordia.com> Date: Mon, 15 Jan 2001 10:13:48 -0500 From: Gary A Hayward Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How well does IPsec and the related key management technology scale into the mass market? At Telcordia we're trying to gather some technical data in that area, and would be delighted to hear from/share with anyone who has experience-based measurements and implementation projections along the following lines: What is the memory footprint for each 10,000 simultaneous sessions in a server running IPsec to protect VoIP services? Assume some sort of X.509v3 certificates are used throughout. If those N*10,000 sessions are lost and simultaneously recovered, say in a regional power outage and restoration, what is the elapsed time (or number of server CPU cycles) taken after power restoration and until full N*10,000 session restoration has been achieved? Assume that the centralized server stays up, but the distributed endpoints all need restarting and all ask for session re-initialization simultaneously. A big voice end office can handle about 50,000 telephone lines, so N=5 would be a wonderful datapoint for comparison. How much of the memory and CPU burden above is due to IPsec proper, and how much to the key management and policy management processing on the centralized server? Are their obvious optimizations that are available to the industry but not quite yet incorporated into current IPsec products and stacks? Some VPN and encrypted networking systems suffer a form of deadly-embrace in wide area recovery - protection timers timeout while awaiting successful recovery of the protected sessions, maintenance code then interprets this as a localized failure, and the session creation is abandoned and the whole process is endlessly restarted. Are there potential problems like this with large scale IPsec systems, or more likely with the applications code expecting to run with IPsec systems? How should deadlock/livelock protection timeouts be set as a function of IPsec deployment scale and options? What data exist on life-cycle labor costs for IPsec and key management infrastructure? As a rule of thumb, how many full time equivalent staff are needed to administer key management (including CRL processing) and policy/configuration management per 10,000 secured hosts? At the client side, how much capital and minutes-per-year of user time is required to prevent the client-side private key from being used inappropriately, say by anyone/anything other than the intended secured user? Any discussion of these points is welcome, public or private. Please note that none of the material above really depends on the actual encryption/authentication performance - it is all based on the processing needed to create and maintain session state. If someone has a reply of the kind "It depends on what you assume as ...", please make your own assumption based on best commercial practice and feel free to reply to the modified question. If I've missed some seminal analysis in the literature that covers this material already, my apologies to all. A lot of discussion seems to assume particular answers to the questions above, but I've never seen an authoritative reference. I'll be delighted to summarize all responses and make them available on request. Gary A. Hayward Telcordia Technologies From owner-ipsec@lists.tislabs.com Mon Jan 15 09:50:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12968; Mon, 15 Jan 2001 09:50:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16535 Mon, 15 Jan 2001 11:18:06 -0500 (EST) Date: Mon, 15 Jan 2001 11:20:06 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: Inbound processing of ESP packet In-Reply-To: <20010114.210912.-318249.4.shoaib21@juno.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sun, 14 Jan 2001, Pervaiz Rizvi wrote: > [ [SPI] [Seq#] [IV] [encrypted payload] [auth data] ] > How does the IPsec stack know the size of the encrypted payload? Normally, packet length is discovered based on link-level framing, either supplemented or confirmed by the byte count in the IP header. The IPsec stack is *told* how many bytes it's getting, total. The SPI identifies the SA, and the SA tells the IPsec stack what authentication algorithm is used, which determines how long the "auth data" section is. The length of the "encrypted payload" section is determined by subtraction. The contents of that section, after decryption, are self-describing. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jan 15 11:25:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19024; Mon, 15 Jan 2001 11:25:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16994 Mon, 15 Jan 2001 13:01:12 -0500 (EST) Date: Mon, 15 Jan 2001 13:03:10 -0500 (EST) From: Henry Spencer To: "Steven M. Bellovin" cc: IP Security List Subject: Re: Inbound processing of ESP packet In-Reply-To: <20010115175120.46BA035DC2@smb.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 15 Jan 2001, Steven M. Bellovin wrote: > >Normally, packet length is discovered based on link-level framing, either > >supplemented or confirmed by the byte count in the IP header... > > Nope; the IP header value is the only authoritative one. There may be > link-level padding, such as the minimum frame size on Ethernet. As I said: "either supplemented..." (that is, the IP header value is needed to pin down where the packet ends and the padding starts, when the frame as received is oversize). > The link-level length is checked to ensure that enough data was > received to accomodate the IP header's value. "...or confirmed". When two numbers have to agree, speaking of one as "authoritative" is questionable usage. And any real implementation initially allocates space based on the frame size -- the size of the packet as received is however many bytes were received, with the IP header consulted only to remove padding and verify consistency. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jan 15 11:28:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19418; Mon, 15 Jan 2001 11:28:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16939 Mon, 15 Jan 2001 12:49:02 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Henry Spencer Cc: IP Security List Subject: Re: Inbound processing of ESP packet Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Jan 2001 12:51:14 -0500 Message-Id: <20010115175120.46BA035DC2@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Henry Spe ncer writes: >On Sun, 14 Jan 2001, Pervaiz Rizvi wrote: >> [ [SPI] [Seq#] [IV] [encrypted payload] [auth data] ] >> How does the IPsec stack know the size of the encrypted payload? > >Normally, packet length is discovered based on link-level framing, either >supplemented or confirmed by the byte count in the IP header. The IPsec >stack is *told* how many bytes it's getting, total. The SPI identifies >the SA, and the SA tells the IPsec stack what authentication algorithm is >used, which determines how long the "auth data" section is. The length of >the "encrypted payload" section is determined by subtraction. The >contents of that section, after decryption, are self-describing. Nope; the IP header value is the only authoritative one. There may be link-level padding, such as the minimum frame size on Ethernet. The link-level length is checked to ensure that enough data was received to accomodate the IP header's value. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Mon Jan 15 14:12:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29309; Mon, 15 Jan 2001 14:12:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17471 Mon, 15 Jan 2001 15:44:44 -0500 (EST) To: thorpej@zembu.com Cc: shoaib21@juno.com, ipsec@lists.tislabs.com Date: Mon, 15 Jan 2001 12:44:06 -0800 Subject: Re: Protection of port 500 Message-ID: <20010115.124614.-530629.1.shoaib21@juno.com> X-Mailer: Juno 4.0.5 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-5,7-20 X-Juno-Att: 0 X-Juno-RefParts: 0 From: Pervaiz Rizvi Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Do you mean IPsec implementations silently ignore the configured policy to protect udp/500 with IPsec? Pervaiz On Mon, 15 Jan 2001 00:37:21 -0800 Jason R Thorpe writes: > On Sun, Jan 14, 2001 at 09:09:12PM -0800, Pervaiz Rizvi wrote: > > > Since IPsec uses UDP500 for key exchange, > > how does it know to ignore configurations > > that seek to protect udp/500 with IPsec? > > If this were allowed, presumably the IPsec > > stack would go into an unterminating recursion. > > Presumably the IKE daemon would change the policy for the > communication endpoints it is using. > > -- > -- Jason R. Thorpe From owner-ipsec@lists.tislabs.com Mon Jan 15 14:13:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29325; Mon, 15 Jan 2001 14:13:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA17478 Mon, 15 Jan 2001 15:45:05 -0500 (EST) To: itojun@iijlab.net Cc: shoaib21@juno.com, ipsec@lists.tislabs.com Date: Mon, 15 Jan 2001 12:42:00 -0800 Subject: Re: Inbound processing of ESP packet Message-ID: <20010115.124614.-530629.0.shoaib21@juno.com> X-Mailer: Juno 4.0.5 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Juno-Att: 0 X-Juno-RefParts: 0 From: Pervaiz Rizvi Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If there is auth trailer: evidently the auth must be performed prior to decryption: 1. SPI (processed) 2. Seq# (processed) 3. Encrypted payload <---- processing 4. Auth trailer The inbound processing finished processing Seq#. I am assuming that it must finish authenticating the packet before it decrypts it. Now it must get to the start of the ESP trailer. Since it does not know the length of the encrypted payload, how does it find the start of the ESP trailer in the packet? Pervaiz On Mon, 15 Jan 2001 19:23:25 +0900 itojun@iijlab.net writes: > > >I am confused about how the inbound processing of ESP > >packet is done. > > [ [SPI] [Seq#] [IV] [encrypted payload] [auth data] ] > >How does the IPsec stack know the size of the encrypted payload? > >Or how does it avoid having to know it? > > assume we do not have authentication data. we can know the > (unencrypted) payload length by pad length. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ---- > | Security Parameters Index (SPI) | > ^Auth. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Cov- > | Sequence Number | > |erage > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > ---- > | Payload Data* (variable) | | > ^ > ~ ~ | > | > | | > |Conf. > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Cov- > | | Padding (0-255 bytes) | > |erage* > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | > | | Pad Length | Next Header | v > v > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ------ > > >Also, since the Auth trailer follows the encrypted payload > >and since the inbound processing routine does not > >know the length of the encrypted payload, how does the > >stack do authenticate the packet prior to encryption? > > when both ends agree upon a configuration, they agrees on > authentication trailer length. so both ends know > authentication > trailer length. then you can subtract pad length to know > the > unencrypted payload length. > > itojun From owner-ipsec@lists.tislabs.com Mon Jan 15 15:07:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02357; Mon, 15 Jan 2001 15:07:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA17681 Mon, 15 Jan 2001 16:44:25 -0500 (EST) Date: Mon, 15 Jan 2001 13:46:28 -0800 From: Jason R Thorpe To: Pervaiz Rizvi Cc: ipsec@lists.tislabs.com Subject: Re: Protection of port 500 Message-ID: <20010115134628.C475@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , Pervaiz Rizvi , ipsec@lists.tislabs.com References: <20010115.124614.-530629.1.shoaib21@juno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010115.124614.-530629.1.shoaib21@juno.com>; from shoaib21@juno.com on Mon, Jan 15, 2001 at 12:44:06PM -0800 Organization: Zembu Labs, Inc. Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, Jan 15, 2001 at 12:44:06PM -0800, Pervaiz Rizvi wrote: > Do you mean IPsec implementations silently > ignore the configured policy to protect > udp/500 with IPsec? No, I meant precisely what I said. As you seem to be already aware, you can't exactly use ESP to protect IKE transactions because IKE is used to exchange keys for ESP. Therefore, the IKE daemon needs to override the system-wide policy for the sockets it creates and use some other mechanism to protect its transactions. -- -- Jason R. Thorpe From owner-ipsec@lists.tislabs.com Mon Jan 15 15:33:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03143; Mon, 15 Jan 2001 15:33:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17857 Mon, 15 Jan 2001 17:03:39 -0500 (EST) Date: Mon, 15 Jan 2001 17:05:39 -0500 (EST) From: Henry Spencer To: Pervaiz Rizvi cc: ipsec@lists.tislabs.com Subject: Re: Protection of port 500 In-Reply-To: <20010115.124614.-530629.1.shoaib21@juno.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 15 Jan 2001, Pervaiz Rizvi wrote: > Do you mean IPsec implementations silently > ignore the configured policy to protect > udp/500 with IPsec? A configured policy which does not include an exception for UDP/500 (perhaps subject to other constraints) is erroneous and should be reported as such. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jan 15 15:36:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03210; Mon, 15 Jan 2001 15:36:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17890 Mon, 15 Jan 2001 17:09:21 -0500 (EST) Date: Mon, 15 Jan 2001 17:11:20 -0500 (EST) From: Henry Spencer To: Pervaiz Rizvi cc: ipsec@lists.tislabs.com Subject: Re: Inbound processing of ESP packet In-Reply-To: <20010115.124614.-530629.0.shoaib21@juno.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 15 Jan 2001, Pervaiz Rizvi wrote: > Now it must get to the start of the ESP trailer. Since it does not know > the length of the encrypted payload, how does it find the start > of the ESP trailer in the packet? It doesn't have to find the *start* of the trailer, only the *end*, because the Pad Length and Next Header fields are at the end, not at the start. It authenticates the whole packet, then decrypts the encrypted payload. The second-last byte of the decrypted result is the pad length. If that byte's value is N, the last N+2 bytes of the decrypted result are the trailer. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jan 15 16:06:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03711; Mon, 15 Jan 2001 16:06:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18159 Mon, 15 Jan 2001 17:52:35 -0500 (EST) From: Dan McDonald Message-Id: <200101152255.f0FMt5v08187@kebe.Eng.Sun.COM> Subject: Re: Protection of port 500 In-Reply-To: from Henry Spencer at "Jan 15, 2001 05:05:39 pm" To: ipsec@lists.tislabs.com Date: Mon, 15 Jan 2001 14:55:05 -0800 (PST) CC: Pervaiz Rizvi Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > On Mon, 15 Jan 2001, Pervaiz Rizvi wrote: > > Do you mean IPsec implementations silently > > ignore the configured policy to protect > > udp/500 with IPsec? > > A configured policy which does not include an exception for UDP/500 > (perhaps subject to other constraints) is erroneous and should be reported > as such. Another approach is to allow trusted applications (e.g. an IKE daemon) to bypass the appropriate port(s) because the application is trusted to protect itself. In Solaris, for example, utter "man ipsec" and look for "Per-Socket Policy". Dan From owner-ipsec@lists.tislabs.com Mon Jan 15 16:21:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03977; Mon, 15 Jan 2001 16:21:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA18085 Mon, 15 Jan 2001 17:47:13 -0500 (EST) Message-Id: <200101152242.OAA15815@potassium.network-alchemy.com> To: Henry Spencer cc: Pervaiz Rizvi , ipsec@lists.tislabs.com Subject: Re: Protection of port 500 In-reply-to: Your message of "Mon, 15 Jan 2001 17:05:39 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15812.979598554.1@network-alchemy.com> Date: Mon, 15 Jan 2001 14:42:34 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just to clarify, the exception should be for UDP/500 and all the interfaces out of which you'll be speaking IKE. It is conceivable that people might want to set up a "tunnel in a tunnel" and that would entail a policy protecting UDP/500 for another gateway. Dan. On Mon, 15 Jan 2001 17:05:39 EST you wrote > On Mon, 15 Jan 2001, Pervaiz Rizvi wrote: > > Do you mean IPsec implementations silently > > ignore the configured policy to protect > > udp/500 with IPsec? > > A configured policy which does not include an exception for UDP/500 > (perhaps subject to other constraints) is erroneous and should be reported > as such. > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Mon Jan 15 16:49:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA04368; Mon, 15 Jan 2001 16:49:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA18254 Mon, 15 Jan 2001 18:25:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Manual SA SPI range Date: Mon, 15 Jan 2001 14:27:44 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C07626574038DD0BC@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: Inbound processing of ESP packet Thread-Index: AcB/QcKclRoOrD3YSTyklUEdsIu6WQAAFtUA From: "Brian Swander" To: X-OriginalArrivalTime: 15 Jan 2001 22:27:47.0250 (UTC) FILETIME=[63095920:01C07F42] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA18251 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Does anyone know if there is a hard specification in any of the RFCs that nails down ranges for manual SA SPIs? I remember hearing that below 256 was set aside for manual SAs, but I cannot find text to that effect anywhere. thanks bs From owner-ipsec@lists.tislabs.com Mon Jan 15 20:36:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA09287; Mon, 15 Jan 2001 20:36:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA18923 Mon, 15 Jan 2001 21:57:07 -0500 (EST) Message-Id: <200101160251.SAA26574@cisco.com> X-Sender: sfluhrer@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 15 Jan 2001 18:46:19 -0800 To: "Brian Swander" , From: Scott Fluhrer Subject: Re: Manual SA SPI range In-Reply-To: <5B90AD65A9E8934987DB0C8C07626574038DD0BC@DF-BOWWOW.platinu m.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 02:27 PM 1/15/01 , Brian Swander wrote: >Does anyone know if there is a hard specification in any of the RFCs >that nails down ranges for manual SA SPIs? I remember hearing that >below 256 was set aside for manual SAs, but I cannot find text to that >effect anywhere. No, there is no specific range set aside for manual SPIs. Of course, since with IKE, a system selects the SPIs for SAs that it decrypts, a system can set aside any range it wished for manual SPIs, and have IKE always select SPIs outside that range for the SPIs it creates. SPIs below 256 are not set aside for manual SAs. 0 is reserved for an implementation's internal use (must not be sent on the wire), and 1-255 are reserved for IANA's future use. See RFC2402 (section 2.4) and RFC2406 (section 2.1) for the official pronouncements. -- scott From owner-ipsec@lists.tislabs.com Mon Jan 15 21:01:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09645; Mon, 15 Jan 2001 21:01:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19141 Mon, 15 Jan 2001 22:35:32 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <20010114.210912.-318249.4.shoaib21@juno.com> References: <20010114.210912.-318249.4.shoaib21@juno.com> Date: Mon, 15 Jan 2001 17:50:25 -0500 To: Pervaiz Rizvi From: Stephen Kent Subject: Re: Inbound processing of ESP packet Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:07 PM -0800 1/14/01, Pervaiz Rizvi wrote: >I am confused about how the inbound processing of ESP >packet is done. > > [ [SPI] [Seq#] [IV] [encrypted payload] [auth data] ] > >How does the IPsec stack know the size of the encrypted payload? >Or how does it avoid having to know it? > >Also, since the Auth trailer follows the encrypted payload >and since the inbound processing routine does not >know the length of the encrypted payload, how does the >stack do authenticate the packet prior to encryption? Your diagram is incomplete. You have omitted the IP header that comes before the SPI, in both transport and tunnel modes. Also you show an IV with is algorithm and mode dependent, i.e., not always present and of a length defined by SA parameters. The end of the IPsec packet is specified by the outer IP header, so we know where the auth trailer is. Also, since the SPI, destination addr from that header and the IPsec protocol{here assumed to be ESP) uniquely identify an SA, the recipient knows whether the auth trailer is present, and its length, since the algotihm used to compute the auth trailer is constant for the life of the SA. With this knowledge, the recipient can check the packet integrity prior to decrypting the encrypted payload. At the end of that payload, when decrypted, will be the real next header field and a padding length field, in a completely determined location. So, what's the problem? Steve From owner-ipsec@lists.tislabs.com Mon Jan 15 21:02:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09670; Mon, 15 Jan 2001 21:02:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19142 Mon, 15 Jan 2001 22:35:32 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <20010115003721.P475@dr-evil.shagadelic.org> References: <20010114.210912.-318249.5.shoaib21@juno.com> <20010115003721.P475@dr-evil.shagadelic.org> Date: Mon, 15 Jan 2001 17:52:41 -0500 To: thorpej@zembu.com From: Stephen Kent Subject: Re: Protection of port 500 Cc: Pervaiz Rizvi , ipsec@lists.tislabs.com Content-Type: multipart/alternative; boundary="============_-1232506174==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1232506174==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 12:37 AM -0800 1/15/01, Jason R Thorpe wrote: >On Sun, Jan 14, 2001 at 09:09:12PM -0800, Pervaiz Rizvi wrote: > > > Since IPsec uses UDP500 for key exchange, > > how does it know to ignore configurations > > that seek to protect udp/500 with IPsec? > > If this were allowed, presumably the IPsec > > stack would go into an unterminating recursion. > >Presumably the IKE daemon would change the policy for the >communication endpoints it is using. > An IPsec implementation may originate and terminate its own management traffic (.e.g., IKE, SNMP, ICMP etc.) irrespective of the SPD and SAD entries use to manage subscriber. Steve --============_-1232506174==_ma============ Content-Type: text/enriched; charset="us-ascii" At 12:37 AM -0800 1/15/01, Jason R Thorpe wrote: On Sun, Jan 14, 2001 at 09:09:12PM -0800, Pervaiz Rizvi wrote: > Since IPsec uses UDP500 for key exchange, > how does it know to ignore configurations > that seek to protect udp/500 with IPsec? > If this were allowed, presumably the IPsec > stack would go into an unterminating recursion. Presumably the IKE daemon would change the policy for the communication endpoints it is using. An IPsec implementation may originate and terminate its own management traffic (.e.g., IKE, SNMP, ICMP etc.) irrespective of the SPD and SAD entries use to manage subscriber. Steve --============_-1232506174==_ma============-- From owner-ipsec@lists.tislabs.com Mon Jan 15 21:04:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09698; Mon, 15 Jan 2001 21:04:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19150 Mon, 15 Jan 2001 22:36:11 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 15 Jan 2001 21:43:01 -0500 To: Henry Spencer From: Stephen Kent Subject: Re: Inbound processing of ESP packet Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >On Mon, 15 Jan 2001, Steven M. Bellovin wrote: > > >Normally, packet length is discovered based on link-level framing, either > > >supplemented or confirmed by the byte count in the IP header... > > > > Nope; the IP header value is the only authoritative one. There may be > > link-level padding, such as the minimum frame size on Ethernet. > >As I said: "either supplemented..." (that is, the IP header value is >needed to pin down where the packet ends and the padding starts, when >the frame as received is oversize). > > > The link-level length is checked to ensure that enough data was > > received to accomodate the IP header's value. > >"...or confirmed". > >When two numbers have to agree, speaking of one as "authoritative" is >questionable usage. And any real implementation initially allocates space >based on the frame size -- the size of the packet as received is however >many bytes were received, with the IP header consulted only to remove >padding and verify consistency. Steve Bellovin is right, Henry. A LAN interface may include padding after the end of the IP packet when the packet is delivered from layer 2 to layer 3 (or from lower layer 3 to IP). The IP total length field is what defines the end of the IP packet, not a byte count from a lower layer protocol. Steve From owner-ipsec@lists.tislabs.com Mon Jan 15 21:12:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09778; Mon, 15 Jan 2001 21:12:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19222 Mon, 15 Jan 2001 22:47:59 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 15 Jan 2001 22:45:30 -0500 To: Henry Spencer From: Stephen Kent Subject: Re: Protection of port 500 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry, >On Mon, 15 Jan 2001, Pervaiz Rizvi wrote: > > Do you mean IPsec implementations silently > > ignore the configured policy to protect > > udp/500 with IPsec? > >A configured policy which does not include an exception for UDP/500 >(perhaps subject to other constraints) is erroneous and should be reported >as such. A UDP/500 SPD entry applies to subscriber traffic, and thus determines whether a subscriber behind the IPsec implementation (especially appropriate in an SG). However, an IPsec implementation can send and receive traffic for ITSELF independent of SPD/SAD entries. Steve From owner-ipsec@lists.tislabs.com Mon Jan 15 21:15:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA09833; Mon, 15 Jan 2001 21:15:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA19253 Mon, 15 Jan 2001 22:52:36 -0500 (EST) X-Authentication-Warning: samara.cisco.com: mfranz owned process doing -bs Date: Mon, 15 Jan 2001 22:15:19 +0000 (/etc/localtime) From: Matthew Franz To: Dan McDonald cc: ipsec@lists.tislabs.com, Pervaiz Rizvi Subject: Re: Protection of port 500 In-Reply-To: <200101152255.f0FMt5v08187@kebe.Eng.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > On Mon, 15 Jan 2001, Pervaiz Rizvi wrote: > > > Do you mean IPsec implementations silently > > > ignore the configured policy to protect > > > udp/500 with IPsec? > > > > A configured policy which does not include an exception for UDP/500 > > (perhaps subject to other constraints) is erroneous and should be reported > > as such. > > Another approach is to allow trusted applications (e.g. an IKE daemon) to > bypass the appropriate port(s) because the application is trusted to protect > itself. > > In Solaris, for example, utter "man ipsec" and look for "Per-Socket Policy". > Isn't this approach just looking for trouble? Can applications be trusted to protect themselves from, let's say, from DoS attacks? I'd want at least the option of some lower layer policy enforcement (ACLs, filters, etc.) in additon to whatever the app layer provides. -mdf From owner-ipsec@lists.tislabs.com Mon Jan 15 21:48:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA10260; Mon, 15 Jan 2001 21:48:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA19354 Mon, 15 Jan 2001 23:32:03 -0500 (EST) Date: Mon, 15 Jan 2001 23:32:44 -0500 (EST) From: Henry Spencer To: Brian Swander cc: ipsec@lists.tislabs.com Subject: Re: Manual SA SPI range In-Reply-To: <5B90AD65A9E8934987DB0C8C07626574038DD0BC@DF-BOWWOW.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 On Mon, 15 Jan 2001, Brian Swander wrote: > Does anyone know if there is a hard specification in any of the RFCs > that nails down ranges for manual SA SPIs? There isn't. SPIs below 256 are reserved for special purposes (only one of them is currently assigned: 0 is reserved for system internal use and may never appear in a packet), but there is no explicit assignment for manual keying. The Linux FreeS/WAN project has decided to reserve all three-digit hex numbers, i.e. 0x100 through 0xfff, for manual keying (one-digit and two-digit hex numbers being the special-purposes area), and its automatic keying will never generate those. At the moment, I don't know of anybody else who has copied this. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jan 15 22:23:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA11311; Mon, 15 Jan 2001 22:23:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA19449 Tue, 16 Jan 2001 00:08:16 -0500 (EST) Date: Tue, 16 Jan 2001 00:10:11 -0500 (EST) From: Henry Spencer To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: Protection of port 500 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 Mon, 15 Jan 2001, Stephen Kent wrote: > A UDP/500 SPD entry applies to subscriber traffic, and thus > determines whether a subscriber behind the IPsec implementation > (especially appropriate in an SG). However, an IPsec implementation > can send and receive traffic for ITSELF independent of SPD/SAD entries. I'm curious: where, exactly, does the published spec say that? I can't find any such statement. Quoth the RFC (2401): "The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic." "The SPD is used to control the flow of ALL traffic through an IPsec system, including security and key management traffic (e.g., ISAKMP) from/to entities behind a security gateway. This means that ISAKMP traffic must be explicitly accounted for in the SPD, else it will be discarded..." "As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", the SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded." These flatly-stated requirements do not seem to leave any loopholes for local management traffic; the word "all" is not usually interpreted to mean "most". (The second quoted statement explicitly mentions ISAKMP traffic from behind a gateway, which might make one wonder whether ISAKMP traffic from the gateway itself was a different case... but the RFC does not actually say anything about that case.) To me, this means that the exemption for local management traffic must be part of the explicit policy, as embodied in both the SPD and whatever higher-level representation of it the administrator deals with. (And it would obviously be desirable for any policy lacking such an exemption to draw at least a warning message.) Doing otherwise is non-compliant. I would further observe that making the administrator explicitly aware of the management traffic is probably a good idea. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jan 15 22:33:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA11598; Mon, 15 Jan 2001 22:33:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA19476 Tue, 16 Jan 2001 00:16:15 -0500 (EST) Date: Tue, 16 Jan 2001 00:18:11 -0500 (EST) From: Henry Spencer To: Stephen Kent cc: IP Security List Subject: Re: Inbound processing of ESP packet 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 Mon, 15 Jan 2001, Stephen Kent wrote: > Steve Bellovin is right, Henry. A LAN interface may include padding > after the end of the IP packet... Please note what I said about the lower-level value possibly being supplemented by information from the IP total length. The IP total length field is authoritative, in a realistic sense, only if the lower levels actually delivered at least that much data. Otherwise the lower-level count *is* authoritative about how much data is present, and the discrepancy between that and the IP length indicates a lower-level transmission error. The only statement of Steve B's that I actually disagree with is his assertion that I am wrong. :-) We're saying the same thing in two different ways. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jan 16 00:48:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA03077; Tue, 16 Jan 2001 00:48:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA19667 Tue, 16 Jan 2001 02:07:52 -0500 (EST) From: Dan McDonald Message-Id: <200101160706.f0G76NA23868@kebe.Eng.Sun.COM> Subject: Re: Protection of port 500 In-Reply-To: from Matthew Franz at "Jan 15, 2001 10:15:19 pm" To: Matthew Franz Date: Mon, 15 Jan 2001 23:06:23 -0800 (PST) CC: ipsec@lists.tislabs.com Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Isn't this approach just looking for trouble? Not really... > Can applications be trusted to protect themselves from, let's say, from DoS > attacks? I used the phrase "trusted applications" in the almost MLS-sense of the word. If you RTM on Solaris, you'll note that bypassing node-wide policy can only be done by root privileged apps. You shouldn't grant such a privilege willy-nilly, which I believe is your point. BTW, you can never _fully_ extinguish Denial-of-Service. There's a paper co-authored by a contributor to this list and WG that explains this. All you can do is reduce the risk to an acceptable level. (What's the difference between DoS and a very busy day of legitimate use?) > I'd want at least the option of some lower layer policy enforcement (ACLs, > filters, etc.) in additon to whatever the app layer provides. For such paranoia, a good implementation should allow that. We allow node-wide policy to disallow even the root-restricted bypass privilege we normally allow. We do not default to that, so that we can make our IKE daemon do per-socket bypass, as well as allow future versions of diagnostic tools (e.g. traceroute) to potentially bypass policy on a per-invocation basis. Dan From owner-ipsec@lists.tislabs.com Tue Jan 16 04:20:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA23426; Tue, 16 Jan 2001 04:20:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA20984 Tue, 16 Jan 2001 05:46:52 -0500 (EST) Message-Id: <200101161048.f0GAmlO97519@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Dan McDonald cc: Matthew Franz , ipsec@lists.tislabs.com Subject: Re: Protection of port 500 In-reply-to: Your message of Mon, 15 Jan 2001 23:06:23 PST. <200101160706.f0G76NA23868@kebe.Eng.Sun.COM> Date: Tue, 16 Jan 2001 11:48:47 +0100 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > I'd want at least the option of some lower layer policy enforcement (ACLs, > filters, etc.) in additon to whatever the app layer provides. For such paranoia, a good implementation should allow that. We allow node-wide policy to disallow even the root-restricted bypass privilege we normally allow. We do not default to that, so that we can make our IKE daemon do per-socket bypass, as well as allow future versions of diagnostic tools (e.g. traceroute) to potentially bypass policy on a per-invocation basis. => FreeBSD 4.2 (and all BSDs with KAME based IPsec support) has a ping[6] with a policy option. I have just tried with a remote site configured with required ESP for everything and it works at you believe (ie. a ping with no policy or the default output policy (out entrust) triggers IKE exchanges and works after a small delay, the same with "out bypass" fails because the peer rejects unprotected echo requests). This is exactly what you have just described using your proposed API (draft-mcdonald-simple-ipsec-api-01.txt) ideas... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Jan 16 15:35:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04443; Tue, 16 Jan 2001 15:35:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23594 Tue, 16 Jan 2001 16:42:12 -0500 (EST) From: "sankar ramamoorthi" To: Subject: ipsec error protocol Date: Tue, 16 Jan 2001 13:40:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There has been a lot of discussion in the past about state-synchronization issues in ipsec, packets vanishing into blackhole because of ipsec peers getting out-of-step, potential DOS problems in suggested solutions, need for secure in-band error communication etc. As for as I know, there was no clear resolution on this issue and it still remains unsolved. The closest working solution was using keep-alives, which many (including me) opposed as too heavyweight to solve a basic protocol problem. Using inband-pings would be nice way to check if the peer's state is in sync. This in conjunction with a suitable icmp error from the peer, would allow one to detect quickly if the ipsec SA state is in sync between both the communicating parties. One of the opposition to using inband-ping was that it was difficult to distinguish from customer traffic. Here is a suggestion for adding control messages to ipsec spi values 1-255 are reserved by IANA for future use. I was wondering if a reserved spi, could be used for ipsec control communication. This could allow control messages including secure echo-replies to be implemented. The control messages of the form ip packet esp header with special spi indicating payload is ipsec-control ipsec control payload (yet to be defined) The receiving entity MUST handle the control packets when it receives a ah/esp packet with the special spi value. The control message can be of the type encrypted echo/echo-reply for a specific tunnel, authenticated or encrypted error notification etc. Welcome your feedback on this idea. Thanks, -- sankar ramamoothi -- From owner-ipsec@lists.tislabs.com Tue Jan 16 17:09:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA07965; Tue, 16 Jan 2001 17:09:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA23880 Tue, 16 Jan 2001 18:39:20 -0500 (EST) Date: Tue, 16 Jan 2001 15:40:02 -0800 (PST) Message-Id: <200101162340.PAA07769@potomac.incog.com> From: ford@incog.com (Mike Ditto) To: henry@spsystems.net CC: ipsec@lists.tislabs.com In-reply-to: (message from Henry Spencer on Mon, 15 Jan 2001 23:32:44 -0500 (EST)) Subject: Re: Manual SA SPI range Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Henry Spencer ... > SPIs below 256 are reserved for special purposes (only one > of them is currently assigned: 0 is reserved for system internal use and > may never appear in a packet) Actually one other SPI value has been assigned by the IANA. SPI 1 is assigned to the SKIP protocol. http://www.isi.edu/in-notes/iana/assignments/spi-numbers > The Linux FreeS/WAN project has decided to reserve all three-digit hex > numbers, i.e. 0x100 through 0xfff, for manual keying (one-digit and > two-digit hex numbers being the special-purposes area), and its automatic > keying will never generate those. At the moment, I don't know of anybody > else who has copied this. I like this idea. It's completely arbitrary, but a useful informal convention. Users will inevitably ask what range is "safe" for them to use for manual keying when they might use IKE with the same destination address, so it's good to have something to tell them, even though it has hardly any practical effect. And it's trivial to implement since a generated SPI should avoid 0-0xFF anyway, so one can just slightly raise the upper bound of that range. 0x100-0xFFF seems like a reasonable chunk of space to set aside. I think I'll make SunScreen follow and document this convention too, so there's the start of a de facto standard for you. -=] Mike [=- From owner-ipsec@lists.tislabs.com Wed Jan 17 04:49:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA28571; Wed, 17 Jan 2001 04:49:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA26759 Wed, 17 Jan 2001 06:07:52 -0500 (EST) Message-ID: <3A657E7A.CC3AB4BB@cisco.com> Date: Wed, 17 Jan 2001 12:14:02 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test12 i686) X-Accept-Language: en MIME-Version: 1.0 To: sankar ramamoorthi CC: ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In this case, you assume there is a phase 2 SA available and identified by a reserved SPI. What if the host crashed ? It does not have a phase 2, and would have to negotiate a new one, possibly involing a phase 1, thus opening the door to clogging. This is just an other way to transport a delete notification or a keepalive but has the same drawbacks as the solutions proposed so far. ISAKMP already proposes such a mechanism (notification payloads -- except keepalives) but as they are unauthenticated, they can not be trusted. regards, frederic detienne sankar ramamoorthi wrote: > > There has been a lot of discussion in the past about state-synchronization > issues in ipsec, packets vanishing into blackhole because of ipsec peers > getting out-of-step, potential DOS problems in suggested solutions, > need for secure in-band error communication etc. > > As for as I know, there was no clear resolution on this issue and it > still remains unsolved. The closest working solution was using keep-alives, > which many (including me) opposed as too heavyweight to solve a basic > protocol problem. > > Using inband-pings would be nice way to check if the peer's state is in > sync. > This in conjunction with a suitable icmp error from the peer, would allow > one > to detect quickly if the ipsec SA state is in sync between both the > communicating parties. > > One of the opposition to using inband-ping was that it was difficult to > distinguish from customer traffic. > > Here is a suggestion for adding control messages to ipsec > > spi values 1-255 are reserved by IANA for future use. I was wondering > if a reserved spi, could be used for ipsec control communication. > This could allow control messages including secure echo-replies to be > implemented. The control messages of the form > > ip packet > esp header with special spi indicating payload is ipsec-control > ipsec control payload (yet to be defined) > > The receiving entity MUST handle the control packets when it receives > a ah/esp packet with the special spi value. The control message can be > of the type encrypted echo/echo-reply for a specific tunnel, authenticated > or encrypted error notification etc. > > Welcome your feedback on this idea. > > Thanks, > > -- sankar ramamoothi -- From owner-ipsec@lists.tislabs.com Wed Jan 17 13:36:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01035; Wed, 17 Jan 2001 13:36:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29820 Wed, 17 Jan 2001 14:20:45 -0500 (EST) From: "Scott G. Kelly" To: fd@cisco.com Cc: sankar ramamoorthi , ipsec@lists.tislabs.com Message-ID: <3A65F0D4.8D7F1FE0@redcreek.com> Date: Wed, 17 Jan 2001 11:21:56 -0800 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: ipsec error protocol References: <3A657E7A.CC3AB4BB@cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Frederic, Frédéric Detienne wrote: > > In this case, you assume there is a phase 2 SA available and identified > by a reserved SPI. What if the host crashed ? It does not have a phase > 2, and would have to negotiate a new one, possibly involing a phase 1, > thus opening the door to clogging. But the crashed host is precisely what you are trying to detect, and in this case, you will need to set up at least one new ike SA anyway, so this is not persuasive. > This is just an other way to transport a delete notification or a > keepalive but has the same drawbacks as the solutions proposed so far. > > ISAKMP already proposes such a mechanism (notification payloads > -- except keepalives) but as they are unauthenticated, they can > not be trusted. Use of an explicit phase 2 SA for this has been suggested by at least 2 other wg participants, if I remember correctly. What are the benefits vs drawbacks of this when compared to an ike-based solution? Benefits: o allows you to eliminate the ike/stack interaction required of an ike-based mechanism o phase 2 control messages could be authenticated without changing ike Drawbacks: o overhead for maintaining additional SA state o may require definition of additional SA characteristic in DOI (ike vs control), although not strictly necessary I'm sure there are other entries in each list - I invite others to add to these lists. Scott From owner-ipsec@lists.tislabs.com Wed Jan 17 14:11:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA03203; Wed, 17 Jan 2001 14:11:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00004 Wed, 17 Jan 2001 15:17:25 -0500 (EST) Message-Id: <200101172019.f0HKJB5106736@thunk.east.sun.com> From: Bill Sommerfeld To: "Scott G. Kelly" cc: fd@cisco.com, sankar ramamoorthi , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol In-reply-to: Your message of "Wed, 17 Jan 2001 11:21:56 PST." <3A65F0D4.8D7F1FE0@redcreek.com> Reply-to: sommerfeld@East.Sun.COM Date: Wed, 17 Jan 2001 15:19:11 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To repeat a previous suggestion I made to this list last year: If we have the system sign a "birth certificate" when it reboots (including a reboot time or boot sequence number), we could include that with a "bad spi" ICMP error and in the negotiation of the IKE SA. This pushes the burden of reestablishing state to the end which already thinks it has shared state and has traffic it wants to send. The system which is receiving packets to unknown SPI's merely has to respond with a simple message which involves no real-time cryptography (it should, of course, be rate limited). The system receiving the error message can discard it if it doesn't correspond to existing state or if it's "old news" (i.e., you get replay protection); if it's not old news, you can rate-limit how often you attempt to verify the signature. I think that, in practice, a boot sequence number will suffice and require minimal state. Also, the "birth certificate" could be included in an "unknown phase 1" IKE error, to allow for faster recovery from loss of phase 1 state.. - Bill From owner-ipsec@lists.tislabs.com Wed Jan 17 14:55:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05388; Wed, 17 Jan 2001 14:55:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00324 Wed, 17 Jan 2001 16:08:03 -0500 (EST) Message-ID: <3A660B48.7825CEF5@cisco.com> Date: Wed, 17 Jan 2001 22:14:48 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" CC: sankar ramamoorthi , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: <3A657E7A.CC3AB4BB@cisco.com> <3A65F0D4.8D7F1FE0@redcreek.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Scott G. Kelly" wrote: > > Hi Frederic, > > Frédéric Detienne wrote: > > > > In this case, you assume there is a phase 2 SA available and identified > > by a reserved SPI. What if the host crashed ? It does not have a phase > > 2, and would have to negotiate a new one, possibly involing a phase 1, > > thus opening the door to clogging. > > But the crashed host is precisely what you are trying to detect, and in > this case, you will need to set up at least one new ike SA anyway, so > this is not persuasive. I agree. I just say that this does not bring anything really "new". > > > This is just an other way to transport a delete notification or a > > keepalive but has the same drawbacks as the solutions proposed so far. > > > > ISAKMP already proposes such a mechanism (notification payloads > > -- except keepalives) but as they are unauthenticated, they can > > not be trusted. > > > > Use of an explicit phase 2 SA for this has been suggested by at least 2 > other wg participants, if I remember correctly. What are the benefits vs > drawbacks of this > when compared to an ike-based solution? > > Benefits: > o allows you to eliminate the ike/stack interaction required of an > ike-based mechanism > o phase 2 control messages could be authenticated without changing ike > > Drawbacks: > o overhead for maintaining additional SA state > o may require definition of additional SA characteristic in DOI (ike vs > control), although not strictly necessary > Allow me to bring the conversation on an other ground: Types of black holes ==================== There are two "types" of black holes in IPSec: 1) you send things to a peer that is dead in an IP prospective 2) you send things to a peer that is dead in an IPSec prospective It is not the role of IPsec to detect (1) and here is why: . In the case of IPSec as a tunneling protocol, there are solution to this problem: routing protocols. (there are other solutions but less generic). . In the case of a peer to peer protocol, it does not matter for IP&IPSec since the other side is dead anyway. It is up to the upper layer protocols to recover. Now, when the dead peer comes back to live, it causes issues (missing SA's on one side). There are several ways to detect (2): a) acknowledgements b) polling c) invalid SPI notifications I know that incidently, (a) and (b) solve (1) but this is not the main purpose. (b) is a poor solution that . consumes bandwidth (esp. in IPsec concentration) . keeps dialup lines up for nothing (except with some nice tricks) . converges slowly (a) and (c) are much better. (a) is easy to implement without chaning IPSec nor IKE (I have a solution that needs a separate RFC but it would be good for any tunneling protocol, including IPSec) but relies on timeout => slow (c) certainly requires some changes to the current RFC. I think of at least one fair solution with a new ISAKMP payload. If you go for acknowledgements (point (a)), you can transport it in anything: . an IPSec packet with a dedicated SA . an IKE payload. . an IPsec packet using the other SA of the SA pair to respond (what I would recommend as it can be implemented without changing the current RFC's). And this is were I wanted to go: I do not criticize Sankar's proposal. I just mean it does not add anything new: discussing the way to transport notifications, acknowledgements or echo (requests and replies) does not bring anything as we can chose. Sorry about that, period. Now, we can go a step further Solutions proposals =================== 1) Acknowledgments ++++++++++++++++++ Acknowledgments can be sent by the receiving end regularly (based on a number of bytes or packets received). If a certain time has elapsed without the other side receiving the acknowledgement, the corresponding SA's should be torn down. How to send those acknowledgements. There are two obvious solutions. a) by changing IPSec -------------------- When a number of bytes/packets have been decrypted on an inbound IPSec SA, send a packet using the outbound IPSec SA. Use piggy backing when possible but send and empty payload if necessary. Only works if the SA contains some sort of authentication (AH or ESP w/ auth). b) without changing IPSec ------------------------- define a new generic IP payload of type "acknowledgement" that would have a header like ack header ::= next protocol | size | would be defined for different types of protocol and in particular AH and ESP. It could contain the SPI number and the last received ID. The "next payload" would allow the header to carry an other IP packet or payload allowing the acknowledgement to be piggy backed without touching IPSec. Drawbacks of (a) and (b): you rely on timers, this converges slowly but anyway polling too. 2) Notifications ++++++++++++++++ There are again two cases. a) the SA was mistakenly deleted and B still has a phase 1 SA (by chance, this *can* happen) ------------------------------------------------------------- B simply sends an AUTHENTICATED delete notification (under the cover of the phase 1) to A and a phase 2 can restart if necessary. b) B really respawned and does not have a phase 1 SA (more frequent) ---------------------------------------------------- By adding a new payload of saying "in order to delete SA with SPI xxx" in the initial offer. Say peer A and peer B have a pair of SA's. B reboots and loses its SA's. A keeps sending traffic, B has nothing to send and receives IPSec packets with unknown SPI's from A. B could then say IP(B->A) UDP (500,500) CKi,0 | SA proposal | "in order to delete SA with SPI xxx" If A does NOT have SPI number xxx, it simply ignores the request. Otherwise, it responds and copies the "in order to delete SA with SPI xxx" payload. IP(A->B) UDP (500,500) CKi,CKr | SA chosen | "in order to delete SA with SPI xxx" and the exchange continues normally. So we have the same level of protection as with the usual Cookies. Just an extra payload and no extra crypto. At the end of phase 1, B can now send an AUTHENTICATED delete notification to A. Am I missing something ? regards, fred > I'm sure there are other entries in each list - I invite others to add > to these lists. > > Scott From owner-ipsec@lists.tislabs.com Wed Jan 17 14:55:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05404; Wed, 17 Jan 2001 14:55:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00369 Wed, 17 Jan 2001 16:19:30 -0500 (EST) Message-ID: <3A660DFB.DE19C011@cisco.com> Date: Wed, 17 Jan 2001 22:26:19 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sommerfeld@East.Sun.COM CC: "Scott G. Kelly" , sankar ramamoorthi , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: <200101172019.f0HKJB5106736@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Bill, I remember your e-mail. Actually, I think it is nice solution but I have a few remarks: a) not everyone knows how many times that host rebooted so far. So the latest cert of birth should be included in every phase 1 negotiation. Otherwise, it is as untrustworthy as an ICMP or authenticated ISAKMP notifications. I mean: an cert of birth with a boot sequence number only makes sense if you can measure the monotonic increase of the sequence. b) if an attacker finds a way to reboot a host generating certs of birth, this can force the signing host (either the host itself (self signed cert)) or the CA to sign an enormous amount of data, therefor weakening its private key (clear text attack). I do not know how efficient that would be but I would welcome the advice of a cryptographer. Besides this, I stick to your idea. fred. Bill Sommerfeld wrote: > > To repeat a previous suggestion I made to this list last year: > > If we have the system sign a "birth certificate" when it reboots > (including a reboot time or boot sequence number), we could include > that with a "bad spi" ICMP error and in the negotiation of the IKE SA. > > This pushes the burden of reestablishing state to the end which > already thinks it has shared state and has traffic it wants to send. > > The system which is receiving packets to unknown SPI's merely has to > respond with a simple message which involves no real-time cryptography > (it should, of course, be rate limited). > > The system receiving the error message can discard it if it doesn't > correspond to existing state or if it's "old news" (i.e., you get > replay protection); if it's not old news, you can rate-limit how often > you attempt to verify the signature. > > I think that, in practice, a boot sequence number will suffice and > require minimal state. Also, the "birth certificate" could be > included in an "unknown phase 1" IKE error, to allow for faster > recovery from loss of phase 1 state.. > > - Bill From owner-ipsec@lists.tislabs.com Wed Jan 17 15:09:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06286; Wed, 17 Jan 2001 15:09:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA00387 Wed, 17 Jan 2001 16:36:41 -0500 (EST) Message-Id: <200101172138.f0HLcK5106913@thunk.east.sun.com> From: Bill Sommerfeld To: fd@cisco.com cc: sommerfeld@East.Sun.COM, "Scott G. Kelly" , sankar ramamoorthi , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol In-reply-to: Your message of "Wed, 17 Jan 2001 22:26:19 +0100." <3A660DFB.DE19C011@cisco.com> Reply-to: sommerfeld@East.Sun.COM Date: Wed, 17 Jan 2001 16:38:20 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > a) not everyone knows how many times that host rebooted so far. So > the latest cert of birth should be included in every phase 1 > negotiation. I said.. "in the negotiation of the IKE SA".. same thing. BTW, from the embedded device front, my understanding is that SNMPv3 security uses a reboot counter, so maintaining this shouldn't be a problem for the embedded folks. > b) if an attacker finds a way to reboot a host generating certs of > birth, this can force the signing host (either the host itself (self > signed cert)) or the CA to sign an enormous amount of data, therefor > weakening its private key (clear text attack). I do not know how > efficient that would be but I would welcome the advice of a > cryptographer. I used the term "certificate" in the generic sense. In some sense it could be more accurately described as a "death certificate for all prior state". It wouldn't have to be (and probably shouldn't be) in x.509 format.. (x.509 specifies one way to do "certificates"; it is not the only way to do certificates, and in some cases, like this one, an application-specific format is appropriate). - Bill From owner-ipsec@lists.tislabs.com Wed Jan 17 15:30:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07801; Wed, 17 Jan 2001 15:30:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00434 Wed, 17 Jan 2001 17:01:52 -0500 (EST) From: "Scott G. Kelly" To: sommerfeld@East.Sun.COM Cc: fd@cisco.com, sankar ramamoorthi , ipsec@lists.tislabs.com Message-ID: <3A661690.13A9ED29@redcreek.com> Date: Wed, 17 Jan 2001 14:02:56 -0800 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: ipsec error protocol References: <200101172019.f0HKJB5106736@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: > > To repeat a previous suggestion I made to this list last year: > > If we have the system sign a "birth certificate" when it reboots > (including a reboot time or boot sequence number), we could include > that with a "bad spi" ICMP error and in the negotiation of the IKE SA. > This is a quick response, and admittedly, I haven't given this a lot of thought, but I'm wondering: isn't this essentially the function of the INITIAL-CONTACT message? > This pushes the burden of reestablishing state to the end which > already thinks it has shared state and has traffic it wants to send. > > The system which is receiving packets to unknown SPI's merely has to > respond with a simple message which involves no real-time cryptography > (it should, of course, be rate limited). > > The system receiving the error message can discard it if it doesn't > correspond to existing state or if it's "old news" (i.e., you get > replay protection); if it's not old news, you can rate-limit how often > you attempt to verify the signature. > > I think that, in practice, a boot sequence number will suffice and > require minimal state. Also, the "birth certificate" could be > included in an "unknown phase 1" IKE error, to allow for faster > recovery from loss of phase 1 state.. > > - Bill From owner-ipsec@lists.tislabs.com Wed Jan 17 15:50:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08868; Wed, 17 Jan 2001 15:50:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00484 Wed, 17 Jan 2001 17:18:42 -0500 (EST) From: "sankar ramamoorthi" To: Cc: Subject: RE: ipsec error protocol Date: Wed, 17 Jan 2001 14:17:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3A657E7A.CC3AB4BB@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, To clarify, I am not assuming there is a phase2 SA avialable for the reserved SPI. I am suggesting we use the reserved SPI as a way to specify error packets for ipsec. The reserved SPI is an identifier to say the payload inside is an ipsec error packet. The payload may be an error packet of type 'encrypted ping' for any specific phase2 SA that the peer wants to check the health of. The format I was proposing was ip header ESP with reserved SPI Header for ipsec error (different type of errors/controls can also be adefined a.k.a icmp) IPSec error/control payload (can be another ESP header containing the encrypted ping payload for a specific SPI that the peer is interested in) As you can see, the reserverd SPI is only used to tunnel the actual error/control packet we are interested in. Using the reserved SPI clearly can allow an ipsec implementation to identify the payload as a control packet for ipsec purposes. There can be no phase2 SA with reserved SPI, since it cannot be negotiated as per the spec. Hence if an ike implementation receives a ESP payload with reserved SPI, it can be safely treated as carrying a ipsec control packet in the clear. Different type of ipsec control packets can be defined one of which can be an encrypted ping on a specific phase2 SA the peer is interested in. If the receiving ipsec implementation has the SA and is able to decrypt the encrypted ping-request, it can send a encrypted-reply tunneled in ESP payload with the reserved SPI. Currently as defined ipsec is a network layer encapsulation method without clear path for error/control packets. This proposal tries to address it. -- sankar -- -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Frédéric Detienne Sent: Wednesday, January 17, 2001 3:14 AM To: sankar ramamoorthi Cc: ipsec@lists.tislabs.com Subject: Re: ipsec error protocol In this case, you assume there is a phase 2 SA available and identified by a reserved SPI. What if the host crashed ? It does not have a phase 2, and would have to negotiate a new one, possibly involing a phase 1, thus opening the door to clogging. This is just an other way to transport a delete notification or a keepalive but has the same drawbacks as the solutions proposed so far. ISAKMP already proposes such a mechanism (notification payloads -- except keepalives) but as they are unauthenticated, they can not be trusted. regards, frederic detienne sankar ramamoorthi wrote: > > There has been a lot of discussion in the past about state-synchronization > issues in ipsec, packets vanishing into blackhole because of ipsec peers > getting out-of-step, potential DOS problems in suggested solutions, > need for secure in-band error communication etc. > > As for as I know, there was no clear resolution on this issue and it > still remains unsolved. The closest working solution was using keep-alives, > which many (including me) opposed as too heavyweight to solve a basic > protocol problem. > > Using inband-pings would be nice way to check if the peer's state is in > sync. > This in conjunction with a suitable icmp error from the peer, would allow > one > to detect quickly if the ipsec SA state is in sync between both the > communicating parties. > > One of the opposition to using inband-ping was that it was difficult to > distinguish from customer traffic. > > Here is a suggestion for adding control messages to ipsec > > spi values 1-255 are reserved by IANA for future use. I was wondering > if a reserved spi, could be used for ipsec control communication. > This could allow control messages including secure echo-replies to be > implemented. The control messages of the form > > ip packet > esp header with special spi indicating payload is ipsec-control > ipsec control payload (yet to be defined) > > The receiving entity MUST handle the control packets when it receives > a ah/esp packet with the special spi value. The control message can be > of the type encrypted echo/echo-reply for a specific tunnel, authenticated > or encrypted error notification etc. > > Welcome your feedback on this idea. > > Thanks, > > -- sankar ramamoothi -- From owner-ipsec@lists.tislabs.com Wed Jan 17 15:55:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08969; Wed, 17 Jan 2001 15:55:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00535 Wed, 17 Jan 2001 17:24:09 -0500 (EST) Message-Id: <200101172225.f0HMPv5106979@thunk.east.sun.com> From: Bill Sommerfeld To: "Scott G. Kelly" cc: sommerfeld@East.Sun.COM, fd@cisco.com, sankar ramamoorthi , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol In-reply-to: Your message of "Wed, 17 Jan 2001 14:02:56 PST." <3A661690.13A9ED29@redcreek.com> Reply-to: sommerfeld@East.Sun.COM Date: Wed, 17 Jan 2001 17:25:57 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > This is a quick response, and admittedly, I haven't given this a lot of > thought, but I'm wondering: isn't this essentially the function of the > INITIAL-CONTACT message? No. initial-contact is a notify message transmitted within a recently-created phase 1 SA. in order for it to be authenticated, you need to have gone through all the IKE phase 1 overhead to re-build the state. initial-contact is just an optimization once the SA is set up; the receiver could just send the sender DELETE messages for each bogus SPI it gets. Here's a revised problem statement: Assume that two nodes A and B have ipsec SA's up, and periodically A is sending B a packet which B responds to (i.e., all exchanges are initiated by A; B is just a passive responder/server. Now, assume that B suddenly reboots and it tosses away all IKE and ipsec SA state. It comes back up, and starts getting AH/ESP packets for SA's it doesn't remember. How do we efficiently recover from this state (where A has stale state for B) without creating opportunities for denial-of-service attacks and without having to wait for the SA's to expire and for rekey to kick in? The "birth certificate" approach puts the computational burden (signature verification) on the end which still has state for the association and which has traffic it wants to send. - Bill From owner-ipsec@lists.tislabs.com Wed Jan 17 16:28:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09512; Wed, 17 Jan 2001 16:28:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00675 Wed, 17 Jan 2001 18:01:38 -0500 (EST) Message-ID: <3A6625EC.765098@cisco.com> Date: Thu, 18 Jan 2001 00:08:28 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sommerfeld@East.Sun.COM CC: "Scott G. Kelly" , sankar ramamoorthi , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: <200101172138.f0HLcK5106913@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: > > > a) not everyone knows how many times that host rebooted so far. So > > the latest cert of birth should be included in every phase 1 > > negotiation. > > I said.. "in the negotiation of the IKE SA".. same thing. yep, ok. I was mislead by the order of things in the sentence. My bad. > BTW, from the embedded device front, my understanding is that SNMPv3 > security uses a reboot counter, so maintaining this shouldn't be a > problem for the embedded folks. > > > b) if an attacker finds a way to reboot a host generating certs of > > birth, this can force the signing host (either the host itself (self > > signed cert)) or the CA to sign an enormous amount of data, therefor > > weakening its private key (clear text attack). I do not know how > > efficient that would be but I would welcome the advice of a > > cryptographer. > > I used the term "certificate" in the generic sense. In some sense it > could be more accurately described as a "death certificate for all > prior state". > > It wouldn't have to be (and probably shouldn't be) in x.509 > format.. (x.509 specifies one way to do "certificates"; it is not the > only way to do certificates, and in some cases, like this one, an > application-specific format is appropriate). Right but to make the notification (ICMP or whatever) accepted by the other side, you need to have the pseudo-cert signed by a form of pub key signature. The pub key must be assumed known everywhere => it can not be something negotiated (chicken & egg) => it would weaken the private key over time. IKE, typically does not use the public keys directly (except in revised pubkey encryption but who uses it?) and I always assumed that we wanted to encrypt as little as possible with our pubkey. With digital signatures, this is done only after the DH exponentiation => the attacker would have to spend a considerable amount of CPU time to do that. Frankly, these are just thoughts; I have no idea how this would be considered secure by crypto folks. Oh yes... and here is the "flaw": you unveil the identity which is what Main mode tried to protect. Imho, not a big deal compared to the advantage. In any case, your proposal is similar to mine then (I just did not notice). Except that I do not rely on a cert at all but I leave the burden on the one that misses the SA. However, this problem is embedded within IKE itself. Summary: your solution ------------- -pro's: uses a cert of birth => notification is trustworthy. Deletes all the old SA's at once. Puts the burden of the one that thinks it has valid SA's. -con's: Requires an extra packet anyway (notification). Requires the definition of a new type of cert (hard). May weaken the private key. Unveils normally hidden identities. my solution ----------- -neutral: just as strong/weak as IKE cookies -con's: Requires a delete notification per SA to delete. I think I can modify my solution to integrate your advantages by defining two new ISAKMP payload. Scenario: here, B is missing an SA to decapsulate traffic sent by IP(A)/SPI(xxx). New payloads: . "in order to delete SA with SPI xxx" . "my reboot sequence number is yyy" IP(B->A) UDP (500,500) CKi,0 | SA proposals | "in order to delete SA with SPI xxx" IP(A->B) UDP (500,500) CKi,CKr | SA chosen | "in order to delete SA with SPI xxx" IP(B->A) UDP (500,500) CKi,CKr | keying material IP(A->B) UDP (500,500) CKi,CKr | keying material IP(B->A) UDP (500,500) * CKi,CKr | sig(hash) | [regular CERT] | ["my reboot sequence number is yyy"] IP(A->B) UDP (500,500) * CKi,CKr | sig(hash) | [regular CERT] | ["my reboot sequence number is zzz"] . here, A would respond to B only if it actually had an outbound SA with SPI xxx. . if "my reboot sequence number is yyy" is present and yyy > previous seq#, all phase 2 SA's with that identity are deleted (same with zzz (optional)). . at the end of the exchange, A should delete SPI xxx. . if B has additional SA's to delete (but not all), it can send *protected* delete notifications. And now, you have exactly the same level of security as Main Mode at the (small) expense of defining two new payloads, without additional cryptography *at all* (not even certs of birth). Correct me if I am wrong, it is a status quo for IKE (level of protection) but it fixes the missing phase 2 SA issue. frederic > - Bill From owner-ipsec@lists.tislabs.com Wed Jan 17 18:23:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA13722; Wed, 17 Jan 2001 18:23:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA01428 Wed, 17 Jan 2001 19:49:39 -0500 (EST) From: "sankar ramamoorthi" To: , Cc: "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Wed, 17 Jan 2001 16:48:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3A6625EC.765098@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, My comments on the suggestions 1. Extending IKE (with new payloads etc) to what is basically an ipsec problem seems to be an incorrect. If ipsec state (ipsec-SA) is out of sync between two peers, it should be dealt in ipsec. 2. If IKE state(phase1 SA or phase2 SA) is out of sync between two peers, it should be dealt as part ike protocol Combining the two seems incorrect. For example if a host has no ipsec-state for a communicating peer and wants to convey that information, it should not have to start another ike exchange for that purpose as suggested. For all purposes the host may not be interested in sending a udp[500] traffic. Also the proposed solutions assume IKE and do not take of manual ipsec SAs. -----Original Message----- From: root@strange-brew.cisco.com [mailto:root@strange-brew.cisco.com]On Behalf Of Frédéric Detienne Sent: Wednesday, January 17, 2001 3:08 PM To: sommerfeld@east.sun.com Cc: Scott G. Kelly; sankar ramamoorthi; ipsec@lists.tislabs.com Subject: Re: ipsec error protocol Bill Sommerfeld wrote: > > > a) not everyone knows how many times that host rebooted so far. So > > the latest cert of birth should be included in every phase 1 > > negotiation. > > I said.. "in the negotiation of the IKE SA".. same thing. yep, ok. I was mislead by the order of things in the sentence. My bad. > BTW, from the embedded device front, my understanding is that SNMPv3 > security uses a reboot counter, so maintaining this shouldn't be a > problem for the embedded folks. > > > b) if an attacker finds a way to reboot a host generating certs of > > birth, this can force the signing host (either the host itself (self > > signed cert)) or the CA to sign an enormous amount of data, therefor > > weakening its private key (clear text attack). I do not know how > > efficient that would be but I would welcome the advice of a > > cryptographer. > > I used the term "certificate" in the generic sense. In some sense it > could be more accurately described as a "death certificate for all > prior state". > > It wouldn't have to be (and probably shouldn't be) in x.509 > format.. (x.509 specifies one way to do "certificates"; it is not the > only way to do certificates, and in some cases, like this one, an > application-specific format is appropriate). Right but to make the notification (ICMP or whatever) accepted by the other side, you need to have the pseudo-cert signed by a form of pub key signature. The pub key must be assumed known everywhere => it can not be something negotiated (chicken & egg) => it would weaken the private key over time. IKE, typically does not use the public keys directly (except in revised pubkey encryption but who uses it?) and I always assumed that we wanted to encrypt as little as possible with our pubkey. With digital signatures, this is done only after the DH exponentiation => the attacker would have to spend a considerable amount of CPU time to do that. Frankly, these are just thoughts; I have no idea how this would be considered secure by crypto folks. Oh yes... and here is the "flaw": you unveil the identity which is what Main mode tried to protect. Imho, not a big deal compared to the advantage. In any case, your proposal is similar to mine then (I just did not notice). Except that I do not rely on a cert at all but I leave the burden on the one that misses the SA. However, this problem is embedded within IKE itself. Summary: your solution ------------- -pro's: uses a cert of birth => notification is trustworthy. Deletes all the old SA's at once. Puts the burden of the one that thinks it has valid SA's. -con's: Requires an extra packet anyway (notification). Requires the definition of a new type of cert (hard). May weaken the private key. Unveils normally hidden identities. my solution ----------- -neutral: just as strong/weak as IKE cookies -con's: Requires a delete notification per SA to delete. I think I can modify my solution to integrate your advantages by defining tw o new ISAKMP payload. Scenario: here, B is missing an SA to decapsulate traffic sent by IP(A)/SPI(xxx). New payloads: . "in order to delete SA with SPI xxx" . "my reboot sequence number is yyy" IP(B->A) UDP (500,500) CKi,0 | SA proposals | "in order to delete SA with SPI xxx" IP(A->B) UDP (500,500) CKi,CKr | SA chosen | "in order to delete SA with SPI xxx" IP(B->A) UDP (500,500) CKi,CKr | keying material IP(A->B) UDP (500,500) CKi,CKr | keying material IP(B->A) UDP (500,500) * CKi,CKr | sig(hash) | [regular CERT] | ["my reboot sequence number is yyy"] IP(A->B) UDP (500,500) * CKi,CKr | sig(hash) | [regular CERT] | ["my reboot sequence number is zzz"] . here, A would respond to B only if it actually had an outbound SA with SPI xxx. . if "my reboot sequence number is yyy" is present and yyy > previous seq#, all phase 2 SA's with that identity are deleted (same with zzz (optional)). . at the end of the exchange, A should delete SPI xxx. . if B has additional SA's to delete (but not all), it can send *protected* delete notifications. And now, you have exactly the same level of security as Main Mode at the (small) expense of defining two new payloads, without additional cryptography *at all* (not even certs of birth). Correct me if I am wrong, it is a status quo for IKE (level of protection) but it fixes the missing phase 2 SA issue. frederic > - Bill From owner-ipsec@lists.tislabs.com Wed Jan 17 19:38:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA15068; Wed, 17 Jan 2001 19:38:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA01680 Wed, 17 Jan 2001 21:16:42 -0500 (EST) Message-Id: <200101180218.f0I2IU5107256@thunk.east.sun.com> From: Bill Sommerfeld To: "sankar ramamoorthi" cc: fd@cisco.com, sommerfeld@East.Sun.COM, "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol In-reply-to: Your message of "Wed, 17 Jan 2001 16:48:06 PST." Reply-to: sommerfeld@East.Sun.COM Date: Wed, 17 Jan 2001 21:18:29 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > 1. Extending IKE (with new payloads etc) to what is basically an ipsec > problem seems to be an incorrect. > If ipsec state (ipsec-SA) is out of sync between two peers, it should be > dealt in ipsec. this is a weak argument; the primary reason for the existance of ike is to establish and destroy ipsec state. - Bill From owner-ipsec@lists.tislabs.com Wed Jan 17 23:11:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA24420; Wed, 17 Jan 2001 23:11:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA02103 Thu, 18 Jan 2001 00:23:13 -0500 (EST) From: "sankar ramamoorthi" To: Cc: , "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Wed, 17 Jan 2001 21:19:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200101180218.f0I2IU5107256@thunk.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, the primary reason for the existance of ike is to establish and destroy ipsec state, but not vice-versa ie: ipsec state can exist independent of ike state once established. Also ipsec sa can be created independent of IKE (manual sa). We have had a number of arguments in the past about dangling ipsec SAs and the general consensus was that ipsec-sa can exist independent of ike-sa. IMHO, creating an ike-sa to handle ipsec state synchronization seems to avoid the real issue, which is the lack of an error mechanism for ipsec, similar to what ip has (ie: icmp). -- sankar -- -----Original Message----- From: sommerfeld@thunk.east.sun.com [mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld Sent: Wednesday, January 17, 2001 6:18 PM To: sankar ramamoorthi Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com Subject: Re: ipsec error protocol > 1. Extending IKE (with new payloads etc) to what is basically an ipsec > problem seems to be an incorrect. > If ipsec state (ipsec-SA) is out of sync between two peers, it should be > dealt in ipsec. this is a weak argument; the primary reason for the existance of ike is to establish and destroy ipsec state. - Bill From owner-ipsec@lists.tislabs.com Wed Jan 17 23:44:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA01773; Wed, 17 Jan 2001 23:44:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA02168 Thu, 18 Jan 2001 01:02:14 -0500 (EST) Message-ID: <3A66887F.C5756B0B@cisco.com> Date: Thu, 18 Jan 2001 07:09:03 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sankar ramamoorthi CC: sommerfeld@East.Sun.COM, "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Agree but let me reverse the argument: once IPSec has detected the problem, what can it do on its own ? Little but asking IKE to fix it... Notice that I see your point: you'd let IPSec delete the offending SA and the lack of SA on the sender side would trigger IKE as it exists today and the tunnels would be recreated. But as I was telling you: you had the choice of the transportation method and you chose a dedicated SA. But you do not tell us what to do with it... Now, if you think of it: IPSec *does* detect the problem (unknown SPI received). And it is simply asking IKE to do something about it. We just give IKE the possibility to do something without opening a DoS door. It is not very different than the usual case: IPSec misses an outbound SA and it asks IKE to fix it (and IKE negotiate SA's on the fly). Now, maybe we could start criticizing the exchange itself... and see if we can improve it or forget it. Is everyone filtering out threads on recovery mechanisms ? :) frederic sankar ramamoorthi wrote: > > Yes, the primary reason for the existance of ike is to establish and > destroy ipsec state, but not vice-versa ie: ipsec state can exist > independent of ike state once established. Also ipsec sa can be created > independent of IKE (manual sa). > > We have had a number of arguments in the past about dangling ipsec SAs > and the general consensus was that ipsec-sa can exist independent of ike-sa. > > IMHO, creating an ike-sa to handle ipsec state synchronization seems > to avoid the real issue, which is the lack of an error mechanism for ipsec, > similar to what ip has (ie: icmp). > > -- sankar -- > > -----Original Message----- > From: sommerfeld@thunk.east.sun.com > [mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld > Sent: Wednesday, January 17, 2001 6:18 PM > To: sankar ramamoorthi > Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly; > ipsec@lists.tislabs.com > Subject: Re: ipsec error protocol > > > 1. Extending IKE (with new payloads etc) to what is basically an ipsec > > problem seems to be an incorrect. > > If ipsec state (ipsec-SA) is out of sync between two peers, it should > be > > dealt in ipsec. > > this is a weak argument; the primary reason for the existance of ike > is to establish and destroy ipsec state. > > - Bill -- ------------------------- * oOo * ------------------------- Frederic Detienne Cisco Systems Escalation Engineer Security & Network Services Tel 32 2 704 55 55 From owner-ipsec@lists.tislabs.com Thu Jan 18 00:26:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA06782; Thu, 18 Jan 2001 00:26:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA02277 Thu, 18 Jan 2001 01:49:57 -0500 (EST) From: "sankar ramamoorthi" To: Cc: , "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Wed, 17 Jan 2001 22:44:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3A66887F.C5756B0B@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually it works like this When a sending IPsec receives unknown spi error (let us say as an ipsec control packet using the reserved spi) it can do the following to ensure that is is a valid error message before asking IKE to recreate the SA check if the spi from the sender matches any of its ipsec sa. If not ignore the error message. send an encrypted ping command for the sa in question and send it using the ipsec control packet. The payload of the control packet contains an encrypted ping encapsualted by an ESP header with the SPI of the SA in question. If the original error message is genuine the peer will not be able to decrypt it and silenty drop the packet (similiar to icmp, control packets do not generate more control packets). The sender after a number of retries can assure itself that the SA has gone stale for good and request IKE to recreate the ipsec SA. On the other hand if the first error was a spurious one, the encrypted pings will be successfully decrypted by the receiver. The receiver will send the encrypted echo-replies in the ipsec control packet and the sender can now knows the SA is still valid. It can safely ignore the initial error message or go tracking the sender of the initial message. Thus DOS problem can be avoided. -- sankar -- -----Original Message----- From: goofy@cisco.com [mailto:goofy@cisco.com]On Behalf Of Frédéric Detienne Sent: Wednesday, January 17, 2001 10:09 PM To: sankar ramamoorthi Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com Subject: Re: ipsec error protocol Agree but let me reverse the argument: once IPSec has detected the problem, what can it do on its own ? Little but asking IKE to fix it... Notice that I see your point: you'd let IPSec delete the offending SA and the lack of SA on the sender side would trigger IKE as it exists today and the tunnels would be recreated. But as I was telling you: you had the choice of the transportation method and you chose a dedicated SA. But you do not tell us what to do with it... Now, if you think of it: IPSec *does* detect the problem (unknown SPI received). And it is simply asking IKE to do something about it. We just give IKE the possibility to do something without opening a DoS door. It is not very different than the usual case: IPSec misses an outbound SA and it asks IKE to fix it (and IKE negotiate SA's on the fly). Now, maybe we could start criticizing the exchange itself... and see if we can improve it or forget it. Is everyone filtering out threads on recovery mechanisms ? :) frederic sankar ramamoorthi wrote: > > Yes, the primary reason for the existance of ike is to establish and > destroy ipsec state, but not vice-versa ie: ipsec state can exist > independent of ike state once established. Also ipsec sa can be created > independent of IKE (manual sa). > > We have had a number of arguments in the past about dangling ipsec SAs > and the general consensus was that ipsec-sa can exist independent of ike-sa. > > IMHO, creating an ike-sa to handle ipsec state synchronization seems > to avoid the real issue, which is the lack of an error mechanism for ipsec, > similar to what ip has (ie: icmp). > > -- sankar -- > > -----Original Message----- > From: sommerfeld@thunk.east.sun.com > [mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld > Sent: Wednesday, January 17, 2001 6:18 PM > To: sankar ramamoorthi > Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly; > ipsec@lists.tislabs.com > Subject: Re: ipsec error protocol > > > 1. Extending IKE (with new payloads etc) to what is basically an ipsec > > problem seems to be an incorrect. > > If ipsec state (ipsec-SA) is out of sync between two peers, it should > be > > dealt in ipsec. > > this is a weak argument; the primary reason for the existance of ike > is to establish and destroy ipsec state. > > - Bill -- ------------------------- * oOo * ------------------------- Frederic Detienne Cisco Systems Escalation Engineer Security & Network Services Tel 32 2 704 55 55 From owner-ipsec@lists.tislabs.com Thu Jan 18 02:34:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA21493; Thu, 18 Jan 2001 02:34:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA02575 Thu, 18 Jan 2001 04:01:08 -0500 (EST) From: "sankar ramamoorthi" To: "sankar ramamoorthi" , Cc: , "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Thu, 18 Jan 2001 00:59:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, When describing DOS prevention, I assumed that is okay to incur a symmetric encryption overhead. If that is not acceptable secure state-synchronization can occur in the following manner On the station receiving the 'invalid spi' error check if spi from the sender matches any of its ipsec sa. If not ignore the error message (This should take care some attacks where the sender is not aware of any currently active spi) send a clear ping command - send it using the ipsec control packet. The payload of the control contains a ping request and the spi in queston. The receiver on receiving the echo request, will reply with an echo-reply if the spi specified in the ping-request packet is still valid. If ping-reply is not received even after a few retries assume that the 'invalid spi' error was bogus (This should take care of passive attacks) This step is of questionable usefulness from DOS prevention point of view, but can help assure both the parties that the ipsec-sa parameters in both sides are in sync and encryption/decryption is working fine. send an encrypted ping command for the sa in question and send it using the ipsec control packet. The payload of the control packet contains an encrypted ping encapsualted by an ESP header with the SPI of the SA in question. If the original error message is genuine the peer will not be able to decrypt it and will silenty drop the packet (similiar to icmp, control packets do not generate more control packets). The sender after a number of retries can assure itself that the SA has gone stale for good and request IKE to recreate the ipsec SA. Note: At this point it is still possible for an active attacker intercepting the packets to make the sender unnecessarily send an encrypted ping and there by incur encryption overhead or restart an IKE exchange by grounding the encrypted pings (If someone is able to do this level of damage, they can also ground the IKE packets or data traffic). On the other hand if the first error was a spurious one, the encrypted pings will be successfully decrypted by the receiver. The receiver will send the encrypted echo-replies in the ipsec control packet and the sender can now knows the SA is still valid and encryption/decryption/authentication are working fine. It can safely ignore the initial error message or go tracking the sender of the initial message. Thus we can do ipsec state synchronization while proofing it against attacks from passive attacker. Welcome your comments, -- sankar -- -----Original Message----- From: sankar ramamoorthi [mailto:sankar@nexsi.com] Sent: Wednesday, January 17, 2001 10:45 PM To: fd@cisco.com Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com Subject: RE: ipsec error protocol Actually it works like this When a sending IPsec receives unknown spi error (let us say as an ipsec control packet using the reserved spi) it can do the following to ensure that is is a valid error message before asking IKE to recreate the SA check if the spi from the sender matches any of its ipsec sa. If not ignore the error message. send an encrypted ping command for the sa in question and send it using the ipsec control packet. The payload of the control packet contains an encrypted ping encapsualted by an ESP header with the SPI of the SA in question. If the original error message is genuine the peer will not be able to decrypt it and silenty drop the packet (similiar to icmp, control packets do not generate more control packets). The sender after a number of retries can assure itself that the SA has gone stale for good and request IKE to recreate the ipsec SA. On the other hand if the first error was a spurious one, the encrypted pings will be successfully decrypted by the receiver. The receiver will send the encrypted echo-replies in the ipsec control packet and the sender can now knows the SA is still valid. It can safely ignore the initial error message or go tracking the sender of the initial message. Thus DOS problem can be avoided. -- sankar -- -----Original Message----- From: goofy@cisco.com [mailto:goofy@cisco.com]On Behalf Of Frédéric Detienne Sent: Wednesday, January 17, 2001 10:09 PM To: sankar ramamoorthi Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com Subject: Re: ipsec error protocol Agree but let me reverse the argument: once IPSec has detected the problem, what can it do on its own ? Little but asking IKE to fix it... Notice that I see your point: you'd let IPSec delete the offending SA and the lack of SA on the sender side would trigger IKE as it exists today and the tunnels would be recreated. But as I was telling you: you had the choice of the transportation method and you chose a dedicated SA. But you do not tell us what to do with it... Now, if you think of it: IPSec *does* detect the problem (unknown SPI received). And it is simply asking IKE to do something about it. We just give IKE the possibility to do something without opening a DoS door. It is not very different than the usual case: IPSec misses an outbound SA and it asks IKE to fix it (and IKE negotiate SA's on the fly). Now, maybe we could start criticizing the exchange itself... and see if we can improve it or forget it. Is everyone filtering out threads on recovery mechanisms ? :) frederic sankar ramamoorthi wrote: > > Yes, the primary reason for the existance of ike is to establish and > destroy ipsec state, but not vice-versa ie: ipsec state can exist > independent of ike state once established. Also ipsec sa can be created > independent of IKE (manual sa). > > We have had a number of arguments in the past about dangling ipsec SAs > and the general consensus was that ipsec-sa can exist independent of ike-sa. > > IMHO, creating an ike-sa to handle ipsec state synchronization seems > to avoid the real issue, which is the lack of an error mechanism for ipsec, > similar to what ip has (ie: icmp). > > -- sankar -- > > -----Original Message----- > From: sommerfeld@thunk.east.sun.com > [mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld > Sent: Wednesday, January 17, 2001 6:18 PM > To: sankar ramamoorthi > Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly; > ipsec@lists.tislabs.com > Subject: Re: ipsec error protocol > > > 1. Extending IKE (with new payloads etc) to what is basically an ipsec > > problem seems to be an incorrect. > > If ipsec state (ipsec-SA) is out of sync between two peers, it should > be > > dealt in ipsec. > > this is a weak argument; the primary reason for the existance of ike > is to establish and destroy ipsec state. > > - Bill -- ------------------------- * oOo * ------------------------- Frederic Detienne Cisco Systems Escalation Engineer Security & Network Services Tel 32 2 704 55 55 From owner-ipsec@lists.tislabs.com Thu Jan 18 02:35:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA21520; Thu, 18 Jan 2001 02:35:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA02581 Thu, 18 Jan 2001 04:01:51 -0500 (EST) From: "sankar ramamoorthi" To: Cc: , "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Thu, 18 Jan 2001 01:00:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: sankar ramamoorthi [mailto:sankar@nexsi.com] Sent: Thursday, January 18, 2001 1:00 AM To: sankar ramamoorthi; fd@cisco.com Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com Subject: RE: ipsec error protocol Hi, When describing DOS prevention, I assumed that is okay to incur a symmetric encryption overhead. If that is not acceptable secure state-synchronization can occur in the following manner On the station receiving the 'invalid spi' error check if spi from the sender matches any of its ipsec sa. If not ignore the error message (This should take care some attacks where the sender is not aware of any currently active spi) send a clear ping command - send it using the ipsec control packet. The payload of the control contains a ping request and the spi in queston. The receiver on receiving the echo request, will reply with an echo-reply if the spi specified in the ping-request packet is still valid. If ping-reply is not received even after a few retries assume that the 'invalid spi' error was bogus (This should take care of passive attacks) This step is of questionable usefulness from DOS prevention point of view, but can help assure both the parties that the ipsec-sa parameters in both sides are in sync and encryption/decryption is working fine. send an encrypted ping command for the sa in question and send it using the ipsec control packet. The payload of the control packet contains an encrypted ping encapsualted by an ESP header with the SPI of the SA in question. If the original error message is genuine the peer will not be able to decrypt it and will silenty drop the packet (similiar to icmp, control packets do not generate more control packets). The sender after a number of retries can assure itself that the SA has gone stale for good and request IKE to recreate the ipsec SA. Note: At this point it is still possible for an active attacker intercepting the packets to make the sender unnecessarily send an encrypted ping and there by incur encryption overhead or restart an IKE exchange by grounding the encrypted pings (If someone is able to do this level of damage, they can also ground the IKE packets or data traffic). On the other hand if the first error was a spurious one, the encrypted pings will be successfully decrypted by the receiver. The receiver will send the encrypted echo-replies in the ipsec control packet and the sender can now knows the SA is still valid and encryption/decryption/authentication are working fine. It can safely ignore the initial error message or go tracking the sender of the initial message. Thus we can do ipsec state synchronization while proofing it against attacks from passive attacker. Welcome your comments, -- sankar -- -----Original Message----- From: sankar ramamoorthi [mailto:sankar@nexsi.com] Sent: Wednesday, January 17, 2001 10:45 PM To: fd@cisco.com Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com Subject: RE: ipsec error protocol Actually it works like this When a sending IPsec receives unknown spi error (let us say as an ipsec control packet using the reserved spi) it can do the following to ensure that is is a valid error message before asking IKE to recreate the SA check if the spi from the sender matches any of its ipsec sa. If not ignore the error message. send an encrypted ping command for the sa in question and send it using the ipsec control packet. The payload of the control packet contains an encrypted ping encapsualted by an ESP header with the SPI of the SA in question. If the original error message is genuine the peer will not be able to decrypt it and silenty drop the packet (similiar to icmp, control packets do not generate more control packets). The sender after a number of retries can assure itself that the SA has gone stale for good and request IKE to recreate the ipsec SA. On the other hand if the first error was a spurious one, the encrypted pings will be successfully decrypted by the receiver. The receiver will send the encrypted echo-replies in the ipsec control packet and the sender can now knows the SA is still valid. It can safely ignore the initial error message or go tracking the sender of the initial message. Thus DOS problem can be avoided. -- sankar -- -----Original Message----- From: goofy@cisco.com [mailto:goofy@cisco.com]On Behalf Of Frédéric Detienne Sent: Wednesday, January 17, 2001 10:09 PM To: sankar ramamoorthi Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com Subject: Re: ipsec error protocol Agree but let me reverse the argument: once IPSec has detected the problem, what can it do on its own ? Little but asking IKE to fix it... Notice that I see your point: you'd let IPSec delete the offending SA and the lack of SA on the sender side would trigger IKE as it exists today and the tunnels would be recreated. But as I was telling you: you had the choice of the transportation method and you chose a dedicated SA. But you do not tell us what to do with it... Now, if you think of it: IPSec *does* detect the problem (unknown SPI received). And it is simply asking IKE to do something about it. We just give IKE the possibility to do something without opening a DoS door. It is not very different than the usual case: IPSec misses an outbound SA and it asks IKE to fix it (and IKE negotiate SA's on the fly). Now, maybe we could start criticizing the exchange itself... and see if we can improve it or forget it. Is everyone filtering out threads on recovery mechanisms ? :) frederic sankar ramamoorthi wrote: > > Yes, the primary reason for the existance of ike is to establish and > destroy ipsec state, but not vice-versa ie: ipsec state can exist > independent of ike state once established. Also ipsec sa can be created > independent of IKE (manual sa). > > We have had a number of arguments in the past about dangling ipsec SAs > and the general consensus was that ipsec-sa can exist independent of ike-sa. > > IMHO, creating an ike-sa to handle ipsec state synchronization seems > to avoid the real issue, which is the lack of an error mechanism for ipsec, > similar to what ip has (ie: icmp). > > -- sankar -- > > -----Original Message----- > From: sommerfeld@thunk.east.sun.com > [mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld > Sent: Wednesday, January 17, 2001 6:18 PM > To: sankar ramamoorthi > Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly; > ipsec@lists.tislabs.com > Subject: Re: ipsec error protocol > > > 1. Extending IKE (with new payloads etc) to what is basically an ipsec > > problem seems to be an incorrect. > > If ipsec state (ipsec-SA) is out of sync between two peers, it should > be > > dealt in ipsec. > > this is a weak argument; the primary reason for the existance of ike > is to establish and destroy ipsec state. > > - Bill -- ------------------------- * oOo * ------------------------- Frederic Detienne Cisco Systems Escalation Engineer Security & Network Services Tel 32 2 704 55 55 From owner-ipsec@lists.tislabs.com Thu Jan 18 08:26:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20849; Thu, 18 Jan 2001 08:26:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA03702 Thu, 18 Jan 2001 09:23:16 -0500 (EST) Message-ID: <3A66FCC7.3209D6A9@cisco.com> Date: Thu, 18 Jan 2001 15:25:11 +0100 From: Frederic Detienne Reply-To: fd@cisco.com Organization: Cisco Systems, Inc X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sankar ramamoorthi CC: sommerfeld@East.Sun.COM, "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So this is a keepalive mechanism. And I think we have seen a number of them already. But all keepalives have the same problems: they consume bandwidth and rely on timers (slow convergence). Acknowledgements are much more efficient in terms of bandwidth: the consume less than 1/2 bandwdith of keepalives (esp. in low traffic conditions). I prefer notifications but I admit notifications can be lost and are subject to rate limiting. So honestly, I'd still vote for a dual notification/acknowledgment system (with each piece configurable). NOT for any sort of keepalive mechanism; we have seen too many problems in the field. regards, frederic detienne sankar ramamoorthi wrote: > > Actually it works like this > > When a sending IPsec receives unknown spi error (let us say as > an ipsec control packet using the reserved spi) it can do the > following to ensure that is is a valid error message before asking > IKE to recreate the SA > > check if the spi from the sender matches any of its ipsec sa. > If not ignore the error message. > > send an encrypted ping command for the sa in question and send > it using the ipsec control packet. The payload of the control packet > contains an encrypted ping encapsualted by an ESP header with the SPI > of the SA in question. If the original error message > is genuine the peer will not be able to decrypt it and silenty > drop the packet (similiar to icmp, control packets do not generate > more control packets). The sender after a number of retries can > assure itself that the SA has gone stale for good and request IKE > to recreate the ipsec SA. > > On the other hand if the first error was a spurious one, the > encrypted pings will be successfully decrypted by the receiver. > The receiver will send the encrypted echo-replies in the ipsec control > packet and the sender can now knows the SA is still valid. > It can safely ignore the initial error message or go tracking > the sender of the initial message. > > Thus DOS problem can be avoided. > > -- sankar -- > > -----Original Message----- > From: goofy@cisco.com [mailto:goofy@cisco.com]On Behalf Of Frédéric > Detienne > Sent: Wednesday, January 17, 2001 10:09 PM > To: sankar ramamoorthi > Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com > Subject: Re: ipsec error protocol > > Agree but let me reverse the argument: once IPSec has detected the problem, > what can it do on its own ? Little but asking IKE to fix it... > > Notice that I see your point: you'd let IPSec delete the offending SA and > the lack of SA on the sender side would trigger IKE as it exists today and > the tunnels would be recreated. But as I was telling you: you had the choice > of the transportation method and you chose a dedicated SA. But you do not > tell us what to do with it... > > Now, if you think of it: IPSec *does* detect the problem (unknown SPI > received). And it is simply asking IKE to do something about it. We just > give IKE the possibility to do something without opening a DoS door. > > It is not very different than the usual case: IPSec misses an outbound SA > and it asks IKE to fix it (and IKE negotiate SA's on the fly). > > Now, maybe we could start criticizing the exchange itself... and see if we > can improve it or forget it. Is everyone filtering out threads on recovery > mechanisms ? :) > > frederic > > sankar ramamoorthi wrote: > > > > Yes, the primary reason for the existance of ike is to establish and > > destroy ipsec state, but not vice-versa ie: ipsec state can exist > > independent of ike state once established. Also ipsec sa can be created > > independent of IKE (manual sa). > > > > We have had a number of arguments in the past about dangling ipsec SAs > > and the general consensus was that ipsec-sa can exist independent of > ike-sa. > > > > IMHO, creating an ike-sa to handle ipsec state synchronization seems > > to avoid the real issue, which is the lack of an error mechanism for > ipsec, > > similar to what ip has (ie: icmp). > > > > -- sankar -- > > > > -----Original Message----- > > From: sommerfeld@thunk.east.sun.com > > [mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld > > Sent: Wednesday, January 17, 2001 6:18 PM > > To: sankar ramamoorthi > > Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly; > > ipsec@lists.tislabs.com > > Subject: Re: ipsec error protocol > > > > > 1. Extending IKE (with new payloads etc) to what is basically an ipsec > > > problem seems to be an incorrect. > > > If ipsec state (ipsec-SA) is out of sync between two peers, it should > > be > > > dealt in ipsec. > > > > this is a weak argument; the primary reason for the existance of ike > > is to establish and destroy ipsec state. > > > > - Bill From owner-ipsec@lists.tislabs.com Thu Jan 18 13:45:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08814; Thu, 18 Jan 2001 13:45:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05325 Thu, 18 Jan 2001 14:51:57 -0500 (EST) From: "sankar ramamoorthi" To: "Scott G. Kelly" , Cc: Subject: RE: ipsec error protocol Date: Thu, 18 Jan 2001 11:50:35 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A65F0D4.8D7F1FE0@redcreek.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, You point out the following drawbacks for the ipsec error/control mechanism 1) overhead of maintaining an additionals sa state 2) may reqired additional SA characterstic in DOI vs ike I would like to point out the proposed scheme does not require a phase2 SA or associated state maintaineance. It only requires that ipsec reserve an spi for control purposes. That SPI could be used to define an ipsec control packet encapsulation which can carry error/control information about the state of other ipsec SAs. Also the change is really specific to ipsec - in that sense it is not DOI specific. Welcome your comments. -- sankar -- -----Original Message----- From: Scott G. Kelly [mailto:skelly@redcreek.com] Sent: Wednesday, January 17, 2001 11:22 AM To: fd@cisco.com Cc: sankar ramamoorthi; ipsec@lists.tislabs.com Subject: Re: ipsec error protocol Hi Frederic, Frédéric Detienne wrote: > > In this case, you assume there is a phase 2 SA available and identified > by a reserved SPI. What if the host crashed ? It does not have a phase > 2, and would have to negotiate a new one, possibly involing a phase 1, > thus opening the door to clogging. But the crashed host is precisely what you are trying to detect, and in this case, you will need to set up at least one new ike SA anyway, so this is not persuasive. > This is just an other way to transport a delete notification or a > keepalive but has the same drawbacks as the solutions proposed so far. > > ISAKMP already proposes such a mechanism (notification payloads > -- except keepalives) but as they are unauthenticated, they can > not be trusted. Use of an explicit phase 2 SA for this has been suggested by at least 2 other wg participants, if I remember correctly. What are the benefits vs drawbacks of this when compared to an ike-based solution? Benefits: o allows you to eliminate the ike/stack interaction required of an ike-based mechanism o phase 2 control messages could be authenticated without changing ike Drawbacks: o overhead for maintaining additional SA state o may require definition of additional SA characteristic in DOI (ike vs control), although not strictly necessary I'm sure there are other entries in each list - I invite others to add to these lists. Scott From owner-ipsec@lists.tislabs.com Thu Jan 18 13:45:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08824; Thu, 18 Jan 2001 13:45:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05209 Thu, 18 Jan 2001 14:42:13 -0500 (EST) From: "sankar ramamoorthi" To: Cc: , "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Thu, 18 Jan 2001 11:40:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A66FCC7.3209D6A9@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can u help me understand how you came to the conclusion that the series of steps I described is a keepalive mechanism. There are no keepalive or acknowledgement packets till the sender receives an error notification at which it can choose to follow the series of steps outlined to ensure the error message it received is genuine and react to it appropriately. How is this a keepalive mechanism? -- sankar -- -----Original Message----- From: fdetienn@cisco.com [mailto:fdetienn@cisco.com]On Behalf Of Frederic Detienne Sent: Thursday, January 18, 2001 6:25 AM To: sankar ramamoorthi Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com Subject: Re: ipsec error protocol So this is a keepalive mechanism. And I think we have seen a number of them already. But all keepalives have the same problems: they consume bandwidth and rely on timers (slow convergence). Acknowledgements are much more efficient in terms of bandwidth: the consume less than 1/2 bandwdith of keepalives (esp. in low traffic conditions). I prefer notifications but I admit notifications can be lost and are subject to rate limiting. So honestly, I'd still vote for a dual notification/acknowledgment system (with each piece configurable). NOT for any sort of keepalive mechanism; we have seen too many problems in the field. regards, frederic detienne sankar ramamoorthi wrote: > > Actually it works like this > > When a sending IPsec receives unknown spi error (let us say as > an ipsec control packet using the reserved spi) it can do the > following to ensure that is is a valid error message before asking > IKE to recreate the SA > > check if the spi from the sender matches any of its ipsec sa. > If not ignore the error message. > > send an encrypted ping command for the sa in question and send > it using the ipsec control packet. The payload of the control packet > contains an encrypted ping encapsualted by an ESP header with the SPI > of the SA in question. If the original error message > is genuine the peer will not be able to decrypt it and silenty > drop the packet (similiar to icmp, control packets do not generate > more control packets). The sender after a number of retries can > assure itself that the SA has gone stale for good and request IKE > to recreate the ipsec SA. > > On the other hand if the first error was a spurious one, the > encrypted pings will be successfully decrypted by the receiver. > The receiver will send the encrypted echo-replies in the ipsec control > packet and the sender can now knows the SA is still valid. > It can safely ignore the initial error message or go tracking > the sender of the initial message. > > Thus DOS problem can be avoided. > > -- sankar -- > > -----Original Message----- > From: goofy@cisco.com [mailto:goofy@cisco.com]On Behalf Of Frédéric > Detienne > Sent: Wednesday, January 17, 2001 10:09 PM > To: sankar ramamoorthi > Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com > Subject: Re: ipsec error protocol > > Agree but let me reverse the argument: once IPSec has detected the problem, > what can it do on its own ? Little but asking IKE to fix it... > > Notice that I see your point: you'd let IPSec delete the offending SA and > the lack of SA on the sender side would trigger IKE as it exists today and > the tunnels would be recreated. But as I was telling you: you had the choice > of the transportation method and you chose a dedicated SA. But you do not > tell us what to do with it... > > Now, if you think of it: IPSec *does* detect the problem (unknown SPI > received). And it is simply asking IKE to do something about it. We just > give IKE the possibility to do something without opening a DoS door. > > It is not very different than the usual case: IPSec misses an outbound SA > and it asks IKE to fix it (and IKE negotiate SA's on the fly). > > Now, maybe we could start criticizing the exchange itself... and see if we > can improve it or forget it. Is everyone filtering out threads on recovery > mechanisms ? :) > > frederic > > sankar ramamoorthi wrote: > > > > Yes, the primary reason for the existance of ike is to establish and > > destroy ipsec state, but not vice-versa ie: ipsec state can exist > > independent of ike state once established. Also ipsec sa can be created > > independent of IKE (manual sa). > > > > We have had a number of arguments in the past about dangling ipsec SAs > > and the general consensus was that ipsec-sa can exist independent of > ike-sa. > > > > IMHO, creating an ike-sa to handle ipsec state synchronization seems > > to avoid the real issue, which is the lack of an error mechanism for > ipsec, > > similar to what ip has (ie: icmp). > > > > -- sankar -- > > > > -----Original Message----- > > From: sommerfeld@thunk.east.sun.com > > [mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld > > Sent: Wednesday, January 17, 2001 6:18 PM > > To: sankar ramamoorthi > > Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly; > > ipsec@lists.tislabs.com > > Subject: Re: ipsec error protocol > > > > > 1. Extending IKE (with new payloads etc) to what is basically an ipsec > > > problem seems to be an incorrect. > > > If ipsec state (ipsec-SA) is out of sync between two peers, it should > > be > > > dealt in ipsec. > > > > this is a weak argument; the primary reason for the existance of ike > > is to establish and destroy ipsec state. > > > > - Bill From owner-ipsec@lists.tislabs.com Thu Jan 18 14:13:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09763; Thu, 18 Jan 2001 14:13:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05731 Thu, 18 Jan 2001 15:35:55 -0500 (EST) Message-ID: <3A675418.3B0ACEF6@cisco.com> Date: Thu, 18 Jan 2001 21:37:44 +0100 From: Frederic Detienne Reply-To: fd@cisco.com Organization: Cisco Systems, Inc X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sankar ramamoorthi CC: sommerfeld@East.Sun.COM, "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk so much my reading. sorry, I have been too quick. Now, rereading, I still have a few remarks: . you use a special SPI to carry the packet but you also have to carry the SPI being probed *in the clear* in the packet (so the remote side can possibly respond). Which means the packet also has to be authenticated (or the SPI could be tampered with). You then have to assume the SA you probe has keys for encrypting and authenticating while in practice, it could be an AH related SA or ESP with encryption only (solution ?) . you need 3 packets and a number of timeouts before deleting the SA and only restarting some IKE negotiation (slow) . you still can not decide if you restart just a phase 2 or also a phase 1 (e.g. If the phase 2 SA was administratively deleted on one host and the notification lost, we may still have a phase 1 available and phase 2 could be enough). . last but not least, because you force the IPSec stack to send a deterministic response in exchange of something known, you offer cribbles to the attacker. This is something that we never see appearing anywhere else in IPSec, I believe. I think you introduce a weakness in IPSec, in particular on the DATA session key (again, cryptographers...). (same in my case but I only weaken the phase 1 session key + the fact that IKE already offers *many* cribbles BUT (solution) you can protect the phase 2 session keys with PFS. You have no such solution). (and sorry again for having misread). regards, frederic sankar ramamoorthi wrote: > > Can u help me understand how you came to the conclusion that the series of > steps > I described is a keepalive mechanism. There are no keepalive or > acknowledgement > packets till the sender receives an error notification at which it can > choose > to follow the series of steps outlined to ensure the error message it > received > is genuine and react to it appropriately. How is this a keepalive mechanism? > > -- sankar -- > > -----Original Message----- > From: fdetienn@cisco.com [mailto:fdetienn@cisco.com]On Behalf Of > Frederic Detienne > Sent: Thursday, January 18, 2001 6:25 AM > To: sankar ramamoorthi > Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com > Subject: Re: ipsec error protocol > > So this is a keepalive mechanism. And I think we have seen a number of them > already. But all keepalives have the same problems: they consume bandwidth > and rely on timers (slow convergence). Acknowledgements are much more > efficient in terms of bandwidth: the consume less than 1/2 bandwdith of > keepalives (esp. in low traffic conditions). > > I prefer notifications but I admit notifications can be lost and are subject > to rate limiting. > > So honestly, I'd still vote for a dual notification/acknowledgment system > (with each piece configurable). NOT for any sort of keepalive mechanism; we > have seen too many problems in the field. > > regards, > > frederic detienne > > sankar ramamoorthi wrote: > > > > Actually it works like this > > > > When a sending IPsec receives unknown spi error (let us say as > > an ipsec control packet using the reserved spi) it can do the > > following to ensure that is is a valid error message before asking > > IKE to recreate the SA > > > > check if the spi from the sender matches any of its ipsec sa. > > If not ignore the error message. > > > > send an encrypted ping command for the sa in question and send > > it using the ipsec control packet. The payload of the control packet > > contains an encrypted ping encapsualted by an ESP header with the SPI > > of the SA in question. If the original error message > > is genuine the peer will not be able to decrypt it and silenty > > drop the packet (similiar to icmp, control packets do not generate > > more control packets). The sender after a number of retries can > > assure itself that the SA has gone stale for good and request IKE > > to recreate the ipsec SA. > > > > On the other hand if the first error was a spurious one, the > > encrypted pings will be successfully decrypted by the receiver. > > The receiver will send the encrypted echo-replies in the ipsec control > > packet and the sender can now knows the SA is still valid. > > It can safely ignore the initial error message or go tracking > > the sender of the initial message. > > > > Thus DOS problem can be avoided. > > > > -- sankar -- > > > > -----Original Message----- > > From: goofy@cisco.com [mailto:goofy@cisco.com]On Behalf Of Frédéric > > Detienne > > Sent: Wednesday, January 17, 2001 10:09 PM > > To: sankar ramamoorthi > > Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com > > Subject: Re: ipsec error protocol > > > > Agree but let me reverse the argument: once IPSec has detected the > problem, > > what can it do on its own ? Little but asking IKE to fix it... > > > > Notice that I see your point: you'd let IPSec delete the offending SA and > > the lack of SA on the sender side would trigger IKE as it exists today and > > the tunnels would be recreated. But as I was telling you: you had the > choice > > of the transportation method and you chose a dedicated SA. But you do not > > tell us what to do with it... > > > > Now, if you think of it: IPSec *does* detect the problem (unknown SPI > > received). And it is simply asking IKE to do something about it. We just > > give IKE the possibility to do something without opening a DoS door. > > > > It is not very different than the usual case: IPSec misses an outbound SA > > and it asks IKE to fix it (and IKE negotiate SA's on the fly). > > > > Now, maybe we could start criticizing the exchange itself... and see if we > > can improve it or forget it. Is everyone filtering out threads on recovery > > mechanisms ? :) > > > > frederic > > > > sankar ramamoorthi wrote: > > > > > > Yes, the primary reason for the existance of ike is to establish and > > > destroy ipsec state, but not vice-versa ie: ipsec state can exist > > > independent of ike state once established. Also ipsec sa can be created > > > independent of IKE (manual sa). > > > > > > We have had a number of arguments in the past about dangling ipsec SAs > > > and the general consensus was that ipsec-sa can exist independent of > > ike-sa. > > > > > > IMHO, creating an ike-sa to handle ipsec state synchronization seems > > > to avoid the real issue, which is the lack of an error mechanism for > > ipsec, > > > similar to what ip has (ie: icmp). > > > > > > -- sankar -- > > > > > > -----Original Message----- > > > From: sommerfeld@thunk.east.sun.com > > > [mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld > > > Sent: Wednesday, January 17, 2001 6:18 PM > > > To: sankar ramamoorthi > > > Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly; > > > ipsec@lists.tislabs.com > > > Subject: Re: ipsec error protocol > > > > > > > 1. Extending IKE (with new payloads etc) to what is basically an ipsec > > > > problem seems to be an incorrect. > > > > If ipsec state (ipsec-SA) is out of sync between two peers, it > should > > > be > > > > dealt in ipsec. > > > > > > this is a weak argument; the primary reason for the existance of ike > > > is to establish and destroy ipsec state. > > > > > > - Bill -- ------------------------- * oOo * ------------------------- Frederic Detienne Cisco Systems Escalation Engineer Security & Network Services Tel 32 2 704 55 55 From owner-ipsec@lists.tislabs.com Thu Jan 18 18:12:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA19941; Thu, 18 Jan 2001 18:12:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06575 Thu, 18 Jan 2001 19:22:08 -0500 (EST) From: "sankar ramamoorthi" To: Cc: , "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Thu, 18 Jan 2001 16:20:07 -0800 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: <3A675418.3B0ACEF6@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: fdetienn@cisco.com on behalf of Frederic Detienne [fd@cisco.com] >Sent: Thursday, January 18, 2001 12:38 PM >To: sankar ramamoorthi >Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >so much my reading. sorry, I have been too quick. > >Now, rereading, I still have a few remarks: > >. you use a special SPI to carry the packet but you also have to carry the SPI being probed *in the clear* in the packet (so the remote side can possibly respond). Which means the packet also has to be authenticated (or the SPI could be tampered with). You then have to assume the SA you probe has keys for encrypting and authenticating while in practice, it could be an AH related SA or ESP with encryption only (solution ?) Yes the SPI being probed will be in the clear. It will be part of the ESP header protecting the probe packet (which is encapsulated in the control packet identified by the reserved spi). Yes - if the receiver of the probe wants to respond, it should have a corresponding SA for authenticating and decrypting the request, encrypting and authenticating the reply. The SA being probed can be AH or ESP or ESP with authentication or any such combination(we just have to define the probe packets for the different types). > >. you need 3 packets and a number of timeouts before deleting the SA and only restarting some IKE negotiation (slow) Yes - that is true. Since it happens only when states go out-of-sync I do not think it is a big issue. If it happens during a DOS, the probes describes should be able to take care of most DOS attacks > >. you still can not decide if you restart just a phase 2 or also a phase 1 (e.g. If the phase 2 SA was administratively deleted on one host and the notification lost, we may still have a phase 1 available and phase 2 could be enough). Isn't acknowledged deletes one of the new features of son-of-ike document? In any case if the sender detects that ipsec SA has gone out of sync, it decides to restart phase2 SA, if phase2 SA times out, restarts phase1 SA. > >. last but not least, because you force the IPSec stack to send a deterministic response in exchange of something known, you offer cribbles to the attacker. This is something that we never see appearing anywhere else in IPSec, I believe. I think you introduce a weakness in IPSec, in particular on the DATA session key (again, cryptographers...). Yes - we are asking ipsec to send a deterministic error when it does not have an SA with a matching spi. How does it open up ipsec attack? The spi is already in the clear. The only additional thing now available to the hacker sniffing on the wire is the knowledge that a receiver does not have the matching spi. How does it help the hacker? He already is able to find out all the valid spis to the receiver. > >(same in my case but I only weaken the phase 1 session key + the fact that IKE already offers *many* cribbles BUT (solution) you can protect the phase 2 session keys with PFS. You have no such solution). > > Can u expand on this point? The probes we discussed do not include creation of the phase 2 session key. It is left to the sender to decide whether to use IKE to recreate phase2 SA (with or without PFS)? The probes only help to identify ipsec-sa has gone out of sync in a secure way. > >(and sorry again for having misread). > No problem >regards, > > frederic > > -- sankar -- From owner-ipsec@lists.tislabs.com Fri Jan 19 15:33:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07291; Fri, 19 Jan 2001 15:32:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10525 Fri, 19 Jan 2001 16:33:03 -0500 (EST) Message-ID: From: "Bagasrawala, Abbas" To: "'Henry Spencer'" , Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range Date: Fri, 19 Jan 2001 16:27:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lucent (Springtide) has reserved the SPI range from 256-4096 (non-inclusive for no reasons) SPI value for manual SA's. Our SPI rekeying algorithm will never generate SPI within that range. Abbas Bagasra -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Monday, January 15, 2001 11:33 PM To: Brian Swander Cc: ipsec@lists.tislabs.com Subject: Re: Manual SA SPI range On Mon, 15 Jan 2001, Brian Swander wrote: > Does anyone know if there is a hard specification in any of the RFCs > that nails down ranges for manual SA SPIs? There isn't. SPIs below 256 are reserved for special purposes (only one of them is currently assigned: 0 is reserved for system internal use and may never appear in a packet), but there is no explicit assignment for manual keying. The Linux FreeS/WAN project has decided to reserve all three-digit hex numbers, i.e. 0x100 through 0xfff, for manual keying (one-digit and two-digit hex numbers being the special-purposes area), and its automatic keying will never generate those. At the moment, I don't know of anybody else who has copied this. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Jan 19 15:55:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07583; Fri, 19 Jan 2001 15:55:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10738 Fri, 19 Jan 2001 17:29:47 -0500 (EST) From: Black_David@emc.com Message-ID: <0F31E5C394DAD311B60C00E029101A0704101459@corpmx9.isus.emc.com> To: ipsec@lists.tislabs.com Subject: FW: [Tsvwg] Last Call: The Addition of Explicit Congestion Notifi cation (ECN) to IP to Proposed Standard Date: Fri, 19 Jan 2001 17:31:49 -0500 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 This IETF last call may be of interest to ipsec WG members because the draft contains material from the "IPsec Interactions with ECN" draft (draft-ietf-ipsec-ecn-02.txt) that was recently approved for publication as an Informational RFC. Here's an explanation of what is happening (and has happened): - The ipsec WG presented the ipsec-ecn draft to the IESG for Proposed Standard last year. - The current ECN RFC (2481) is Experimental; the IESG determined that this made it inappropriate to approve the ipsec-ecn draft as a Proposed Standard. - The ECN co-authors (including yours truly) have combined all of the ECN material from RFC 2481, the ipsec-ecn draft, and a couple of other ECN drafts into a new draft, draft-ietf-tsvwg-ecn-01.txt . There were no significant changes to the IPsec-related material. The resulting draft is now in IETF Last Call for Proposed Standard, having passed Working Group Last Call in the Transport Area WG (tsvwg). I also wanted to note that this draft makes some small changes RFC 2401's procedures for tunnel encapsulation and decapsulation to avoid some nasty interactions between ECN and IPsec tunnels. The changes are limited to the two bits in the IP header used by ECN. Thanks, --David > -----Original Message----- > From: The IESG [SMTP:iesg-secretary@ietf.org] > Sent: Tuesday, January 16, 2001 1:06 PM > Cc: tsvwg@ietf.org > Subject: [Tsvwg] Last Call: The Addition of Explicit Congestion > Notification (ECN) to IP to Proposed Standard > > > The IESG has received a request from the Transport Area Working Group > Working Group to consider The Addition of Explicit Congestion > Notification (ECN) to IP as a Proposed > Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by January 29, 2001. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-01.txt > > > > > _______________________________________________ > tsvwg mailing list > tsvwg@ietf.org > http://www1.ietf.org/mailman/listinfo/tsvwg From owner-ipsec@lists.tislabs.com Fri Jan 19 15:55:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07608; Fri, 19 Jan 2001 15:55:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10689 Fri, 19 Jan 2001 17:24:56 -0500 (EST) Message-ID: <8894CA1F87A5D411BD24009027EE7838127FB4@md-exchange1.nai.com> From: "Mason, David" To: "'Bagasrawala, Abbas'" , "'Henry Spencer'" , Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range Date: Fri, 19 Jan 2001 14:24:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not sure why one would need to reserve SPIs for manual keys. The manual keys would be loaded on system startup and IKE would therefore never use them. Of course, there is the case where you might want to add a manual SA after system startup, but the chance that whatever SPI chosen is already in use would quite small (and the IKE negotiated SA that is using it, could be made to rekey upon load of the manual key, thereby freeing up that SPI). -dave -----Original Message----- From: Bagasrawala, Abbas [mailto:abagasrawala@lucent.com] Sent: Friday, January 19, 2001 4:28 PM To: 'Henry Spencer'; Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range Lucent (Springtide) has reserved the SPI range from 256-4096 (non-inclusive for no reasons) SPI value for manual SA's. Our SPI rekeying algorithm will never generate SPI within that range. Abbas Bagasra -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Monday, January 15, 2001 11:33 PM To: Brian Swander Cc: ipsec@lists.tislabs.com Subject: Re: Manual SA SPI range On Mon, 15 Jan 2001, Brian Swander wrote: > Does anyone know if there is a hard specification in any of the RFCs > that nails down ranges for manual SA SPIs? There isn't. SPIs below 256 are reserved for special purposes (only one of them is currently assigned: 0 is reserved for system internal use and may never appear in a packet), but there is no explicit assignment for manual keying. The Linux FreeS/WAN project has decided to reserve all three-digit hex numbers, i.e. 0x100 through 0xfff, for manual keying (one-digit and two-digit hex numbers being the special-purposes area), and its automatic keying will never generate those. At the moment, I don't know of anybody else who has copied this. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Jan 19 16:28:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08112; Fri, 19 Jan 2001 16:28:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10882 Fri, 19 Jan 2001 18:11:45 -0500 (EST) From: Dan McDonald Message-Id: <200101192313.f0JNDwP09853@kebe.Eng.Sun.COM> Subject: Connectathon notes (general + IPsec-specific) To: ipsec@lists.tislabs.com Date: Fri, 19 Jan 2001 15:13:57 -0800 (PST) CC: audrey@vanb.com Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello IPsec folks! First off, a word from Audrey, the C-thon boss... Hotel space is full at the Connectathon hotel. Connectathon registration will continue until Feb. 7th (3 weeks left!). For more information, please feel free to respond to me or see http://www.connectathon.org. Audrey Van Belleghem Event Manager Now, a word from me. People have been asking "what are you testing at Connectathon?" My answer had been the mealy-mouthed, "Whatever people bring". That doesn't help a lot of people, so I sorted things into some categories. So the list of C-thon IPsec technolgies this time 'round: IPsec Basics: AH: IPv4, IPv6 MD5-HMAC, SHA-1-HMAC, SHA-2-HMAC Tunnel, transport ESP: IPv4, IPv6 Same hashes as AH DES, 3DES, Blowfish, AES Tunnel, transport IKE Basics: MM: Pre-shared, RSA-sigs, RSA-enc., DSA-sigs, Mod. RSA-enc. Oakley groups 1-5 Same hashes/ciphers as AH and ESP INITIAL-CONTACT handling DELETE handling QM: QM PFS (Oakley groups 1-5) Inner IP tunnel negotiation (i.e. Phase 2 IDs != IP addrs of IKE traffic) For AH, ESP, and AH+ESP simultaneously AM: Same items as MM + QM, modulo PFS for IPsec SAs. Advanced IPsec: Per-application policy and discussion among OS vendors about application uses of IPsec. Advanced IKE: New Oakley groups. Single CA LDAP server? XAUTH? Things in question marks are thing that I don't have too much implementation experience, or just general lack of knowledge about. Things on the list will not necessarily be provided by every vendor in attendance, but they are things worth testing IMHO. We don't have suites the way other c-thon technologies do, but if you have any suites, feel free to bring them. (Unfortunately, the TAHI test suite folks won't be making it out this year.) So there it is! See you in March! Dan From owner-ipsec@lists.tislabs.com Mon Jan 22 07:37:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23085; Mon, 22 Jan 2001 07:37:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA17863 Mon, 22 Jan 2001 08:00:04 -0500 (EST) Message-ID: From: "Bagasrawala, Abbas" To: "'Mason, David'" , "Bagasrawala, Abbas" , "'Henry Spencer'" , Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range Date: Fri, 19 Jan 2001 17:44:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It depends on your implementation. If you maintain an internal database of SPI (which are currently used)then the system can always check user defined SPI against the database before accepting it. But then you run in to other problems and solving it depends on how much complexity you want - reserving SPI is one simple effective way. Abbas B -----Original Message----- From: Mason, David [mailto:David_Mason@NAI.com] Sent: Friday, January 19, 2001 5:24 PM To: 'Bagasrawala, Abbas'; 'Henry Spencer'; Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range I'm not sure why one would need to reserve SPIs for manual keys. The manual keys would be loaded on system startup and IKE would therefore never use them. Of course, there is the case where you might want to add a manual SA after system startup, but the chance that whatever SPI chosen is already in use would quite small (and the IKE negotiated SA that is using it, could be made to rekey upon load of the manual key, thereby freeing up that SPI). -dave -----Original Message----- From: Bagasrawala, Abbas [mailto:abagasrawala@lucent.com] Sent: Friday, January 19, 2001 4:28 PM To: 'Henry Spencer'; Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range Lucent (Springtide) has reserved the SPI range from 256-4096 (non-inclusive for no reasons) SPI value for manual SA's. Our SPI rekeying algorithm will never generate SPI within that range. Abbas Bagasra -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Monday, January 15, 2001 11:33 PM To: Brian Swander Cc: ipsec@lists.tislabs.com Subject: Re: Manual SA SPI range On Mon, 15 Jan 2001, Brian Swander wrote: > Does anyone know if there is a hard specification in any of the RFCs > that nails down ranges for manual SA SPIs? There isn't. SPIs below 256 are reserved for special purposes (only one of them is currently assigned: 0 is reserved for system internal use and may never appear in a packet), but there is no explicit assignment for manual keying. The Linux FreeS/WAN project has decided to reserve all three-digit hex numbers, i.e. 0x100 through 0xfff, for manual keying (one-digit and two-digit hex numbers being the special-purposes area), and its automatic keying will never generate those. At the moment, I don't know of anybody else who has copied this. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jan 22 08:12:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26327; Mon, 22 Jan 2001 08:12:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18248 Mon, 22 Jan 2001 09:23:58 -0500 (EST) Message-ID: From: "Costo, Avi" To: "'ipsec@lists.tislabs.com'" Cc: "Costo, Avi" Subject: Increased sequence number in ESP/AH Date: Mon, 22 Jan 2001 06:23:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I would like to ask about the proposal to increase the size of the sequence number field in ESP and AH headers to 64 or 128 bits. This was discussed in the last IETF conference in San Diego. * Is there any specific definition for updated ESP/AH structure? * ESP and AH headers currently does not include version number. - Does the preceding header will have new values for the headers? Or how this can be solved (specific SPIs?) Thanks, Avi Costo Network Communications Group Intel From owner-ipsec@lists.tislabs.com Mon Jan 22 08:37:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28010; Mon, 22 Jan 2001 08:37:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18343 Mon, 22 Jan 2001 09:49:27 -0500 (EST) Message-ID: <8894CA1F87A5D411BD24009027EE7838127FB7@md-exchange1.nai.com> From: "Mason, David" To: "'Bagasrawala, Abbas'" , "Mason, David" , "'Henry Spencer'" , Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range Date: Mon, 22 Jan 2001 06:48:40 -0800 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 If you don't maintain a database of currently used SPIs, how would IKE know what SPI to send in its proposals so that it doesn't use one that is currently being used (by a previous IKE negotiation - which easily boils down to manual SAs as well)? -dave -----Original Message----- From: Bagasrawala, Abbas [mailto:abagasrawala@lucent.com] Sent: Friday, January 19, 2001 5:44 PM To: 'Mason, David'; Bagasrawala, Abbas; 'Henry Spencer'; Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range It depends on your implementation. If you maintain an internal database of SPI (which are currently used)then the system can always check user defined SPI against the database before accepting it. But then you run in to other problems and solving it depends on how much complexity you want - reserving SPI is one simple effective way. Abbas B -----Original Message----- From: Mason, David [mailto:David_Mason@NAI.com] Sent: Friday, January 19, 2001 5:24 PM To: 'Bagasrawala, Abbas'; 'Henry Spencer'; Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range I'm not sure why one would need to reserve SPIs for manual keys. The manual keys would be loaded on system startup and IKE would therefore never use them. Of course, there is the case where you might want to add a manual SA after system startup, but the chance that whatever SPI chosen is already in use would quite small (and the IKE negotiated SA that is using it, could be made to rekey upon load of the manual key, thereby freeing up that SPI). -dave -----Original Message----- From: Bagasrawala, Abbas [mailto:abagasrawala@lucent.com] Sent: Friday, January 19, 2001 4:28 PM To: 'Henry Spencer'; Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range Lucent (Springtide) has reserved the SPI range from 256-4096 (non-inclusive for no reasons) SPI value for manual SA's. Our SPI rekeying algorithm will never generate SPI within that range. Abbas Bagasra -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Monday, January 15, 2001 11:33 PM To: Brian Swander Cc: ipsec@lists.tislabs.com Subject: Re: Manual SA SPI range On Mon, 15 Jan 2001, Brian Swander wrote: > Does anyone know if there is a hard specification in any of the RFCs > that nails down ranges for manual SA SPIs? There isn't. SPIs below 256 are reserved for special purposes (only one of them is currently assigned: 0 is reserved for system internal use and may never appear in a packet), but there is no explicit assignment for manual keying. The Linux FreeS/WAN project has decided to reserve all three-digit hex numbers, i.e. 0x100 through 0xfff, for manual keying (one-digit and two-digit hex numbers being the special-purposes area), and its automatic keying will never generate those. At the moment, I don't know of anybody else who has copied this. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jan 22 08:42:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28280; Mon, 22 Jan 2001 08:42:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18412 Mon, 22 Jan 2001 10:09:12 -0500 (EST) Message-ID: From: "Bagasrawala, Abbas" To: "'Mason, David'" , "'Henry Spencer'" , Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range Date: Mon, 22 Jan 2001 09:41:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It depends on your implementation. If you maintain an internal database of SPI (which are currently used)then the system can always check user defined SPI against the database before accepting it. But then you run in to other problems and solving it depends on how much complexity you want - reserving SPI is one simple effective way. Abbas B -----Original Message----- From: Mason, David [mailto:David_Mason@nai.com] Sent: Friday, January 19, 2001 5:24 PM To: 'Bagasrawala, Abbas'; 'Henry Spencer'; Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range I'm not sure why one would need to reserve SPIs for manual keys. The manual keys would be loaded on system startup and IKE would therefore never use them. Of course, there is the case where you might want to add a manual SA after system startup, but the chance that whatever SPI chosen is already in use would quite small (and the IKE negotiated SA that is using it, could be made to rekey upon load of the manual key, thereby freeing up that SPI). -dave -----Original Message----- From: Bagasrawala, Abbas [mailto:abagasrawala@lucent.com] Sent: Friday, January 19, 2001 4:28 PM To: 'Henry Spencer'; Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range Lucent (Springtide) has reserved the SPI range from 256-4096 (non-inclusive for no reasons) SPI value for manual SA's. Our SPI rekeying algorithm will never generate SPI within that range. Abbas Bagasra -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Monday, January 15, 2001 11:33 PM To: Brian Swander Cc: ipsec@lists.tislabs.com Subject: Re: Manual SA SPI range On Mon, 15 Jan 2001, Brian Swander wrote: > Does anyone know if there is a hard specification in any of the RFCs > that nails down ranges for manual SA SPIs? There isn't. SPIs below 256 are reserved for special purposes (only one of them is currently assigned: 0 is reserved for system internal use and may never appear in a packet), but there is no explicit assignment for manual keying. The Linux FreeS/WAN project has decided to reserve all three-digit hex numbers, i.e. 0x100 through 0xfff, for manual keying (one-digit and two-digit hex numbers being the special-purposes area), and its automatic keying will never generate those. At the moment, I don't know of anybody else who has copied this. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jan 22 09:22:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01566; Mon, 22 Jan 2001 09:22:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18565 Mon, 22 Jan 2001 10:42:03 -0500 (EST) Message-ID: <8894CA1F87A5D411BD24009027EE7838127FB8@md-exchange1.nai.com> From: "Mason, David" To: "'Bagasrawala, Abbas'" , "Mason, David" , "'Henry Spencer'" , Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range Date: Mon, 22 Jan 2001 07:41:15 -0800 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 If there is an easy way to avoid reserving numbers it should be considered since reserving numbers is always problematic (too large a reserve range and you're wasting space, too small a reserve range and there's an artificially imposed limit). -dave -----Original Message----- From: Bagasrawala, Abbas [mailto:abagasrawala@lucent.com] Sent: Monday, January 22, 2001 9:42 AM To: 'Mason, David'; 'Henry Spencer'; Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range It depends on your implementation. If you maintain an internal database of SPI (which are currently used)then the system can always check user defined SPI against the database before accepting it. But then you run in to other problems and solving it depends on how much complexity you want - reserving SPI is one simple effective way. Abbas B -----Original Message----- From: Mason, David [mailto:David_Mason@nai.com] Sent: Friday, January 19, 2001 5:24 PM To: 'Bagasrawala, Abbas'; 'Henry Spencer'; Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range I'm not sure why one would need to reserve SPIs for manual keys. The manual keys would be loaded on system startup and IKE would therefore never use them. Of course, there is the case where you might want to add a manual SA after system startup, but the chance that whatever SPI chosen is already in use would quite small (and the IKE negotiated SA that is using it, could be made to rekey upon load of the manual key, thereby freeing up that SPI). -dave -----Original Message----- From: Bagasrawala, Abbas [mailto:abagasrawala@lucent.com] Sent: Friday, January 19, 2001 4:28 PM To: 'Henry Spencer'; Brian Swander Cc: ipsec@lists.tislabs.com Subject: RE: Manual SA SPI range Lucent (Springtide) has reserved the SPI range from 256-4096 (non-inclusive for no reasons) SPI value for manual SA's. Our SPI rekeying algorithm will never generate SPI within that range. Abbas Bagasra -----Original Message----- From: Henry Spencer [mailto:henry@spsystems.net] Sent: Monday, January 15, 2001 11:33 PM To: Brian Swander Cc: ipsec@lists.tislabs.com Subject: Re: Manual SA SPI range On Mon, 15 Jan 2001, Brian Swander wrote: > Does anyone know if there is a hard specification in any of the RFCs > that nails down ranges for manual SA SPIs? There isn't. SPIs below 256 are reserved for special purposes (only one of them is currently assigned: 0 is reserved for system internal use and may never appear in a packet), but there is no explicit assignment for manual keying. The Linux FreeS/WAN project has decided to reserve all three-digit hex numbers, i.e. 0x100 through 0xfff, for manual keying (one-digit and two-digit hex numbers being the special-purposes area), and its automatic keying will never generate those. At the moment, I don't know of anybody else who has copied this. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jan 22 10:55:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07563; Mon, 22 Jan 2001 10:55:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18891 Mon, 22 Jan 2001 11:59:16 -0500 (EST) Message-ID: <3A6C6871.997B680C@cisco.com> Date: Mon, 22 Jan 2001 18:05:53 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sankar ramamoorthi CC: sommerfeld@East.Sun.COM, "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Sankar, FD>>. you need 3 packets and a number of timeouts before deleting the SA and FD>> only restarting some IKE negotiation (slow) SR> Yes - that is true. Since it happens only when states go out-of-sync SR> I do not think it is a big issue. If it happens during a DOS, the SR> probes describes should be able to take care of most DOS attacks Exactly not. In a DoS attack, the probing party may have to maintain a large number of timers (say this is a hub with a few thousands remote spokes connected to it; multiply the number of spokes by the number of outbound phase 2 SA's per host; now, flood the hub with spoofed invalid (but existing) SPI's from the spokes). FD>>. you still can not decide if you restart just a phase 2 or also a phase 1 FD>> (e.g. If the phase 2 SA was administratively deleted on one host and the FD>> notification lost, we may still have a phase 1 available and phase 2 could FD>> be enough). SR> Isn't acknowledged deletes one of the new features of son-of-ike document? and ? Even if you acknowledge the delete, what does that bring to you ? SR> In any case if the sender detects that ipsec SA has gone out of sync, SR> it decides to restart phase2 SA, if phase2 SA times out, restarts phase1 SR> SA. Exactly: additional delay. FD>> . last but not least, because you force the IPSec stack to send a FD>> deterministic response in exchange of something known, you offer cribbles to FD>> the attacker. This is something that we never see appearing anywhere else in FD>> IPSec, I believe. I think you introduce a weakness in IPSec, in particular FD>> on the DATA session key (again, cryptographers...). SR> Yes - we are asking ipsec to send a deterministic error when it does not SR> have SR> an SA with a matching spi. How does it open up ipsec attack? The spi is SR> already SR> in the clear. The only additional thing now available to the hacker sniffing SR> on the wire is the knowledge that a receiver does not have the matching spi. SR> How does it help the hacker? He already is able to find out all the valid SR> spis to the receiver. The clear text SPI is not really the problem here. Because we know the shape of the "echo request" (you will have to come up with a spec for this), an attacker will know what to attack (clear text attack). Say A and B share SA's. E is our evil attacker. E sends spoofed (B's source address) unauthenticated "invalid SPI" notifications to A. A responds with an "SPI echo-request" to B. The echo request is encrypted and has a known form. So E will now have a pair of clear and cypher text "echo-request" (in other words, a cribble) => leading to a possible clear text attack. If you noticed, the "next protocol" field in ESP is actually hidden in the encrypted portion. Because we do not know what is carried within this encrypted portion (not even the value of the "next protocol" field), a clear text attack can not be performed. FD>>(same in my case but I only weaken the phase 1 session key + the fact that FD>>IKE already offers *many* cribbles BUT (solution) you can protect the phase FD>>2 session keys with PFS. You have no such solution). SR> Can u expand on this point? The probes we discussed do not include SR> creation of the phase 2 session key. It is left to the sender to SR> decide whether to use IKE to recreate phase2 SA (with or without PFS)? SR> The probes only help to identify ipsec-sa has gone out of sync in a SR> secure way. I think you missed my point. What I mean is that there *are* cribbles in IKE (think of the well known shape of the packets in an exchange and the "next protocol" fields). I just add a few more things to the protocol but who cares since I do not make it worse ? In short: while I do *not* introduce anything (bad&new) in IKE, you *do* introduce something (bad&new) in IPSec. Now, I would also add: you said that I was relying on ISAKMP/IKE to recover and you prefer an all-IPSec based method. Well, think of your method: you send an unauthenticated IKE message to notify. You verify the notification with IPSec probes and finally, you let IKE restart in the worst possible way (slowly). Is that really what you wanted ? In the Detienne/Sommerfeld method, you notify and restart the negotiation at once (no IPSec<->IKE pingpong), almost immediately (no wasted packets, no timers), at a stage that is the most efficient in all the cases (phase 1 first or directly with phase 2) and with a fraction (at worse 1/2) of the timers required in your method. Sorry but until someone attacks our method, I find it much faster, safer and more homogeneous. And btw, I have not received any technical comment on this yet... still waiting. Anyone ? Finally, let me repeat that I would consider a (our) notification/renegotiation method in conjunction with an acknowledgement based method embedded within IPSec (can be done without cribbles). The main reason is that we need to rate limit the notifications (in ALL methods, not only our). So it is still possible that we do not recover easily in a case of DoS/true error pair (i.e. a true recovery is needed AND we are under DoS at the same time). Regards, Frederic Detienne -- ------------------------- * oOo * ------------------------- Frederic Detienne Cisco Systems Escalation Engineer Security & Network Services Tel 32 2 704 55 55 From owner-ipsec@lists.tislabs.com Mon Jan 22 12:55:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA13526; Mon, 22 Jan 2001 12:55:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19345 Mon, 22 Jan 2001 13:51:23 -0500 (EST) From: "Scott G. Kelly" To: fd@cisco.com Cc: sankar ramamoorthi , sommerfeld@East.Sun.COM, ipsec@lists.tislabs.com Message-ID: <3A6C8163.F17C08F5@redcreek.com> Date: Mon, 22 Jan 2001 10:52:19 -0800 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: ipsec error protocol References: <3A6C6871.997B680C@cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Frederic, Frédéric Detienne wrote: > Sorry but until someone attacks our method, I find it much faster, safer > and more homogeneous. And btw, I have not received any technical comment > on this yet... still waiting. Anyone ? > The best way to get comprehensive comments is to write up a draft and submit it for target practice :-) Scott From owner-ipsec@lists.tislabs.com Mon Jan 22 15:53:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19591; Mon, 22 Jan 2001 15:53:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20147 Mon, 22 Jan 2001 17:08:37 -0500 (EST) Date: Mon, 22 Jan 2001 17:10:46 -0500 (EST) From: Henry Spencer To: IP Security List Subject: RE: Manual SA SPI range In-Reply-To: <8894CA1F87A5D411BD24009027EE7838127FB4@md-exchange1.nai.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 19 Jan 2001, Mason, David wrote: > I'm not sure why one would need to reserve SPIs for manual keys. The manual > keys would be loaded on system startup and IKE would therefore never use > them. Manual keying isn't necessarily confined to VPN-like applications, where connections are established at startup time and never changed thereafter. > ...the chance that whatever SPI chosen is already in > use would quite small (and the IKE negotiated SA that is using it, could be > made to rekey upon load of the manual key, thereby freeing up that SPI). However, the interactions involved may be awkward, and it looks simpler -- given that some users want to use manual keying but it's not something we want to put a lot of support work into -- to just reserve a small range as a manual-keying playpen. (This involves *no* extra code, since there is already a reserved range and this just expands it slightly.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jan 22 15:59:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA19695; Mon, 22 Jan 2001 15:59:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20210 Mon, 22 Jan 2001 17:37:26 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: , "'sankar ramamoorthi'" Cc: , Subject: RE: ipsec error protocol Date: Mon, 22 Jan 2001 17:36:44 -0500 Message-Id: <001d01c084c3$cd2e32e0$1e72788a@andrewk3.ca.alcatel.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: <3A6C6871.997B680C@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This issue seems to flood the list on a regular schedule and then go completely silent for awhile (and that is partly my fault). Seeing that none of the "new" proposals are really all that new, I hope everyone involved has at least gone back and re-read the discussion from the last few times around. My concern is that people keep advancing ideas that seem simple on the surface, but if you examine them closely you see hidden vulnerabilities or interoperability problems. Many of these are due to existing problems with IKE, but since we are not allowed to change IKE, we cannot ignore them. Some of my concerns: - Any mechanism which relies on invalid SPI notifies or acknowledged deletes will not interoperate with dangling SA implementations. - The use of birth certificates effectively requires continuous channel mode as well. (Or at least it requires you to remember a large portion of the information in the phase 1 SA, such as the peer's identity & public key.) - DoS prevention is the only real reason to have secure black hole detection, but a solution which sacrifices worst case performance for improved average case performance will be extremely vulnerable to a DoS attack. It appears to me that reaching consensus on this issue through discussion alone is less likely than a lasting Palistine-Israeli peace accord. Ultimately, the market will decide, and I fear that the market will give no weight to the issue of DoS avoidance. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Mon Jan 22 16:15:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20105; Mon, 22 Jan 2001 16:15:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA20289 Mon, 22 Jan 2001 17:51:27 -0500 (EST) Message-Id: <200101222254.f0MMs65120378@thunk.east.sun.com> From: Bill Sommerfeld To: andrew.krywaniuk@alcatel.com cc: fd@cisco.com, "'sankar ramamoorthi'" , sommerfeld@East.Sun.COM, ipsec@lists.tislabs.com Subject: Re: ipsec error protocol In-reply-to: Your message of "Mon, 22 Jan 2001 17:36:44 EST." <001d01c084c3$cd2e32e0$1e72788a@andrewk3.ca.alcatel.com> Reply-to: sommerfeld@East.Sun.COM Date: Mon, 22 Jan 2001 17:54:05 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > - The use of birth certificates effectively requires continuous channel mode > as well. (Or at least it requires you to remember a large portion of the > information in the phase 1 SA, such as the peer's identity & public > key.) If you don't remember the authenticated identity, sessions will be vulnerable to hijacking by a different principal at rekey time. - Bill From owner-ipsec@lists.tislabs.com Mon Jan 22 17:03:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22132; Mon, 22 Jan 2001 17:03:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20429 Mon, 22 Jan 2001 18:25:56 -0500 (EST) Message-ID: <3A6CC322.F1B477E1@cisco.com> Date: Tue, 23 Jan 2001 00:32:50 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Scott G. Kelly" , andrew.krywaniuk@alcatel.com CC: sankar ramamoorthi , sommerfeld@East.Sun.COM, ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: <3A6C6871.997B680C@cisco.com> <3A6C8163.F17C08F5@redcreek.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Scott, Andrew, List, Candid questions: a. Do I have to copy paste the whole ISAKMP and IKE RFC's and add two new payloads + usage or can I define them in the draft only ? b. Andrew says "Many of these are due to existing problems with IKE, but since we are not allowed to change IKE, we cannot ignore them.". Sorry if I missed something previously but why are not we allowed to change IKE ? Thanks, fred "Scott G. Kelly" wrote: > > Hi Frederic, > > Frédéric Detienne wrote: > > > Sorry but until someone attacks our method, I find it much faster, safer > > and more homogeneous. And btw, I have not received any technical comment > > on this yet... still waiting. Anyone ? > > > > The best way to get comprehensive comments is to write up a draft and > submit it for target practice :-) > > Scott From owner-ipsec@lists.tislabs.com Mon Jan 22 17:03:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22131; Mon, 22 Jan 2001 17:03:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20476 Mon, 22 Jan 2001 18:35:59 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Cc: Subject: RE: ipsec error protocol Date: Mon, 22 Jan 2001 18:35:59 -0500 Message-Id: <002301c084cc$1469d990$1e72788a@andrewk3.ca.alcatel.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: <200101222254.f0MMs65120378@thunk.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > If you don't remember the authenticated identity, sessions will be > vulnerable to hijacking by a different principal at rekey time. True, although they wouldn't know the keys for any previously created SAs, so it wouldn't help them much. Personally, I don't think the memory savings of dangling phase 2s are worth the disadvantages. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. From owner-ipsec@lists.tislabs.com Mon Jan 22 17:12:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22282; Mon, 22 Jan 2001 17:12:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20564 Mon, 22 Jan 2001 18:57:16 -0500 (EST) From: "Scott G. Kelly" To: fd@cisco.com Cc: andrew.krywaniuk@alcatel.com, sankar ramamoorthi , sommerfeld@East.Sun.COM, ipsec@lists.tislabs.com Message-ID: <3A6CC91A.492D05EC@redcreek.com> Date: Mon, 22 Jan 2001 15:58:18 -0800 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: ipsec error protocol References: <3A6C6871.997B680C@cisco.com> <3A6C8163.F17C08F5@redcreek.com> <3A6CC322.F1B477E1@cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Fred, Frédéric Detienne wrote: > > Hi Scott, Andrew, List, > > Candid questions: > > a. Do I have to copy paste the whole ISAKMP and IKE RFC's and add > two new payloads + usage or can I define them in the draft only ? > I think you can make the draft brief, and just include the relevant payloads. The point is to communicate all the details of your proposal in one place so that everyone has the same basis for discussion. I wouldn't worry too much about form unless you get sufficient interest in your ideas to justify the work. > b. Andrew says "Many of these are due to existing problems with IKE, but since we are not allowed to change IKE, we cannot ignore them.". Sorry if I missed something previously but why are not we allowed to change IKE ? > There is son-of-ike work pending in the ipsec working group, so I'd say ike is going to undergo some sort of revision. I don't know if additional payloads for this functionality would be acceptable or not, but there is only one way to find out. I think what Andrew is referring to is that the ipsra group is supposed to favor remote access solution mechanisms which do not require ike modifications. Scott > Thanks, > > fred > > "Scott G. Kelly" wrote: > > > > Hi Frederic, > > > > Frédéric Detienne wrote: > > > > > Sorry but until someone attacks our method, I find it much faster, safer > > > and more homogeneous. And btw, I have not received any technical comment > > > on this yet... still waiting. Anyone ? > > > > > > > The best way to get comprehensive comments is to write up a draft and > > submit it for target practice :-) > > > > Scott From owner-ipsec@lists.tislabs.com Mon Jan 22 17:13:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22312; Mon, 22 Jan 2001 17:13:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20580 Mon, 22 Jan 2001 18:59:23 -0500 (EST) From: "sankar ramamoorthi" To: Cc: , "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Mon, 22 Jan 2001 15:57:13 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A6C6871.997B680C@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: goofy@cisco.com on behalf of Frédéric Detienne [fd@cisco.com] >Sent: Monday, January 22, 2001 9:06 AM >To: sankar ramamoorthi >Cc: sommerfeld@East.Sun.COM; Scott G. Kelly; ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >Hi Sankar, > >FD>>. you need 3 packets and a number of timeouts before deleting the SA and >FD>> only restarting some IKE negotiation (slow) >SR> Yes - that is true. Since it happens only when states go out-of-sync >SR> I do not think it is a big issue. If it happens during a DOS, the >SR> probes describes should be able to take care of most DOS attacks > >Exactly not. In a DoS attack, the probing party may have to maintain a large number of timers (say this is a hub with a few thousands remote spokes connected to it; multiply the number of spokes by the number of outbound phase 2 SA's per host; now, flood the hub with spoofed invalid (but existing) SPI's from the spokes). I see it more of an implementation issue. If an implemantion wants to scale large number of connections, it should be able to effectively deal (and many have dealt) with bookkeeping of large number of timers. How is the overhead of maintaining probe timers more than authenticating notifications? In fact if it is DOS, I would rather prefer the computation overhead of simple probing. >FD>>. you still can not decide if you restart just a phase 2 or also a phase 1 >FD>> (e.g. If the phase 2 SA was administratively deleted on one host and the >FD>> notification lost, we may still have a phase 1 available and phase 2 could >FD>> be enough). > >SR> Isn't acknowledged deletes one of the new features of son-of-ike document? > >and ? Even if you acknowledge the delete, what does that bring to you ? > >SR> In any case if the sender detects that ipsec SA has gone out of sync, >SR> it decides to restart phase2 SA, if phase2 SA times out, restarts phase1 >SR> SA. > >Exactly: additional delay. Additional delay only when the peers are out-of-sync or when there is DOS. In the DOS case both the probe and IKE packets could be wasted but atleast in the probe seems to be light weight compared to ike. In the out-of-sync case the sender would have to be make sure the notification is genuine before starting IKE. > > >FD>> . last but not least, because you force the IPSec stack to send a >FD>> deterministic response in exchange of something known, you offer cribbles to >FD>> the attacker. This is something that we never see appearing anywhere else in >FD>> IPSec, I believe. I think you introduce a weakness in IPSec, in particular >FD>> on the DATA session key (again, cryptographers...). > >SR> Yes - we are asking ipsec to send a deterministic error when it does not >SR> have >SR> an SA with a matching spi. How does it open up ipsec attack? The spi is >SR> already >SR> in the clear. The only additional thing now available to the hacker sniffing >SR> on the wire is the knowledge that a receiver does not have the matching spi. >SR> How does it help the hacker? He already is able to find out all the valid >SR> spis to the receiver. > >The clear text SPI is not really the problem here. > >Because we know the shape of the "echo request" (you will have to come up with a spec for this), an attacker will know what to attack (clear text attack). > >Say A and B share SA's. E is our evil attacker. E sends spoofed (B's source address) unauthenticated "invalid SPI" notifications to A. A responds with an "SPI echo-request" to B. The echo request is encrypted and has a known form. So E will now have a pair of clear and cypher text "echo-request" (in other words, a cribble) => leading to a possible clear text attack. As for the probe being a cribble, as you said the format has not been specified - There are many possiblities to avoid cribbles here. The probe has to be specified in such a way that replay attacks must not be possible - it means it will use the sequence numbers from the SA of interest. For all purposes the probe packet will be similiar to that of data packet through an ipsec SA except that it comes through the error packet and may be thrown away. Hence it will be as difficult/easy to crack as an ESP packet. In short, the probe offers no more information than a regular packet through the SA. > >If you noticed, the "next protocol" field in ESP is actually hidden in the encrypted portion. Because we do not know what is carried within this encrypted portion (not even the value of the "next protocol" field), a clear text attack can not be performed. > That still applies to the probe packet encapsulated inside the ipsec error packet > >FD>>(same in my case but I only weaken the phase 1 session key + the fact that >FD>>IKE already offers *many* cribbles BUT (solution) you can protect the phase >FD>>2 session keys with PFS. You have no such solution). > >SR> Can u expand on this point? The probes we discussed do not include >SR> creation of the phase 2 session key. It is left to the sender to >SR> decide whether to use IKE to recreate phase2 SA (with or without PFS)? >SR> The probes only help to identify ipsec-sa has gone out of sync in a >SR> secure way. > >I think you missed my point. What I mean is that there *are* cribbles in IKE (think of the well known shape of the packets in an exchange and the "next protocol" fields). I just add a few more things to the protocol but who cares since I do not make it worse ? As I said, it is possible to design encrypted probes purely with in the protection offered by ipsec without offering any cribbles to some attacker in the middle. >In short: while I do *not* introduce anything (bad&new) in IKE, you *do* introduce something (bad&new) in IPSec. > same here > >Now, I would also add: you said that I was relying on ISAKMP/IKE to recover and you prefer an all-IPSec based method. Well, think of your method: you send an unauthenticated IKE message to notify. You verify the notification with IPSec probes and finally, you let IKE restart in the worst possible way (slowly). Is that really what you wanted ? > Yes - all I am expecting from ipsec is a building block to deal with the out-of-sync ipsec endpoints. I am not looking for a complete solution since that solution is out of scope of ipsec. The solution also may vary depending on the need. Note: The unauthenticated notify need to be sent only when there is no existing phase1 SA to the peer ie: when there are no existing phase 1 SA with the peer. > >In the Detienne/Sommerfeld method, you notify and restart the negotiation at once (no IPSec<->IKE pingpong), almost immediately (no wasted packets, no timers), at a stage that is the most efficient in all the cases (phase 1 first or directly with phase 2) and with a fraction (at worse 1/2) of the timers required in your method. If I understand the proposal correctly it requires the sender of the message to remember some unique information known to each peer to get the 'invalid spi' notification authenticated. How can the sender remember this information across reboots? If that is not necessary, how is replay protection provided for the authenticated notify messages? Regards, -- sankar -- From owner-ipsec@lists.tislabs.com Mon Jan 22 18:56:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA23619; Mon, 22 Jan 2001 18:56:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA21029 Mon, 22 Jan 2001 20:27:21 -0500 (EST) From: "sankar ramamoorthi" To: , "Scott G. Kelly" , Cc: , Subject: RE: ipsec error protocol Date: Mon, 22 Jan 2001 17:24:08 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A6CC322.F1B477E1@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ignore this if it is a duplicate. Thanks, -- sankar -- >From: goofy@cisco.com on behalf of Frédéric Detienne [fd@cisco.com] >Sent: Monday, January 22, 2001 9:06 AM >To: sankar ramamoorthi >Cc: sommerfeld@East.Sun.COM; Scott G. Kelly; ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >Hi Sankar, > >FD>>. you need 3 packets and a number of timeouts before deleting the SA and >FD>> only restarting some IKE negotiation (slow) >SR> Yes - that is true. Since it happens only when states go out-of-sync >SR> I do not think it is a big issue. If it happens during a DOS, the >SR> probes describes should be able to take care of most DOS attacks > >Exactly not. In a DoS attack, the probing party may have to maintain a large number of timers (say this is a hub with a few thousands remote spokes connected to it; multiply the number of spokes by the number of outbound phase 2 SA's per host; now, flood the hub with spoofed invalid (but existing) SPI's from the spokes). I see it more of an implementation issue. If an implemantion wants to scale large number of connections, it should be able to effectively deal (and many have dealt) with bookkeeping of large number of timers. How is the overhead of maintaining probe timers more than authenticating notifications? In fact if it is DOS, I would rather prefer the computation overhead with simple probing. >FD>>. you still can not decide if you restart just a phase 2 or also a phase 1 >FD>> (e.g. If the phase 2 SA was administratively deleted on one host and the >FD>> notification lost, we may still have a phase 1 available and phase 2 could >FD>> be enough). > >SR> Isn't acknowledged deletes one of the new features of son-of-ike document? > >and ? Even if you acknowledge the delete, what does that bring to you ? > >SR> In any case if the sender detects that ipsec SA has gone out of sync, >SR> it decides to restart phase2 SA, if phase2 SA times out, restarts phase1 >SR> SA. > >Exactly: additional delay. Additional delay only when the peers are out-of-sync or when there is DOS. In the DOS case both the probe and IKE packets could be wasted but atleast in the probe seems to be light weight compared to ike. In the out-of-sync case the sender would have to be make sure the notification is genuine before starting IKE. > > >FD>> . last but not least, because you force the IPSec stack to send a >FD>> deterministic response in exchange of something known, you offer cribbles to >FD>> the attacker. This is something that we never see appearing anywhere else in >FD>> IPSec, I believe. I think you introduce a weakness in IPSec, in particular >FD>> on the DATA session key (again, cryptographers...). > >SR> Yes - we are asking ipsec to send a deterministic error when it does not >SR> have >SR> an SA with a matching spi. How does it open up ipsec attack? The spi is >SR> already >SR> in the clear. The only additional thing now available to the hacker sniffing >SR> on the wire is the knowledge that a receiver does not have the matching spi. >SR> How does it help the hacker? He already is able to find out all the valid >SR> spis to the receiver. > >The clear text SPI is not really the problem here. > >Because we know the shape of the "echo request" (you will have to come up with a spec for this), an attacker will know what to attack (clear text attack). > >Say A and B share SA's. E is our evil attacker. E sends spoofed (B's source address) unauthenticated "invalid SPI" notifications to A. A responds with an "SPI echo-request" to B. The echo request is encrypted and has a known form. So E will now have a pair of clear and cypher text "echo-request" (in other words, a cribble) => leading to a possible clear text attack. As for the probe being a cribble, as you said the format has not been specified - There are many possiblities to avoid cribbles here. The probe has to be specified in such a way that replay attacks must not be possible - it means it will use the sequence numbers from the SA of interest. For all purposes the probe packet will be similiar to that of data packet through an ipsec SA except that it comes through the error packet and is thrown away. Hence it will be as difficult/easy to crack as an ESP packet. In short, the probe offers no more information than a regular packet through the SA. > >If you noticed, the "next protocol" field in ESP is actually hidden in the encrypted portion. Because we do not know what is carried within this encrypted portion (not even the value of the "next protocol" field), a clear text attack can not be performed. > That still applies to the probe packet encapsulated inside the ipsec error packet > >FD>>(same in my case but I only weaken the phase 1 session key + the fact that >FD>>IKE already offers *many* cribbles BUT (solution) you can protect the phase >FD>>2 session keys with PFS. You have no such solution). > >SR> Can u expand on this point? The probes we discussed do not include >SR> creation of the phase 2 session key. It is left to the sender to >SR> decide whether to use IKE to recreate phase2 SA (with or without PFS)? >SR> The probes only help to identify ipsec-sa has gone out of sync in a >SR> secure way. > >I think you missed my point. What I mean is that there *are* cribbles in IKE (think of the well known shape of the packets in an exchange and the "next protocol" fields). I just add a few more things to the protocol but who cares since I do not make it worse ? As I said, it is possible to design encrypted probes purely with in the protection offered by ipsec without offering any cribbles to some attacker in the middle. >In short: while I do *not* introduce anything (bad&new) in IKE, you *do* introduce something (bad&new) in IPSec. > same here > >Now, I would also add: you said that I was relying on ISAKMP/IKE to recover and you prefer an all-IPSec based method. Well, think of your method: you send an unauthenticated IKE message to notify. You verify the notification with IPSec probes and finally, you let IKE restart in the worst possible way (slowly). Is that really what you wanted ? > Yes - all I am expecting from ipsec is a building block to deal with the out-of-sync ipsec endpoints. I am not looking for a complete solution since that solution is out of scope of ipsec. The solution also may vary depending on the need. Note: The unauthenticated notify need to be sent when there is no existing phase1 SA to the peer ie: when there are no phase 1 SAs with the peer. > >In the Detienne/Sommerfeld method, you notify and restart the negotiation at once (no IPSec<->IKE pingpong), almost immediately (no wasted packets, no timers), at a stage that is the most efficient in all the cases (phase 1 first or directly with phase 2) and with a fraction (at worse 1/2) of the timers required in your method. If I understand the proposal correctly it requires the sender of the message to remember some unique information known to each peer to get the 'invalid spi' notification authenticated. How can the sender remember this information across reboots> If that is not necessary, how is replay protection provided for the authenticated notify messages? Regards, -- sankar -- From owner-ipsec@lists.tislabs.com Mon Jan 22 20:33:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA25147; Mon, 22 Jan 2001 20:33:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21256 Mon, 22 Jan 2001 21:57:54 -0500 (EST) Message-Id: <200101230300.f0N30Y5120900@thunk.east.sun.com> From: Bill Sommerfeld To: "sankar ramamoorthi" cc: fd@cisco.com, sommerfeld@East.Sun.COM, "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol In-reply-to: Your message of "Mon, 22 Jan 2001 15:57:13 PST." Reply-to: sommerfeld@East.Sun.COM Date: Mon, 22 Jan 2001 22:00:33 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >In the Detienne/Sommerfeld method, you notify and restart the negotiation > at once (no IPSec<->IKE pingpong), almost immediately (no wasted packets, no > timers), at a stage that is the most efficient in all the cases (phase 1 > first or directly with phase 2) and with a fraction (at worse 1/2) of the > timers required in your method. > > If I understand the proposal correctly it requires the sender of the message > to remember some unique information known to each peer to get the > 'invalid spi' notification authenticated. How can the sender remember > this information across reboots? The message contains a signed sequence number; the "birth cert" sender need only keep a single sequence number, shared across all peers. Replay detection is simple. the "birth cert" receiver (SA sender) needs to hang on to the "current" birth cert for the lifetime of the sending side of the SA. (i.e., the sending end of the SA can throw it away when it throws away the SA state). If it receives a newer birth cert than the old one, it knows that the peer has rebooted and its SA state is stale. If it receives an older birth cert in an error message, it can trivially ignore it. There are other tricks you can use to engineer DoS resistance. (i.e., rate limit how often you'll attempt to validate a signature, skip the validation if you've recently received authentic traffic from the peer, etc., etc.) - Bill From owner-ipsec@lists.tislabs.com Mon Jan 22 21:53:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA26105; Mon, 22 Jan 2001 21:53:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA21465 Mon, 22 Jan 2001 23:12:24 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 22 Jan 2001 15:13:42 -0500 To: "Costo, Avi" From: Stephen Kent Subject: Re: Increased sequence number in ESP/AH Cc: "'ipsec@lists.tislabs.com'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Avi, >I would like to ask about the proposal to increase the size of the sequence >number field in ESP and AH headers to 64 or 128 bits. This was discussed in >the last IETF conference in San Diego. > > * Is there any specific definition for updated ESP/AH structure? > * ESP and AH headers currently does not include version number. > - Does the preceding header will have new values for the headers? >Or how this can be solved (specific SPIs?) My proposal calls for the extended sequence numbers to NOT occupy any more space in the ESP or AH headers. Instead, use of these numbers would be negotiated by IKE, so that interoperability would be maintained with systems that do not support the extended fields. No change would occur in the "on the wire" format, which avoids increasing overhead. Sender and receiver maintain larger (e.g., 64 bit) counters, but transmit only the low order 32 bits. A new receiver window algorithm is needed to deal with the transition that occurs every 2**32 packets, but there is no security ambiguity here, i.e., any packet that is < 2**32-1 by more than the receive window is treated like a packet from the next chunk of sequence space. Steve P.S. Since sequence numbers are not used for anti-replay for manually keyed SAs, not being able to negotiate this for non-IKE contexts does not seem to be a problem. Any other protocol that is used to negotiate SAs should be able to support this sort of negotiation. From owner-ipsec@lists.tislabs.com Mon Jan 22 21:53:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA26118; Mon, 22 Jan 2001 21:53:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA21458 Mon, 22 Jan 2001 23:12:11 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <0F31E5C394DAD311B60C00E029101A0704101459@corpmx9.isus.emc.com> References: <0F31E5C394DAD311B60C00E029101A0704101459@corpmx9.isus.emc.com> Date: Mon, 22 Jan 2001 14:59:07 -0500 To: Black_David@emc.com From: Stephen Kent Subject: Re: FW: [Tsvwg] Last Call: The Addition of Explicit Congestion Notifi cation (ECN) to IP to Proposed Standard Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, Thanks for the heads up. I'll review the document to make sure its consistent with planned changes to 2401, since we want that architecture document to be definitive. Steve From owner-ipsec@lists.tislabs.com Mon Jan 22 22:00:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA26210; Mon, 22 Jan 2001 22:00:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA21600 Mon, 22 Jan 2001 23:24:52 -0500 (EST) From: "sankar ramamoorthi" To: Cc: , "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Mon, 22 Jan 2001 20:17:54 -0800 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: <200101230300.f0N30Y5120900@thunk.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, comments inline >From: sommerfeld@thunk.east.sun.com on behalf of Bill Sommerfeld >[sommerfeld@east.sun.com] >Sent: Monday, January 22, 2001 7:01 PM >To: sankar ramamoorthi >Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly; >ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >> >In the Detienne/Sommerfeld method, you notify and restart the negotiation >> at once (no IPSec<->IKE pingpong), almost immediately (no wasted packets, no >> timers), at a stage that is the most efficient in all the cases (phase 1 >> first or directly with phase 2) and with a fraction (at worse 1/2) of the >> timers required in your method. >> >> If I understand the proposal correctly it requires the sender of the message >> to remember some unique information known to each peer to get the >> 'invalid spi' notification authenticated. How can the sender remember >> this information across reboots? > >The message contains a signed sequence number; the "birth cert" sender >need only keep a single sequence number, shared across all peers. > >Replay detection is simple. the "birth cert" receiver (SA sender) >needs to hang on to the "current" birth cert for the lifetime of the >sending side of the SA. (i.e., the sending end of the SA can throw it >away when it throws away the SA state). > >If it receives a newer birth cert than the old one, it knows that the >peer has rebooted and its SA state is stale. > >If it receives an older birth cert in an error message, it can >trivially ignore it. > Some comments on the scheme. Correct me if am I wrong in my understanding. This scheme depends upon the sequence number used in a birth cert to be continously incrasing across reboots. This may not always be possible. For example time (from which the sequence number may be derived) may be reset, configuration may be reset etc. In these cases information about the previous sequence number is lost. What if the private key that is used to sign the sequence number is lost? (may be nvram/flash needed to be reprogrammed for some reason) How does the birth cert owner recover from the situation? Does it have to create a new ike sa with every existing peer to update the birth cert information? What the ways to handle these operational problems? >There are other tricks you can use to engineer DoS resistance. (i.e., >rate limit how often you'll attempt to validate a signature, skip the >validation if you've recently received authentic traffic from the >peer, etc., etc.) > > - Bill -- sankar -- From owner-ipsec@lists.tislabs.com Tue Jan 23 02:30:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01133; Tue, 23 Jan 2001 02:30:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA22614 Tue, 23 Jan 2001 03:54:51 -0500 (EST) Message-ID: <3A6D3CB0.F0690533@cisco.com> Date: Tue, 23 Jan 2001 09:11:28 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sankar ramamoorthi CC: sommerfeld@East.Sun.COM, "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is much simpler. Suppose A and B have SA's in common. In the combined method, the reboot seq# is actually sent in the last 2 IKE packets. So they are implicitly signed when the whole exchange itself is signed. In short, all there is to remember is the boot seq# of the peer with each SA you have with a remote peer. I think 32 bits are enough and do not consume much memory. If A does not have any SA anymore with B (say A crashed or was forced to delete its SA's), no risk that it will send bad SPI's. And any notification/restart from B would be spoof. If A has at least an SA with B but A and B are out of sync, it still has the seq# and can take the conclusions at the end of the exchange. So really, are 4 bytes/SA a problem ? And that number could even be a date-time... And this is just a solution example. It is possible to make better if you think you will have many SA's per peer (space and speed efficiency). fred sankar ramamoorthi wrote: > > Hi, > > comments inline > >From: sommerfeld@thunk.east.sun.com on behalf of Bill Sommerfeld > >[sommerfeld@east.sun.com] > >Sent: Monday, January 22, 2001 7:01 PM > >To: sankar ramamoorthi > >Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly; > >ipsec@lists.tislabs.com > >Subject: Re: ipsec error protocol > > > >> >In the Detienne/Sommerfeld method, you notify and restart the > negotiation > >> at once (no IPSec<->IKE pingpong), almost immediately (no wasted packets, > no > >> timers), at a stage that is the most efficient in all the cases (phase 1 > >> first or directly with phase 2) and with a fraction (at worse 1/2) of the > >> timers required in your method. > >> > >> If I understand the proposal correctly it requires the sender of the > message > >> to remember some unique information known to each peer to get the > >> 'invalid spi' notification authenticated. How can the sender remember > >> this information across reboots? > > > >The message contains a signed sequence number; the "birth cert" sender > >need only keep a single sequence number, shared across all peers. > > > >Replay detection is simple. the "birth cert" receiver (SA sender) > >needs to hang on to the "current" birth cert for the lifetime of the > >sending side of the SA. (i.e., the sending end of the SA can throw it > >away when it throws away the SA state). > > > >If it receives a newer birth cert than the old one, it knows that the > >peer has rebooted and its SA state is stale. > > > >If it receives an older birth cert in an error message, it can > >trivially ignore it. > > > Some comments on the scheme. Correct me if am I wrong in my understanding. > > This scheme depends upon the sequence number used in a birth cert to be > continously incrasing across reboots. This may not always be possible. > For example time (from which the sequence number may be derived) may be > reset, configuration may be reset etc. In these cases information > about the previous sequence number is lost. > > What if the private key that is used to sign the sequence number is lost? > (may be nvram/flash needed to be reprogrammed for some reason) How > does the birth cert owner recover from the situation? > Does it have to create a new ike sa with every existing peer to update > the birth cert information? > > What the ways to handle these operational problems? > > >There are other tricks you can use to engineer DoS resistance. (i.e., > >rate limit how often you'll attempt to validate a signature, skip the > >validation if you've recently received authentic traffic from the > >peer, etc., etc.) > > > > - Bill > > -- sankar -- From owner-ipsec@lists.tislabs.com Tue Jan 23 08:44:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA27866; Tue, 23 Jan 2001 08:44:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24792 Tue, 23 Jan 2001 09:48:56 -0500 (EST) Date: Tue, 23 Jan 2001 07:50:13 -0700 (MST) From: Joel M Snyder Subject: VPNCON Update (Feb 19-22, San Jose) To: ipsec@lists.tislabs.com Message-id: <01JZ8MF5KY9690MTAO@Opus1.COM> Organization: Opus One - +1 520 324 0494 MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Fruit-of-the-day: Cascara Comments: Telecommunications and Information Technology Services Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I know that most of the active members of this list will find this a little off-topic, but many of the lurkers are probably more interested in learning more about IPSEC and VPNs. So at the risk of offending, here's an update on VPNCON. VPNCON, the most VPN-focused business/technical conference, will be held in San Jose, February 19-22. I'm the semi-paid/mostly-volunteer conference director and in charge of bringing the "content" part of the show to you. This conference is aimed at: - technical people who want to know more about VPNs, IPSEC, networking technology behind VPNs, and the products and services available - managers who want to know how to design and integrate VPNs into their existing networks, and how to deploy VPNs to their remote users - decision makers who want to know how VPNs can be used in real organizations To support that, VPNCON San Jose has: - two tutorials on Monday. IPSEC basics & VPN design (presented by Jan Trumbo of Opus One) and PKI (presented by Stephen Kent and Charlie Birnbaum) - three tracks of sessions: technical and detailed technology information; business issues and VPN deployment; and real-world case studies. There are over 30 sessions to choose from - four "Hands On VPN" seminars to walk you through real equipment in-your-face implementations of VPNs (led by VPNet, NetScreen/Verisign, IPDynamics, and EICON networks) - tutorial on Thursday on "Network Security and Firewalls" presented by Global Knowledge Network - keynote speech by Jawad Khaki of Microsoft - extensive exhibit hall with every leading VPN vendor showing their stuff. No better way to see all the VPN products under one roof. - after session events each evening for networking with peers Full conference info and registration via the VPNCON web page is at: http://www.vpncon.com/2001events/spring/spring2001index.htm If you mention the IPSEC Guru List discount code 103 when registering before 1/29, you'll get the early bird price. Hint hint: if you live in San Jose and were thinking of just stopping by for the exhibits, it's better to preregister anyway. On-site exhibit-only registration is $30, but if you register before 1/29 with discount code 103, you'll get it for $10. -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Phone: +1 520 324 0494 x101 (v) +1 520 324 0495 (FAX) jms@Opus1.COM http://www.opus1.com/jms Opus One From owner-ipsec@lists.tislabs.com Tue Jan 23 11:23:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07684; Tue, 23 Jan 2001 11:23:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25977 Tue, 23 Jan 2001 12:47:37 -0500 (EST) Message-Id: <200101231740.f0NHeJ5121158@thunk.east.sun.com> From: Bill Sommerfeld To: "sankar ramamoorthi" cc: sommerfeld@East.Sun.COM, fd@cisco.com, "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol In-reply-to: Your message of "Mon, 22 Jan 2001 20:17:54 PST." Reply-to: sommerfeld@East.Sun.COM Date: Tue, 23 Jan 2001 12:40:18 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Note that snmpv3 security also uses a boot sequence number as part of its replay detection, so any box which does snmpv3 security must already have solved this problem ;-) > This scheme depends upon the sequence number used in a birth cert to be > continously incrasing across reboots. This may not always be possible. > For example time (from which the sequence number may be derived) may be > reset, configuration may be reset etc. In these cases information > about the previous sequence number is lost. I can think of a number of ways; I'm sure there are others.. The boot sequence number could be put in part of NVRAM which is not cleared on a config reset. After a config reset, some sort of config reload is generally required; that can include resetting system time to a known correct value. > What if the private key that is used to sign the sequence number is > lost? The intent is that the key used to sign the birth cert is the same as the key used to authenticate the IKE exchange. If you lose that, you need to generate a new one and have certificates reissued, etc., - Bill From owner-ipsec@lists.tislabs.com Tue Jan 23 11:50:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09427; Tue, 23 Jan 2001 11:50:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26262 Tue, 23 Jan 2001 13:24:03 -0500 (EST) Message-Id: <200101231548.f0NFmB101604@marajade.sandelman.ottawa.on.ca> To: "'ipsec@lists.tislabs.com'" Subject: Re: Increased sequence number in ESP/AH In-reply-to: Your message of "Mon, 22 Jan 2001 15:13:42 EST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 23 Jan 2001 10:48:11 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> My proposal calls for the extended sequence numbers to NOT occupy any Stephen> more space in the ESP or AH headers. Instead, use of these numbers Stephen> would be negotiated by IKE, so that interoperability would be So, as I understand this note, it simply allows to hosts to agree to not rekey after 2^32 packets, but rather go to a much higher number. I can see the benefit of this for extremely high bandwidth devices, but even at OC-768 is it really necessary? Is there more than you can tell about the intended application of this? ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Tue Jan 23 13:18:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12146; Tue, 23 Jan 2001 13:18:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA26716 Tue, 23 Jan 2001 14:27:30 -0500 (EST) Message-Id: <200101231923.LAA18858@potassium.network-alchemy.com> To: "'ipsec@lists.tislabs.com'" Subject: Re: Increased sequence number in ESP/AH In-reply-to: Your message of "Mon, 22 Jan 2001 15:13:42 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18855.980277810.1@network-alchemy.com> Date: Tue, 23 Jan 2001 11:23:30 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk While we're on the subject of sequence numbers and IKE negotiation I'd like to make use of them negotiable. Right now the sender must always send them even if the recipient is not using them. Parallelization of IPsec processing is much easier if both sides can agree to forgo the benefits of the anti-replay check. There's a REPLAY-STATUS notify message which I will wager has never been implemented by anyone but it still does not relieve the sender of his obligation to send the counter, it just allows the recipient to say it will be ignored. This would require new verbage on REPLAY-STATUS usage in the combined IKE draft and also changes to RFC2401 which I understand is already being considered for change. Dan. P.S. for those of you with long memories yes I was the one that stood up in Munich and told Steve Kent it was "just plain stupid" to negotiate this. Mmmmmm, crow. On Mon, 22 Jan 2001 15:13:42 EST Stephen Kent wrote > Avi, > > >I would like to ask about the proposal to increase the size of the sequence > >number field in ESP and AH headers to 64 or 128 bits. This was discussed in > >the last IETF conference in San Diego. > > > > * Is there any specific definition for updated ESP/AH structure? > > * ESP and AH headers currently does not include version number. > > - Does the preceding header will have new values for the headers? > >Or how this can be solved (specific SPIs?) > > My proposal calls for the extended sequence numbers to NOT occupy any > more space in the ESP or AH headers. Instead, use of these numbers > would be negotiated by IKE, so that interoperability would be > maintained with systems that do not support the extended fields. No > change would occur in the "on the wire" format, which avoids > increasing overhead. Sender and receiver maintain larger (e.g., 64 > bit) counters, but transmit only the low order 32 bits. A new > receiver window algorithm is needed to deal with the transition that > occurs every 2**32 packets, but there is no security ambiguity here, > i.e., any packet that is < 2**32-1 by more than the receive window is > treated like a packet from the next chunk of sequence space. > > Steve > > P.S. Since sequence numbers are not used for anti-replay for > manually keyed SAs, not being able to negotiate this for non-IKE > contexts does not seem to be a problem. Any other protocol that is > used to negotiate SAs should be able to support this sort of > negotiation. > From owner-ipsec@lists.tislabs.com Tue Jan 23 13:47:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12795; Tue, 23 Jan 2001 13:47:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27007 Tue, 23 Jan 2001 15:15:10 -0500 (EST) Message-Id: <200101232017.f0NKHh5121568@thunk.east.sun.com> From: Bill Sommerfeld To: Dan Harkins cc: "'ipsec@lists.tislabs.com'" Subject: Re: Increased sequence number in ESP/AH In-reply-to: Your message of "Tue, 23 Jan 2001 11:23:30 PST." <200101231923.LAA18858@potassium.network-alchemy.com> Reply-to: sommerfeld@East.Sun.COM Date: Tue, 23 Jan 2001 15:17:43 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > While we're on the subject of sequence numbers and IKE negotiation > I'd like to make use of them negotiable. Right now the sender must always > send them even if the recipient is not using them. Parallelization of > IPsec processing is much easier if both sides can agree to forgo the > benefits of the anti-replay check. If all you care about is performance, it's even faster if you leave out the crypto. :-) If you want to avoid multiple crypto engines single-threading on the counter increment, negotiate multiple equivalent SA's and load-balance across the SA's.. - Bill From owner-ipsec@lists.tislabs.com Tue Jan 23 14:24:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13647; Tue, 23 Jan 2001 14:24:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA27327 Tue, 23 Jan 2001 15:59:31 -0500 (EST) Message-ID: <3A6DF166.60200CD1@columbia.sparta.com> Date: Tue, 23 Jan 2001 16:02:30 -0500 From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: "'ipsec@lists.tislabs.com'" Subject: Re: Increased sequence number in ESP/AH References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, How does this address freshness (anti-replay)? Is this intended only as a useful feature for high-speed devices that may need additional SA lifetime? --- Andrea Colegrove Stephen Kent wrote: > Avi, > > >I would like to ask about the proposal to increase the size of the sequence > >number field in ESP and AH headers to 64 or 128 bits. This was discussed in > >the last IETF conference in San Diego. > > > > * Is there any specific definition for updated ESP/AH structure? > > * ESP and AH headers currently does not include version number. > > - Does the preceding header will have new values for the headers? > >Or how this can be solved (specific SPIs?) > > My proposal calls for the extended sequence numbers to NOT occupy any > more space in the ESP or AH headers. Instead, use of these numbers > would be negotiated by IKE, so that interoperability would be > maintained with systems that do not support the extended fields. No > change would occur in the "on the wire" format, which avoids > increasing overhead. Sender and receiver maintain larger (e.g., 64 > bit) counters, but transmit only the low order 32 bits. A new > receiver window algorithm is needed to deal with the transition that > occurs every 2**32 packets, but there is no security ambiguity here, > i.e., any packet that is < 2**32-1 by more than the receive window is > treated like a packet from the next chunk of sequence space. > > Steve > > P.S. Since sequence numbers are not used for anti-replay for > manually keyed SAs, not being able to negotiate this for non-IKE > contexts does not seem to be a problem. Any other protocol that is > used to negotiate SAs should be able to support this sort of > negotiation. From owner-ipsec@lists.tislabs.com Tue Jan 23 14:53:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14304; Tue, 23 Jan 2001 14:53:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27482 Tue, 23 Jan 2001 16:21:52 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Andrea Colegrove Cc: Stephen Kent , "'ipsec@lists.tislabs.com'" Subject: Re: Increased sequence number in ESP/AH Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jan 2001 16:24:32 -0500 Message-Id: <20010123212432.94DCB35C42@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3A6DF166.60200CD1@columbia.sparta.com>, Andrea Colegrove writes: >Steve, > How does this address freshness (anti-replay)? > > Is this intended only as a useful feature for high-speed devices that may >need additional SA lifetime? > OC-192 -- deployed in some of today's backbones -- is roughly 1 gigabyte/second. Multiply by whatever you think is the average packet size, and multiply again by 4 -- but it's not a large number for the duration of an SA. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Tue Jan 23 15:04:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14555; Tue, 23 Jan 2001 15:04:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27549 Tue, 23 Jan 2001 16:28:38 -0500 (EST) Message-ID: <3A6DF837.53EA2C9F@columbia.sparta.com> Date: Tue, 23 Jan 2001 16:31:35 -0500 From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" , ipsec@lists.tislabs.com Subject: Re: Increased sequence number in ESP/AH References: <20010123212432.94DCB35C42@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Let me rephrase the questions, please: Is the intent of expanding the sequence number purely for the purpose of extending the SA lifetime, or are there other considerations? and How will the multiple instances of replay be countered? ---- Andrea "Steven M. Bellovin" wrote: > In message <3A6DF166.60200CD1@columbia.sparta.com>, Andrea Colegrove writes: > >Steve, > > How does this address freshness (anti-replay)? > > > > Is this intended only as a useful feature for high-speed devices that may > >need additional SA lifetime? > > > > OC-192 -- deployed in some of today's backbones -- is roughly 1 > gigabyte/second. Multiply by whatever you think is the average packet > size, and multiply again by 4 -- but it's not a large number for the > duration of an SA. > > --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Tue Jan 23 15:15:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14784; Tue, 23 Jan 2001 15:15:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27620 Tue, 23 Jan 2001 16:33:24 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Andrea Colegrove Cc: ipsec@lists.tislabs.com Subject: Re: Increased sequence number in ESP/AH Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jan 2001 16:36:09 -0500 Message-Id: <20010123213609.35E0F35C42@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3A6DF837.53EA2C9F@columbia.sparta.com>, Andrea Colegrove writes: >Steve, > Let me rephrase the questions, please: > > Is the intent of expanding the sequence number purely for the purpose >of >extending the SA lifetime, or are there other considerations? and > How will the multiple instances of replay be countered? As far as I know, the sole motivation is to extend the SA lifetime. In his presentation at the last IETF, Steve Kent noted that the high-order bits of the extended sequence number had to be included in the authentication check, to prevent replays of old packets. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Tue Jan 23 15:22:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14960; Tue, 23 Jan 2001 15:22:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA27699 Tue, 23 Jan 2001 16:46:55 -0500 (EST) Message-Id: <200101232142.NAA19223@potassium.network-alchemy.com> To: sommerfeld@East.Sun.COM cc: "'ipsec@lists.tislabs.com'" Subject: Re: Increased sequence number in ESP/AH In-reply-to: Your message of "Tue, 23 Jan 2001 15:17:43 EST." <200101232017.f0NKHh5121568@thunk.east.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19220.980286169.1@network-alchemy.com> Date: Tue, 23 Jan 2001 13:42:49 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 23 Jan 2001 15:17:43 EST you wrote > > While we're on the subject of sequence numbers and IKE negotiation > > I'd like to make use of them negotiable. Right now the sender must always > > send them even if the recipient is not using them. Parallelization of > > IPsec processing is much easier if both sides can agree to forgo the > > benefits of the anti-replay check. > > If all you care about is performance, it's even faster if you leave > out the crypto. :-) Yuck, yuck. Actually, no it's not; crypto is not the bottleneck. There is a point of diminishing returns for complying with the anti-replay requirement. > If you want to avoid multiple crypto engines single-threading on the > counter increment, negotiate multiple equivalent SA's and load-balance > across the SA's.. That's one way to do it. But if the recipient has already said she isn't going to be inspecting the counter, for whatever reason, why mandate that the sender keep sending it? Dan. From owner-ipsec@lists.tislabs.com Tue Jan 23 15:44:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15721; Tue, 23 Jan 2001 15:44:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA27825 Tue, 23 Jan 2001 17:02:25 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: ipsec From: "Steven M. Bellovin" To: Dan Harkins Cc: sommerfeld@East.Sun.COM, "'ipsec@lists.tislabs.com'" Subject: Re: Increased sequence number in ESP/AH Mime-Version: 1.0 Content-Type: text/plain Date: Tue, 23 Jan 2001 17:05:07 -0500 Message-Id: <20010123220508.DC88F35C42@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200101232142.NAA19223@potassium.network-alchemy.com>, Dan Harkins w rites: >On Tue, 23 Jan 2001 15:17:43 EST you wrote >> > While we're on the subject of sequence numbers and IKE negotiation >> > I'd like to make use of them negotiable. Right now the sender must always >> > send them even if the recipient is not using them. Parallelization of >> > IPsec processing is much easier if both sides can agree to forgo the >> > benefits of the anti-replay check. >> >> If all you care about is performance, it's even faster if you leave >> out the crypto. :-) > >Yuck, yuck. Actually, no it's not; crypto is not the bottleneck. There >is a point of diminishing returns for complying with the anti-replay >requirement. For your application, what is the bottleneck? We're talking about a single 32-bit addition, which I assume is quite fast. > >> If you want to avoid multiple crypto engines single-threading on the >> counter increment, negotiate multiple equivalent SA's and load-balance >> across the SA's.. > >That's one way to do it. But if the recipient has already said she isn't >going to be inspecting the counter, for whatever reason, why mandate that >the sender keep sending it? If you're going to have N encryptors, assign them each a separate counter starting at [0,N-1], with each incrementing by N instead of 1. I would expect that most reasonable distributions of packet sizes would result in most packets not arriving too much out of sequence, and certainly well within the window. Besides -- leaving out the replay counter is *dangerous*. I'd really like to avoid reopening that can of worms. (Folks may recall that I opposed the notion of making the check by the receiver optional.) From owner-ipsec@lists.tislabs.com Tue Jan 23 17:36:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17858; Tue, 23 Jan 2001 17:36:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28452 Tue, 23 Jan 2001 18:42:47 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3A6DF166.60200CD1@columbia.sparta.com> References: <3A6DF166.60200CD1@columbia.sparta.com> Date: Tue, 23 Jan 2001 18:42:14 -0500 To: Andrea Colegrove From: Stephen Kent Subject: Re: Increased sequence number in ESP/AH Cc: "'ipsec@lists.tislabs.com'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:02 PM -0500 1/23/01, Andrea Colegrove wrote: >Steve, > How does this address freshness (anti-replay)? > > Is this intended only as a useful feature for high-speed devices that may >need additional SA lifetime? > >--- Andrea Colegrove The extended sequence number is made part of the integrity check, e.g., by virtually appending it to the payload, so that anti-replay is still offered to an SA that makes use of the extended sequence numbers. Steve From owner-ipsec@lists.tislabs.com Tue Jan 23 17:36:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17872; Tue, 23 Jan 2001 17:36:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA28451 Tue, 23 Jan 2001 18:42:47 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200101231548.f0NFmB101604@marajade.sandelman.ottawa.on.ca> References: <200101231548.f0NFmB101604@marajade.sandelman.ottawa.on.ca> Date: Tue, 23 Jan 2001 18:40:23 -0500 To: Michael Richardson From: Stephen Kent Subject: Re: Increased sequence number in ESP/AH Cc: "'ipsec@lists.tislabs.com'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, We're looking at 10 Gb/s IPsec implementations. At that speed, if one were to send minimum size packets over a single SA (a worst case scenario, I admit) the SA would run out of sequence number space in a few minutes. So, to avoid the cost of rekeying the SA (and migrating the traffic to the new SA), I suggest that we extend the sequence number space. Steve From owner-ipsec@lists.tislabs.com Tue Jan 23 17:49:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18453; Tue, 23 Jan 2001 17:49:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28582 Tue, 23 Jan 2001 19:27:05 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Dan Harkins Cc: sommerfeld@East.Sun.COM, "'ipsec@lists.tislabs.com'" Subject: Re: Increased sequence number in ESP/AH Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jan 2001 19:29:44 -0500 Message-Id: <20010124002945.E45E935C42@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200101240014.QAA19763@potassium.network-alchemy.com>, Dan Harkins w rites: >> >> For your application, what is the bottleneck? We're talking about a >> single 32-bit addition, which I assume is quite fast. > >For now it's the 100Mb/s wire. Crypto will become the bottleneck again >with faster media though. Right -- but a single 32-bit add is going to be much faster than any of the crypto, no matter what. > >The problem is that the box provides 250ms active session failover from >device to device and keeping the replay window in sync at very high >bitrates gets to be expensive. > But you can send state updates rather infrequently; the bound is the window in which you're willing to accept the attack I outline below. (There's always some risk. For example, the enemy could divert *all* packets from an SA, and replay the stream in its entirely later.) I'm not convinced that this is a pressing enough need to warrant complicating everyone else's stacks. >> >> Besides -- leaving out the replay counter is *dangerous*. I'd really >> like to avoid reopening that can of worms. (Folks may recall that I >> opposed the notion of making the check by the receiver optional.) > >If it is possible to authenticate, decrypt and decapsulate packets faster >than they can be delivered what is the danger in getting a packet which >will either fail the authentication check or which had previously been >delivered? Sorry, I don't recall your opposition. Under certain circumstances, there's a simple but very devastating attack if there's no replay check: the enemy waits till your process is done, and then binds to the same port and replays the packets. Why crack the crypto when the kernel will decrypt it for you? --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Tue Jan 23 18:07:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA18806; Tue, 23 Jan 2001 18:07:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA28553 Tue, 23 Jan 2001 19:18:55 -0500 (EST) Message-Id: <200101240014.QAA19763@potassium.network-alchemy.com> To: "Steven M. Bellovin" cc: sommerfeld@East.Sun.COM, "'ipsec@lists.tislabs.com'" Subject: Re: Increased sequence number in ESP/AH In-reply-to: Your message of "Tue, 23 Jan 2001 17:05:07 EST." <20010123220508.DC88F35C42@smb.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19760.980295292.1@network-alchemy.com> Date: Tue, 23 Jan 2001 16:14:52 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 23 Jan 2001 17:05:07 EST you wrote > In message <200101232142.NAA19223@potassium.network-alchemy.com>, Dan Harkins > w > rites: > >On Tue, 23 Jan 2001 15:17:43 EST you wrote > >> > While we're on the subject of sequence numbers and IKE negotiation > >> > I'd like to make use of them negotiable. Right now the sender must alway >s > >> > send them even if the recipient is not using them. Parallelization of > >> > IPsec processing is much easier if both sides can agree to forgo the > >> > benefits of the anti-replay check. > >> > >> If all you care about is performance, it's even faster if you leave > >> out the crypto. :-) > > > >Yuck, yuck. Actually, no it's not; crypto is not the bottleneck. There > >is a point of diminishing returns for complying with the anti-replay > >requirement. > > For your application, what is the bottleneck? We're talking about a > single 32-bit addition, which I assume is quite fast. For now it's the 100Mb/s wire. Crypto will become the bottleneck again with faster media though. The problem is that the box provides 250ms active session failover from device to device and keeping the replay window in sync at very high bitrates gets to be expensive. > >> If you want to avoid multiple crypto engines single-threading on the > >> counter increment, negotiate multiple equivalent SA's and load-balance > >> across the SA's.. > > > >That's one way to do it. But if the recipient has already said she isn't > >going to be inspecting the counter, for whatever reason, why mandate that > >the sender keep sending it? > > If you're going to have N encryptors, assign them each a separate > counter starting at [0,N-1], with each incrementing by N instead > of 1. I would expect that most reasonable distributions of packet > sizes would result in most packets not arriving too much out of > sequence, and certainly well within the window. > > Besides -- leaving out the replay counter is *dangerous*. I'd really > like to avoid reopening that can of worms. (Folks may recall that I > opposed the notion of making the check by the receiver optional.) If it is possible to authenticate, decrypt and decapsulate packets faster than they can be delivered what is the danger in getting a packet which will either fail the authentication check or which had previously been delivered? Sorry, I don't recall your opposition. Dan. From owner-ipsec@lists.tislabs.com Tue Jan 23 20:25:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22094; Tue, 23 Jan 2001 20:25:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA28879 Tue, 23 Jan 2001 20:44:03 -0500 (EST) Subject: Re: Increased sequence number in ESP/AH From: Niels Provos In-Reply-To: Dan Harkins, Tue, 23 Jan 2001 13:42:49 PST To: Dan Harkins Cc: sommerfeld@East.Sun.COM, "'ipsec@lists.tislabs.com'" Date: Tue, 23 Jan 2001 20:46:46 -0500 Message-Id: <20010124014646.2798F207C3@citi.umich.edu> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200101232142.NAA19223@potassium.network-alchemy.com>, Dan Harkins w rites: >That's one way to do it. But if the recipient has already said she isn't >going to be inspecting the counter, for whatever reason, why mandate that >the sender keep sending it? Did the recipient also say that she will give the session key to anyone who is asking? Aren't there security implications when replay protection is removed. Wasn't IPsec supposed to solve them? And if you can encrypt at 1GB/s, it shouldn't be a problem to run the key exchange more often either. IKE and IPsec already seemed complicated enough to me, but I am sure that we can find good reasons to further complicate them. This discussion is getting very confusing, Niels. From owner-ipsec@lists.tislabs.com Tue Jan 23 21:01:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA22918; Tue, 23 Jan 2001 21:01:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA29077 Tue, 23 Jan 2001 22:22:13 -0500 (EST) Message-ID: <3A6E4ABA.C6866A4F@storm.ca> Date: Tue, 23 Jan 2001 22:23:38 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "'ipsec@lists.tislabs.com'" Subject: Re: Increased sequence number in ESP/AH References: <20010123212432.94DCB35C42@smb.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" wrote: > > In message <3A6DF166.60200CD1@columbia.sparta.com>, Andrea Colegrove writes: > >Steve, > > How does this address freshness (anti-replay)? > > > > Is this intended only as a useful feature for high-speed devices that may > >need additional SA lifetime? > > > > OC-192 -- deployed in some of today's backbones -- is roughly 1 > gigabyte/second. Multiply by whatever you think is the average packet > size, and multiply again by 4 -- but it's not a large number for the > duration of an SA. > > --Steve Bellovin, http://www.research.att.com/~smb Yes, but do we expect those backbone devices to be doing IPSEC? Perhaps a limited amount for management functions -- remote admin login, ICMP, routing protocols -- but I wouldn't expect them to be doing it for bulk traffic. Methinks bulk traffic encryption needs to be as near end-to-end as practical, if not on the end user systems, then on local routers and firewalls. Almost by definition, that excludes backbone routers. You want them just shuffling packets. Routing is hard enough without adding IPSEC to that mix. OC-3 is the largest pipe I'd expect near enough to the edges that we want to see IPSEC on it. 155 Mbit/sec, ~ 20 Mbyte, certainly less than 1 M packets/sec, so over an hour between re-keyinga. No problem. If we're contemplating any changes to the protocol, we want some that bring us nearer to the end-to-end goal, IPSEC on end-point systems. From owner-ipsec@lists.tislabs.com Tue Jan 23 23:21:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA04942; Tue, 23 Jan 2001 23:21:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA29370 Wed, 24 Jan 2001 00:38:11 -0500 (EST) From: "sankar ramamoorthi" To: Cc: , "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Tue, 23 Jan 2001 21:28:26 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-reply-to: <200101231740.f0NHeJ5121158@thunk.east.sun.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: sommerfeld@thunk.east.sun.com on behalf of Bill Sommerfeld >[sommerfeld@east.sun.com] >Sent: Tuesday, January 23, 2001 9:40 AM >To: sankar ramamoorthi >Cc: sommerfeld@east.sun.com; fd@cisco.com; Scott G. Kelly; >ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >Note that snmpv3 security also uses a boot sequence number as part of >its replay detection, so any box which does snmpv3 security must >already have solved this problem ;-) > >> This scheme depends upon the sequence number used in a birth cert to be >> continously incrasing across reboots. This may not always be possible. >> For example time (from which the sequence number may be derived) may be >> reset, configuration may be reset etc. In these cases information >> about the previous sequence number is lost. > >I can think of a number of ways; I'm sure there are others.. > >The boot sequence number could be put in part of NVRAM which is not >cleared on a config reset. > >After a config reset, some sort of config reload is generally >required; that can include resetting system time to a known correct >value. What if the previous time was wrong for some reasons? > >> What if the private key that is used to sign the sequence number is >> lost? > >The intent is that the key used to sign the birth cert is the same as >the key used to authenticate the IKE exchange. > >If you lose that, you need to generate a new one and have certificates >reissued, etc., Which means during the intervals when certs are reissued and propagated, the 'invalid spi' notification cannot be sent out because the private key with with it has to be signed is lost. > > - Bill As I try to understand the scheme better I see a number of problems . operational problems (as described above - there could be more) They probably could be worked around but it seems to me the solution is now extending from ipsec to ike to device configuration and management. . lack of a time-variant(replay sequence as in ESP or AH) allows one conjure some scenarios where replay attacks are possible . extra overhead of authenticating notifications during DOS attack. Considering all this I feel an error control protocol in ipsec is preferable as a mechanism towards ipsec-state synchronization problem. The protocol is limited to ipsec, does not try to impose a solution to state synchronization but provides a building block. Conforming implementations just need to support simple ipsec error processing and no other changes are required. There are a lot of similarities to proposed ipsec error control mechnism and icmp. icmp is an ip error control protocol and uses a reserved protocol number from the transport-layer protcol space. The proposed ipsec error control mechanism uses a spi from the reserved spi space. Like icmp, ipsec error control can be used to provide a number of error/control functionality. As for DOS resistant solution, my personal take is that it is difficult to provide a complete solution for DOS prevention. One can only provide guidelines on how systems can react to DOS to minimize the damage. -- sankar -- From owner-ipsec@lists.tislabs.com Wed Jan 24 00:37:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18157; Wed, 24 Jan 2001 00:37:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA29503 Wed, 24 Jan 2001 01:57:45 -0500 (EST) Message-Id: <200101240700.XAA07641@cisco.com> X-Sender: sfluhrer@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 23 Jan 2001 22:54:07 -0800 To: ipsec@lists.tislabs.com From: Scott Fluhrer Subject: A tale of three transforms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The goal of this memo is help the IETF specify the AES based IPSec transform, by comparing and contrasting three specific proposals by a variety of criteria. Three draft RFCs (of various levels of completeness) have been published to specify how AES will be used within an IPSec transform. These three drafts are: A CBC mode draft (referred to as CBC within this memo): http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-01.txt A Counter mode draft (referred to as COUNTER within this memo): http://www.ietf.org/internet-drafts/draft-mcgrew-ipsec-scesp-02.txt A draft based on the new IAPM mode (referred to as IAPM within this memo): http://www.ietf.org/internet-drafts/draft-jutla-ietf-ipsec-esp-iapm-00.txt The author welcomes any correction to these evaluations, and any additional criteria that these proposals should be evaluated against. Full disclosure: the author of this memo is a coauthor of the COUNTER draft. A few notes on the ground rules used for these evaluations: IAPM also provides authentication. We will assume that the IPSec SAs will require message authentication, and hence for the purposes of the evaluation, the CBC and COUNTER drafts will be used along with an authentication transform. We also note that there are a variety of ways to tweak these proposals to reduce some of the listed drawbacks. However, these tweaks tend to add drawbacks elsewhere. Because of this complexity, we will examine the proposals as written. However, IAPM does not strictly define how the random vector r is generated. Following the recommendation in section 2.2, we will assume that 96 bits of explicit IV, along with the 32 bit sequence number, will be used to generate the r vector. The actual evaluations: Security Claims: All three transforms claim to offer privacy equivalent to the underlying block cipher (for the number of messages that IPSec can transmit before rekeying). In addition, IAPM claims to offer authentication equivalent to the underlying block cipher. Neither CBC nor COUNTER make any authentication claims. Confidence in the Security Claims: This section is, necessarily, a matter of opinion. However, we all feel good with CBC -- we have used it with all previous block-cipher based transforms. We don't have as much experience with COUNTER mode, however, there is enough to feel comfortable with it. IAPM is quite new. There do exist security proofs for it, which have been reviewed by competent cryptographers, however, we'd all feel better if it had been around for a while first. Completeness of Specification: CBC is a complete specification -- it appears that the authors have specified enough to allow interoperable implementations to be created. COUNTER is not quite complete -- the issue of key length is never addressed. In addition, it appears likely that the exact specification will change somewhat. IAPM is not at all complete -- the listed draft is more a specification of a block cipher mode rather than an ESP transform. Packet Size: COUNTER has the shortest packets -- there is no IV and supports minimal padding. Hence, the overhead is 1-4 bytes of padding, along with the overhead from the authentication transform. CBC is rather larger -- there is a 16 byte IV, 1-16 bytes of padding, and the overhead from the authentication transform. IAPM is also comparatively large -- a 12 byte IV, 16 bytes of encrypted checksum, and 1-16 bytes of padding. Speed of Software Implementation: All three transforms can be executed in approximately the same speed. However, CBC and COUNTER also require authentication transforms to be executed, hence IAPM would be somewhat faster. Speed of Hardware Implementation: This evaluation assumes an aggressively parallized hardware implementation. IAPM is the fastest, in that it is inherently parallizable. COUNTER is equally parallizable, but then brings us the question of how to make the authentication transform equally fast. CBC is necessarily slow in the encrypted direction, because the block cipher evaluations must be done serially. Intellectual Property Issues: There is no know intellection property issues with CBC or COUNTER, and there is sufficient prior art to make it quite unlikely that any will arise. IAPM is patent pending by IBM. However, the listed draft reflects refinements by Phillip Rogaway, and it is unknown how that affects the intellection property. Fit within Existing Security Architecture: CBC and COUNTER fit into the existing security architecture as encryption transforms. IAPM does not -- the security architecture will need to be extended to include transforms that does both encryption and authentication. Strength against Faulty Implementations: By faulty implementation, we refer to accidental faults that allow implementations to interoperate, but cause security risks. We do not consider faults available to malicious implementations, as side channels exist independent of the transform. With CBC, the worst fault appears to be if the IV generation reuses the same IV. This would allow the attacker to see if the first blocks of the encrypted data are reused, however, this does not appear to be a severe problem. With IAPM, a problem would occur only if both the IV and the key are reused between sessions. This would allow the attacker to see duplicate blocks between sessions, however, this would require multiple faults, so it does not appear to be likely. COUNTER has the most severe problems -- if a faulty keying mechanism reuses the same keys between sessions, then an attacker can gain considerable information on the encrypted data. From owner-ipsec@lists.tislabs.com Wed Jan 24 03:06:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04380; Wed, 24 Jan 2001 03:06:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA29938 Wed, 24 Jan 2001 04:11:31 -0500 (EST) Message-ID: <3A6E9DF2.5E5F22C6@cisco.com> Date: Wed, 24 Jan 2001 10:18:42 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sankar ramamoorthi CC: sommerfeld@East.Sun.COM, "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sankar ramamoorthi wrote: > >After a config reset, some sort of config reload is generally > >required; that can include resetting system time to a known correct > >value. > > What if the previous time was wrong for some reasons? Then quit trusting all form of certificate because they are time stamped. > > > >> What if the private key that is used to sign the sequence number is > >> lost? > > > >The intent is that the key used to sign the birth cert is the same as > >the key used to authenticate the IKE exchange. > > > >If you lose that, you need to generate a new one and have certificates > >reissued, etc., > > Which means during the intervals when certs are reissued and propagated, > the 'invalid spi' notification cannot be sent out because the private > key with with it has to be signed is lost. Fixed by the combined method. You sign the last IKE packets, period. And btw, you do not change certs very often... and in the cert of birth method alone, you could also include the CA cert. This is riduculous. > As I try to understand the scheme better I see a number of problems > > . operational problems (as described above - there could be more) > They probably could be worked around but it seems to me the solution > is now extending from ipsec to ike to device configuration and > management. The combined method fixes this. > . lack of a time-variant(replay sequence as in ESP or AH) allows > one conjure some scenarios where replay attacks are possible The combined method does that too: IKE is replay protected. And btw, your method has the same problem: the seq # in ESP goes in the clear and it is protected only if authentication is available on the SPI you are probing. > . extra overhead of authenticating notifications during DOS attack. The combined method would stop before doing any crypto computation (cookie protection). And btw, your probe has to be protected and the reply has to be protected too... > Considering all this I feel an error control protocol in ipsec is > preferable as a mechanism towards ipsec-state synchronization problem. I do not see the relationship. > The protocol is limited to ipsec, does not try to impose a solution > to state synchronization but provides a building block. Conforming > implementations just need to support simple ipsec error processing > and no other changes are required. > > There are a lot of similarities to proposed ipsec error control > mechnism and icmp. icmp is an ip error control protocol and uses > a reserved protocol number from the transport-layer protcol space. > The proposed ipsec error control mechanism uses a spi from the > reserved spi space. Like icmp, ipsec error control can be used > to provide a number of error/control functionality. You certainly mean there are parallels between ICMP-type/code and the SPI number... not the protocol type of ICMP and the SPI number. ICMP is multipurpose your SPI would be single purpose (like the type/code in ICMP). Whatever. I agree that looks nice but does that bring anything ? The group could also have built IKE on top of ICMP. Since IPSec is somehow part of IP(v6), that would have made sense... I do not feel that IKE is such misplaced, though. But I will leave you that as I am not interested in a philosophical debate. In any case, this does not make your recovery mechanism efficient (even when NOT under DoS): 1 notification, several*[probe + timeout] before starting phase 2, timing out, then phase 1... keepalives in disguise. Finally, if you do not like IKE, you certainly do not like my method (which is NOT Cert of Birth only) but I have not introduced anything new in IKE (in terms of hazard). On your side, you still have not explained the shape of your probe packets and the way you protect them (key usage and generation). Can you proceed ? Regards, frederic detienne From owner-ipsec@lists.tislabs.com Wed Jan 24 06:20:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18988; Wed, 24 Jan 2001 06:20:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA00688 Wed, 24 Jan 2001 07:47:53 -0500 (EST) Message-Id: <200101240229.f0O2TEh03852@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: Increased sequence number in ESP/AH In-reply-to: Your message of "Tue, 23 Jan 2001 18:40:23 EST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 23 Jan 2001 21:29:14 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen Kent writes: Stephen> We're looking at 10 Gb/s IPsec implementations. At that speed, if one Stephen> were to send minimum size packets over a single SA (a worst case Stephen> scenario, I admit) the SA would run out of sequence number space Yeah, I can buy that for minimum length packets at 10Gb/s. It seems like a trivial new IKE proposal option, as it has no detectable wire changes, just changes to the documents. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Jan 24 10:46:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04067; Wed, 24 Jan 2001 10:46:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA01779 Wed, 24 Jan 2001 12:17:15 -0500 (EST) From: "Joseph D. Harwood" To: "Ipsec" , "Sandy Harris" Subject: RE: Increased sequence number in ESP/AH Date: Wed, 24 Jan 2001 09:20:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0018_01C085E6.D7795800" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <3A6E4ABA.C6866A4F@storm.ca> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C085E6.D7795800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Sandy Harris > Sent: Tuesday, January 23, 2001 7:24 PM > To: 'ipsec@lists.tislabs.com' > Subject: Re: Increased sequence number in ESP/AH > > > "Steven M. Bellovin" wrote: > > > > In message <3A6DF166.60200CD1@columbia.sparta.com>, Andrea > Colegrove writes: > > >Steve, > > > How does this address freshness (anti-replay)? > > > > > > Is this intended only as a useful feature for high-speed > devices that may > > >need additional SA lifetime? > > > > > > > OC-192 -- deployed in some of today's backbones -- is roughly 1 > > gigabyte/second. Multiply by whatever you think is the average packet > > size, and multiply again by 4 -- but it's not a large number for the > > duration of an SA. > > > > --Steve Bellovin, http://www.research.att.com/~smb > > Yes, but do we expect those backbone devices to be doing IPSEC? > Perhaps a limited > amount for management functions -- remote admin login, ICMP, > routing protocols -- > but I wouldn't expect them to be doing it for bulk traffic. > > Methinks bulk traffic encryption needs to be as near end-to-end > as practical, if not > on the end user systems, then on local routers and firewalls. > Almost by definition, > that excludes backbone routers. You want them just shuffling > packets. Routing is > hard enough without adding IPSEC to that mix. > > OC-3 is the largest pipe I'd expect near enough to the edges that > we want to see > IPSEC on it. 155 Mbit/sec, ~ 20 Mbyte, certainly less than 1 M > packets/sec, so > over an hour between re-keyinga. No problem. ISPs that provide network-based VPN services could use more than 155 Mbps IPsec processing capability. E.g., take a look at the service switches from Cosine Communications, SpringTide (Lucent), Shasta (Nortel), Quarry Technology. > > If we're contemplating any changes to the protocol, we want some > that bring us > nearer to the end-to-end goal, IPSEC on end-point systems. > Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com ------=_NextPart_000_0018_01C085E6.D7795800 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0018_01C085E6.D7795800-- From owner-ipsec@lists.tislabs.com Wed Jan 24 10:48:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04144; Wed, 24 Jan 2001 10:48:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01579 Wed, 24 Jan 2001 11:36:14 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: Scott Fluhrer Cc: ipsec@lists.tislabs.com Subject: Re: A tale of three transforms Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Jan 2001 11:38:41 -0500 Message-Id: <20010124163844.CE6FA35C42@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks -- that's a useful summary. I should point out that NIST has announced its Modes of Operation plans, at http://csrc.nist.gov/encryption/tkmodes.html The current plan is to specify the four current modes (ECB, CBC, CFB, and OFB), plus a counter mode, some time this spring. I'd be loathe to see the IETF design its own counter mode in advance of the NIST standard. They're also planning to specify other modes in the future. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Wed Jan 24 11:49:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA11236; Wed, 24 Jan 2001 11:49:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02101 Wed, 24 Jan 2001 13:18:19 -0500 (EST) Message-Id: <200101241814.KAA21566@potassium.network-alchemy.com> To: "Steven M. Bellovin" cc: sommerfeld@East.Sun.COM, "'ipsec@lists.tislabs.com'" Subject: Re: Increased sequence number in ESP/AH In-reply-to: Your message of "Tue, 23 Jan 2001 19:29:44 EST." <20010124002945.E45E935C42@smb.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21563.980360056.1@network-alchemy.com> Date: Wed, 24 Jan 2001 10:14:16 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 23 Jan 2001 19:29:44 EST you wrote > In message <200101240014.QAA19763@potassium.network-alchemy.com>, Dan Harkins > w > rites: > > >> > >> For your application, what is the bottleneck? We're talking about a > >> single 32-bit addition, which I assume is quite fast. > > > >For now it's the 100Mb/s wire. Crypto will become the bottleneck again > >with faster media though. > > Right -- but a single 32-bit add is going to be much faster than any of > the crypto, no matter what. Of course. The single 32-bit add is noise. But keeping that counter in sync is not. > >The problem is that the box provides 250ms active session failover from > >device to device and keeping the replay window in sync at very high > >bitrates gets to be expensive. > > > But you can send state updates rather infrequently; the bound is the > window in which you're willing to accept the attack I outline below. > (There's always some risk. For example, the enemy could divert *all* > packets from an SA, and replay the stream in its entirely later.) I'm > not convinced that this is a pressing enough need to warrant > complicating everyone else's stacks. If you send them infrequently then you have to "guess" what the new node who has gotten the failed-over workload should use as a sequence number for packets it starts sending. It's hard to know how many packets have been sent by the now-failed node since the last update unless the updates are relatively frequent. One can make the guess absurdly high but absurdly high on one link is absurdly low on another. And regardless of the media it's really the pps that is the governing factor. It's possible to use an adaptive update heuristic but now the complexity of just doing that single 32-bit add is pretty big. If the possibility of the attack you described is remote enough then I think the point of diminishing returns has been reached. Dan. From owner-ipsec@lists.tislabs.com Wed Jan 24 13:00:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16834; Wed, 24 Jan 2001 13:00:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02263 Wed, 24 Jan 2001 14:31:03 -0500 (EST) From: "sankar ramamoorthi" To: Cc: , "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Wed, 24 Jan 2001 11:29:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A6E9DF2.5E5F22C6@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: owner-ipsec@lists.tislabs.com on behalf of Frédéric Detienne >[fd@cisco.com] >Sent: Wednesday, January 24, 2001 1:19 AM >To: sankar ramamoorthi >Cc: sommerfeld@East.Sun.COM; Scott G. Kelly; ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > > >On your side, you still have not explained the shape of your probe packets and the way you protect them (key usage and generation). Can you proceed ? > I will try to address this point. On furthur thinking, I belive the scheme can be refined to avoid timers and minimize delays. The format of the state-synchronization ipsec-control packet I hadin mind was something like (Note: other ipsec-control packets can be defined but they are not interest here). ------------------------------ | ESP-NULL (with reserved spi) | ------------------------------ | ipsec control/error header | ------------------------------ | ESP packet for ipsec-sa of | | interest | ------------------------------ ipsec error header is of the form (similiar to icmp) type | code | checksum type = control or error code is different codes we want to use for the control/error For ipsec-state-synchronization purposes I was visualizing two codes namely recipt-needed specifies that if the encapsulated ipsec packet is successfully processed a recipt should be sent to the peer. The encapsulated ipsec packet is a valid data packet, that should be sent to the upper layers if successfully processed. recipt specified the control packet is a receipt to say that some previously sent receipt-needed packet was successfully processed. The receipt packet is accepted as a valid receipt only it passes successful inbound ipsec processing. The receipt data is not a valid data packet and should not be sent to the upper layers. It should be discarded after processing. Using the above messages ipsec-state synchronization would proceed along these lines. Assume two peers communicating packets over an ipsec tunnel and one peer lost the ipsec-sa-state. peer without the ipsec-sa peer with the possibly state out-of-sync ipsec-sa (1) (on receiving an ipsec packet for which there is no matching ipsec-sa send a 'invalid spi' error in the clear) --------------------------------------------------> (2) on receiving 'invalid spi' error, if the selectors specified in the error, match an exisiting ipsec-sa mark the ipsec-sa with 'MAY-BE-OUT-OF-SYNC' flag and set counter to 0 (2B) If there is data to send and the ipsec-sa has 'MAY-BE-OUT-OF-SYNC' flag set, send the ipsec packet encapsulated in a control packet of type 'receipt-needed'. Increment counter. (3) if a control-packet of type 'receipt-needed' is received, do normal inound-ipsec processing on the encapsulated ipsec packet using the ipsec-sa specified in the control packet. If processing is unsuccessful do not send receipt. If processing is sucessful, pass packet to upper layers and send a receipt to peer. To send a receipt, generate an ip packet containing random data. Do normal outbound ipsec-processing on the packet using the ipsec-sa of interest. Build an ipsec control packet of type 'receipt' and send it to the peer. (4) If an ipsec-control packet of type 'receipt' is recieved, do normal inbound ipsec processing on the packet using the ipsec-sa specified in the control packet. If the ipsec-sa was not found or if if the ipsec-sa is not in 'MAY-BE-OUT-OF-SYNC' state or if the inbound processing was unsuccessful, drop the packet. If processing is successful, reset the counter reset the 'MAY-BE-OUT-OF-SYNC' flag and throw away the data from the decrypted packet. If a valid ipsec packet is received from the peer and if the 'MAY-BE-OUT-OF-SYNC' flag is set clear the flag and reset the counter. If counter has reached a max. value, then it implies the peer is out-of-sync. delete the ipsec-sa There are probably furthur refinements possible to this scheme. But as you can see, it rides on the replay protection scheme provied by ESP and AH protocols, does not add additional overheads in terms of the need to buffer data, timers etc. Now spoofing can occur at step (2), (3) and (4). packets spoofed at step (2) This may cause the receiver of the 'invalid spi' error to incorrectly set the SA in 'MAY-BE-OUT-OF-SYNC' state. This is not much a harm since it sends a 'recipt-needed' control packet only when there is data to be sent to the peer. There are no wasted round-trips since the data is sent in the 'receipt-needed' control packet. packets spoofed at step (2) This may cause an implementation to receive spoofed 'receipt-needed' ipsec control packets. The spoofed packets can be detected because, the encapsulated packet has to match an exisiting ipsec sa, has to be with in the replay window of the inbound-ipsec sa and has to be sucessfully processed for inbound-ipsec-processing. packets spoofed at step (3) This may cause an implementation to receive spoofed 'receipt' ipsec packets. Agains spoofed packets can be detected because, the encapsulated packet has to match an existing ipsec sa, has to with in the replay window of the inbound ipsec-sa and has to be sucessfully processed for inbound-ipsec processing. There are no timers maintained since the 'receipt-needed' packets are sent only when there is data to be sent. The overhead is the processing of valid 'receipt' packets. An attacker can induce a lot of them to be generated by spoofing a lot of 'invalid spi' packets which could force the communicating parties to go through step 2), 3) and 4). This is somewhat minimized if there is bidirectional communication since in that case a normal ipsec packet would act like a receipt. In the case of unidirectional traffic, the sender may receive a lot of valid receipt packets. This would have to be minimized by rate limiting. Welcome your comments on the described approach -- sankar -- >Regards, > > frederic detienne From owner-ipsec@lists.tislabs.com Wed Jan 24 13:01:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17220; Wed, 24 Jan 2001 13:01:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02279 Wed, 24 Jan 2001 14:36:47 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <3A6E4ABA.C6866A4F@storm.ca> References: <20010123212432.94DCB35C42@smb.research.att.com> <3A6E4ABA.C6866A4F@storm.ca> Date: Wed, 24 Jan 2001 09:30:29 -0500 To: Sandy Harris From: Stephen Kent Subject: Re: Increased sequence number in ESP/AH Cc: "'ipsec@lists.tislabs.com'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sandy, >"Steven M. Bellovin" wrote: > > > > In message <3A6DF166.60200CD1@columbia.sparta.com>, Andrea >Colegrove writes: > > >Steve, > > > How does this address freshness (anti-replay)? > > > > > > Is this intended only as a useful feature for high-speed >devices that may > > >need additional SA lifetime? > > > > > > > OC-192 -- deployed in some of today's backbones -- is roughly 1 > > gigabyte/second. Multiply by whatever you think is the average packet > > size, and multiply again by 4 -- but it's not a large number for the > > duration of an SA. > > > > --Steve Bellovin, http://www.research.att.com/~smb > >Yes, but do we expect those backbone devices to be doing IPSEC? >Perhaps a limited >amount for management functions -- remote admin login, ICMP, routing >protocols -- >but I wouldn't expect them to be doing it for bulk traffic. > >Methinks bulk traffic encryption needs to be as near end-to-end as >practical, if not >on the end user systems, then on local routers and firewalls. Almost >by definition, >that excludes backbone routers. You want them just shuffling >packets. Routing is >hard enough without adding IPSEC to that mix. > >OC-3 is the largest pipe I'd expect near enough to the edges that we >want to see >IPSEC on it. 155 Mbit/sec, ~ 20 Mbyte, certainly less than 1 M packets/sec, so >over an hour between re-keyinga. No problem. > >If we're contemplating any changes to the protocol, we want some that bring us >nearer to the end-to-end goal, IPSEC on end-point systems. Some of my clients anticipate OC 192 pipes to their sites in the next couple fo years, if not sooner, and thus a security gateway at the periphery of such sites needs to be able to deal with very high speed flows of the sort that motivate this proposal. steve From owner-ipsec@lists.tislabs.com Wed Jan 24 13:05:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA17911; Wed, 24 Jan 2001 13:05:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA02343 Wed, 24 Jan 2001 14:59:00 -0500 (EST) To: "sankar ramamoorthi" Cc: , , "Scott G. Kelly" , Subject: Re: ipsec error protocol References: From: Derek Atkins Date: 24 Jan 2001 15:01:35 -0500 In-Reply-To: "sankar ramamoorthi"'s message of "Wed, 24 Jan 2001 11:29:39 -0800" Message-ID: Lines: 219 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk But this doesn't help. If one of your hosts rebooted and lost it's SA state, it will receive this message and then do what? The 'ipsec-sa of interest' wont exist, and even if it did, the rebooted host would have lost all state from its peer so it wont have any keying information with which to decrypt the inside ESP packet. So, what does this buy you? Worse, as there is no authentication of this packet, an attacker could cause you to believe that you have stale information. All they have to do is send a message with a 'garbage' inside ESP with a known 'ipsec-sa of interest' and your host will think there is a state error. My question is: in the case of a rebooted host, where is this key information coming from? The ether? Or are you assuming manually-keyed SAs? -derek "sankar ramamoorthi" writes: > I will try to address this point. > > On furthur thinking, I belive the scheme can be refined to avoid > timers and minimize delays. > > The format of the state-synchronization ipsec-control packet I hadin mind > was > something like (Note: other ipsec-control packets can be defined but they > are > not interest here). > > ------------------------------ > | ESP-NULL (with reserved spi) | > ------------------------------ > | ipsec control/error header | > ------------------------------ > | ESP packet for ipsec-sa of | > | interest | > ------------------------------ > > > ipsec error header is of the form (similiar to icmp) > > type | code | checksum > > > type =3D control or error > code is different codes we want to use for the control/error > > For ipsec-state-synchronization purposes I was visualizing two > codes namely > > recipt-needed > specifies that if the encapsulated ipsec packet is successfully > processed a recipt should be sent to the peer. The encapsulated > ipsec packet is a valid data packet, that should be sent to the > upper layers if successfully processed. > > recipt > specified the control packet is a receipt to say that > some previously sent receipt-needed packet was successfully > processed. The receipt packet is accepted as a valid receipt > only it passes successful inbound ipsec processing. The > receipt data is not a valid data packet and should not be > sent to the upper layers. It should be discarded after processing. > > Using the above messages ipsec-state synchronization would proceed > along these lines. > > Assume two peers communicating packets over an ipsec tunnel and > one peer lost the ipsec-sa-state. > > peer without the ipsec-sa peer with the possibly > state out-of-sync ipsec-sa > > > (1) > (on receiving an ipsec packet > for which there is no matching ipsec-sa > send a 'invalid spi' error in the clear) > > --------------------------------------------------> > (2) > on receiving 'invalid spi' > error, if the selectors > specified in the error, > match an exisiting ipsec-sa > mark the ipsec-sa with > 'MAY-BE-OUT-OF-SYNC' flag > and set counter to 0 > > > (2B) > If there is data to send and > the ipsec-sa has > 'MAY-BE-OUT-OF-SYNC' flag set= > , > send the ipsec packet > encapsulated > in a control packet of type > 'receipt-needed'. Increment > counter. > > (3) > if a control-packet of type > 'receipt-needed' is received, > do normal inound-ipsec processing > on the encapsulated ipsec packet > using the ipsec-sa specified in > the control packet. If processing > is unsuccessful do not send receipt. > If processing is sucessful, pass > packet to upper layers and send > a receipt to peer. > > To send a receipt, generate an > ip packet containing random data. > Do normal outbound ipsec-processing > on the packet using the ipsec-sa > of interest. Build an ipsec control > packet of type 'receipt' and send it > to the peer. > (4) > If an ipsec-control packet of > type 'receipt' is recieved, > do normal inbound ipsec > processing on the packet using > the ipsec-sa specified in the > control packet. If the ipsec-s= > a > was not found or if if the > ipsec-sa > is not in 'MAY-BE-OUT-OF-SYNC' > state or if the inbound > processing was unsuccessful, > drop the packet. If processing > is successful, reset the count= > er > reset the 'MAY-BE-OUT-OF-SYNC' > flag and throw away the data > from the decrypted packet. > > > If a valid ipsec packet is > received from the peer and if = > the > 'MAY-BE-OUT-OF-SYNC' flag is s= > et > clear the flag and reset the > counter. > > > If counter has reached a max. > value, then it implies the pee= > r > is out-of-sync. delete the > ipsec-sa > > > There are probably furthur refinements possible to this scheme. > But as you can see, it rides on the replay protection scheme provied > by ESP and AH protocols, does not add additional overheads in terms > of the need to buffer data, timers etc. > > Now spoofing can occur at step (2), (3) and (4). > > packets spoofed at step (2) > > This may cause the receiver of the 'invalid spi' error to incorrectly > set the SA in 'MAY-BE-OUT-OF-SYNC' state. This is not much a harm > since it sends a 'recipt-needed' control packet only when there is > data to be sent to the peer. There are no wasted round-trips since > the data is sent in the 'receipt-needed' control packet. > > packets spoofed at step (2) > > This may cause an implementation to receive spoofed 'receipt-needed' ipse= > c > control packets. The spoofed packets can be detected because, > the encapsulated packet has to match an exisiting ipsec sa, > has to be with in the replay window of the inbound-ipsec sa and has to > be sucessfully processed for inbound-ipsec-processing. > > packets spoofed at step (3) > > This may cause an implementation to receive spoofed 'receipt' ipsec > packets. Agains spoofed packets can be detected because, the encapsulated > packet has to match an existing ipsec sa, has to with in the replay windo= > w > of the inbound ipsec-sa and has to be sucessfully processed for > inbound-ipsec processing. > > There are no timers maintained since the 'receipt-needed' packets are > sent only when there is data to be sent. > > The overhead is the processing of valid 'receipt' packets. > An attacker can induce a lot of them to be generated by spoofing > a lot of 'invalid spi' packets which could force the communicating > parties to go through step 2), 3) and 4). This is somewhat minimized > if there is bidirectional communication since in that case a normal > ipsec packet would act like a receipt. In the case of unidirectional > traffic, the sender may receive a lot of valid receipt packets. > This would have to be minimized by rate limiting. > > Welcome your comments on the described approach > > -- sankar -- > > >Regards, > > > > frederic detienne > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jan 24 16:15:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA27752; Wed, 24 Jan 2001 16:15:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02836 Wed, 24 Jan 2001 17:56:05 -0500 (EST) To: "sankar ramamoorthi" Cc: , , "Scott G. Kelly" , Subject: Re: ipsec error protocol References: From: Derek Atkins Date: 24 Jan 2001 17:58:51 -0500 In-Reply-To: "sankar ramamoorthi"'s message of "Wed, 24 Jan 2001 14:29:35 -0800" Message-ID: Lines: 40 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "sankar ramamoorthi" writes: > I think there is some confusion here. The 'invalid spi' is sent > by the host which has lost the SA state (because of reboot or > other means) and received by one trying to send data. > > The rebooted host does not have to worry about the decrypting > the inside ESP packets. It will drop the 'receipt-needed' packets > and the sending host will detect the condition after sending a few packets. Ok, so hosts A and B have IPSec SAs, but B is generally communicating with A, with A rarely having anything to say except in response to B. A reboots, losing all state. B sends an ESP packet to A. A doesn't understand it, so it builds an invalid spi message to send back to B. B sees the invalid spi message and knows it needs to rekey before it can send anything to A. Is this what you envision? > Yes - there is no authentication of the 'invalid spi' message. > But there are ways to ensure the message is genuine. At the first > level, the 'invalid spi' message can be made to carry some information > about the packet it received (8 bytes just as in icmp). That information > can contain the spi and sequence of the packet for which 'invalid spi' > is being generated. This can be used the receiver of the 'invalid spi' > to ensure that the message is reasonably genuine. It still is possible > that the message has been spoofed. The ipsec control packets > 'recipt-needed' and 'recipt' as described in the scheme can be used > to ensure the message was really genuine. Assuming my last interpretation is correct, an attacker can force a pair of hosts to rekey just by forging an invalid spi message. All they need to do is be able to copy an ESP packet off the wire and then build an invalid spi message around it. There is no proof that the invalid spi actually came from the intended recipient. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jan 24 16:15:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA27803; Wed, 24 Jan 2001 16:15:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA02777 Wed, 24 Jan 2001 17:31:21 -0500 (EST) From: "sankar ramamoorthi" To: "Derek Atkins" Cc: , , "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Wed, 24 Jan 2001 14:29:35 -0800 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >To: Derek Atkins >Cc: fd@cisco.com; sommerfeld@East.Sun.COM; Scott G. Kelly; >ipsec@lists.tislabs.com >Subject: RE: ipsec error protocol > > > > >-----Original Message----- >From: owner-ipsec@lists.tislabs.com >[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Derek Atkins >Sent: Wednesday, January 24, 2001 12:02 PM >To: sankar ramamoorthi >Cc: fd@cisco.com; sommerfeld@East.Sun.COM; Scott G. Kelly; >ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > > >But this doesn't help. If one of your hosts rebooted and lost it's SA >state, it will receive this message and then do what? The 'ipsec-sa By message do you mean the 'invalid spi' message? If the host does not have the SA state corresponding to the 'invalid spi' message it will ignore the message. >of interest' wont exist, and even if it did, the rebooted host would >have lost all state from its peer so it wont have any keying >information with which to decrypt the inside ESP packet. So, what >does this buy you? I think there is some confusion here. The 'invalid spi' is sent by the host which has lost the SA state (because of reboot or other means) and received by one trying to send data. The rebooted host does not have to worry about the decrypting the inside ESP packets. It will drop the 'receipt-needed' packets and the sending host will detect the condition after sending a few packets. > >Worse, as there is no authentication of this packet, an attacker could >cause you to believe that you have stale information. All they have >to do is send a message with a 'garbage' inside ESP with a known >'ipsec-sa of interest' and your host will think there is a state >error. By packet, I assume you imply 'invalid spi' packet. Yes - there is no authentication of the 'invalid spi' message. But there are ways to ensure the message is genuine. At the first level, the 'invalid spi' message can be made to carry some information about the packet it received (8 bytes just as in icmp). That information can contain the spi and sequence of the packet for which 'invalid spi' is being generated. This can be used the receiver of the 'invalid spi' to ensure that the message is reasonably genuine. It still is possible that the message has been spoofed. The ipsec control packets 'recipt-needed' and 'recipt' as described in the scheme can be used to ensure the message was really genuine. > >My question is: in the case of a rebooted host, where is this key >information coming from? The ether? Or are you assuming >manually-keyed SAs? Again, the rebooted host does not have to worry about the failed SAs or key information in the failed SA. > >-derek > >"sankar ramamoorthi" writes: > >> I will try to address this point. >> >> On furthur thinking, I belive the scheme can be refined to avoid >> timers and minimize delays. >> >> The format of the state-synchronization ipsec-control packet I hadin mind >> was >> something like (Note: other ipsec-control packets can be defined but they >> are >> not interest here). >> >> ------------------------------ >> | ESP-NULL (with reserved spi) | >> ------------------------------ >> | ipsec control/error header | >> ------------------------------ >> | ESP packet for ipsec-sa of | >> | interest | >> ------------------------------ >> >> >> ipsec error header is of the form (similiar to icmp) >> >> type | code | checksum >> >> >> type =3D control or error >> code is different codes we want to use for the control/error >> >> For ipsec-state-synchronization purposes I was visualizing two >> codes namely >> >> recipt-needed >> specifies that if the encapsulated ipsec packet is successfully >> processed a recipt should be sent to the peer. The encapsulated >> ipsec packet is a valid data packet, that should be sent to the >> upper layers if successfully processed. >> >> recipt >> specified the control packet is a receipt to say that >> some previously sent receipt-needed packet was successfully >> processed. The receipt packet is accepted as a valid receipt >> only it passes successful inbound ipsec processing. The >> receipt data is not a valid data packet and should not be >> sent to the upper layers. It should be discarded after processing. >> >> Using the above messages ipsec-state synchronization would proceed >> along these lines. >> >> Assume two peers communicating packets over an ipsec tunnel and >> one peer lost the ipsec-sa-state. >> >> peer without the ipsec-sa peer with the possibly >> state out-of-sync ipsec-sa >> >> >> (1) >> (on receiving an ipsec packet >> for which there is no matching ipsec-sa >> send a 'invalid spi' error in the clear) >> >> --------------------------------------------------> >> (2) >> on receiving 'invalid spi' >> error, if the selectors >> specified in the error, >> match an exisiting ipsec-sa >> mark the ipsec-sa with >> 'MAY-BE-OUT-OF-SYNC' flag >> and set counter to 0 >> >> >> (2B) >> If there is data to send and >> the ipsec-sa has >> 'MAY-BE-OUT-OF-SYNC' flag set= >> , >> send the ipsec packet >> encapsulated >> in a control packet of type >> 'receipt-needed'. Increment >> counter. >> >> (3) >> if a control-packet of type >> 'receipt-needed' is received, >> do normal inound-ipsec processing >> on the encapsulated ipsec packet >> using the ipsec-sa specified in >> the control packet. If processing >> is unsuccessful do not send receipt. >> If processing is sucessful, pass >> packet to upper layers and send >> a receipt to peer. >> >> To send a receipt, generate an >> ip packet containing random data. >> Do normal outbound ipsec-processing >> on the packet using the ipsec-sa >> of interest. Build an ipsec control >> packet of type 'receipt' and send it >> to the peer. >> (4) >> If an ipsec-control packet of >> type 'receipt' is recieved, >> do normal inbound ipsec >> processing on the packet using >> the ipsec-sa specified in the >> control packet. If the ipsec-s= >> a >> was not found or if if the >> ipsec-sa >> is not in 'MAY-BE-OUT-OF-SYNC' >> state or if the inbound >> processing was unsuccessful, >> drop the packet. If processing >> is successful, reset the count= >> er >> reset the 'MAY-BE-OUT-OF-SYNC' >> flag and throw away the data >> from the decrypted packet. >> >> >> If a valid ipsec packet is >> received from the peer and if = >> the >> 'MAY-BE-OUT-OF-SYNC' flag is s= >> et >> clear the flag and reset the >> counter. >> >> >> If counter has reached a max. >> value, then it implies the pee= >> r >> is out-of-sync. delete the >> ipsec-sa >> >> >> There are probably furthur refinements possible to this scheme. >> But as you can see, it rides on the replay protection scheme provied >> by ESP and AH protocols, does not add additional overheads in terms >> of the need to buffer data, timers etc. >> >> Now spoofing can occur at step (2), (3) and (4). >> >> packets spoofed at step (2) >> >> This may cause the receiver of the 'invalid spi' error to incorrectly >> set the SA in 'MAY-BE-OUT-OF-SYNC' state. This is not much a harm >> since it sends a 'recipt-needed' control packet only when there is >> data to be sent to the peer. There are no wasted round-trips since >> the data is sent in the 'receipt-needed' control packet. >> >> packets spoofed at step (2) >> >> This may cause an implementation to receive spoofed 'receipt-needed' ipse= >> c >> control packets. The spoofed packets can be detected because, >> the encapsulated packet has to match an exisiting ipsec sa, >> has to be with in the replay window of the inbound-ipsec sa and has to >> be sucessfully processed for inbound-ipsec-processing. >> >> packets spoofed at step (3) >> >> This may cause an implementation to receive spoofed 'receipt' ipsec >> packets. Agains spoofed packets can be detected because, the encapsulated >> packet has to match an existing ipsec sa, has to with in the replay windo= >> w >> of the inbound ipsec-sa and has to be sucessfully processed for >> inbound-ipsec processing. >> >> There are no timers maintained since the 'receipt-needed' packets are >> sent only when there is data to be sent. >> >> The overhead is the processing of valid 'receipt' packets. >> An attacker can induce a lot of them to be generated by spoofing >> a lot of 'invalid spi' packets which could force the communicating >> parties to go through step 2), 3) and 4). This is somewhat minimized >> if there is bidirectional communication since in that case a normal >> ipsec packet would act like a receipt. In the case of unidirectional >> traffic, the sender may receive a lot of valid receipt packets. >> This would have to be minimized by rate limiting. >> >> Welcome your comments on the described approach >> >> -- sankar -- >> >> >Regards, >> > >> > frederic detienne >> > >-- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Jan 24 17:49:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA00506; Wed, 24 Jan 2001 17:49:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA03051 Wed, 24 Jan 2001 19:35:20 -0500 (EST) Message-Id: <200101250037.f0P0bt5127600@thunk.east.sun.com> From: Bill Sommerfeld To: "sankar ramamoorthi" cc: "Derek Atkins" , fd@cisco.com, sommerfeld@East.Sun.COM, "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol In-reply-to: Your message of "Wed, 24 Jan 2001 15:58:06 PST." Reply-to: sommerfeld@East.Sun.COM Date: Wed, 24 Jan 2001 19:37:55 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > B sees the invalid spi messages, > goes through few levels of steps to assure itself the message > is genuine and then rekeys. what exactly does B do to validate the message? please show your work. - Bill From owner-ipsec@lists.tislabs.com Wed Jan 24 18:44:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA02174; Wed, 24 Jan 2001 18:44:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA03273 Wed, 24 Jan 2001 20:42:12 -0500 (EST) From: "sankar ramamoorthi" To: "Derek Atkins" Cc: , , "Scott G. Kelly" , Subject: RE: ipsec error protocol Date: Wed, 24 Jan 2001 15:58:06 -0800 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: Derek Atkins [warlord@MIT.EDU] >Sent: Wednesday, January 24, 2001 2:59 PM >To: sankar ramamoorthi >Cc: fd@cisco.com; sommerfeld@East.Sun.COM; Scott G. Kelly; >ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >"sankar ramamoorthi" writes: > >> I think there is some confusion here. The 'invalid spi' is sent >> by the host which has lost the SA state (because of reboot or >> other means) and received by one trying to send data. >> >> The rebooted host does not have to worry about the decrypting >> the inside ESP packets. It will drop the 'receipt-needed' packets >> and the sending host will detect the condition after sending a few packets. > >Ok, so hosts A and B have IPSec SAs, but B is generally communicating >with A, with A rarely having anything to say except in response to B. >A reboots, losing all state. B sends an ESP packet to A. A doesn't >understand it, so it builds an invalid spi message to send back to B. >B sees the invalid spi message and knows it needs to rekey before it >can send anything to A. Is this what you envision? Yes with minor correction, B sees the invalid spi messages, goes through few levels of steps to assure itself the message is genuine and then rekeys. > >> Yes - there is no authentication of the 'invalid spi' message. >> But there are ways to ensure the message is genuine. At the first >> level, the 'invalid spi' message can be made to carry some information >> about the packet it received (8 bytes just as in icmp). That information >> can contain the spi and sequence of the packet for which 'invalid spi' >> is being generated. This can be used the receiver of the 'invalid spi' >> to ensure that the message is reasonably genuine. It still is possible >> that the message has been spoofed. The ipsec control packets >> 'recipt-needed' and 'recipt' as described in the scheme can be used >> to ensure the message was really genuine. > >Assuming my last interpretation is correct, an attacker can force a >pair of hosts to rekey just by forging an invalid spi message. All >they need to do is be able to copy an ESP packet off the wire and then >build an invalid spi message around it. There is no proof that the >invalid spi actually came from the intended recipient. > Assuming he can send the forged 'invalid spi' packet in some reasonable time window from which the original ESP packet was sent. Yes, detection of the forged 'invalid spi message' is the problem to be solved. That is why the receiver of the 'invalid spi' has to take some extra steps to ensure the 'invalid spi' actually came from the intended recipient before rekeying. The suggested approach outlines ways to do that. OR find ways to ensure the 'invalid spi' message is always authenticated (as in the solution proposed by Bill Sommerfeld and Fredric detienne). OR some variations of these (as in keepalive based solutions proposed in the draft by Andrew krywaniuk and others). -- sankar -- >-derek >-- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jan 25 01:01:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA02718; Thu, 25 Jan 2001 01:01:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA03895 Thu, 25 Jan 2001 02:26:48 -0500 (EST) Message-ID: <3A6FD6E4.93F510EE@cisco.com> Date: Thu, 25 Jan 2001 08:33:56 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sankar ramamoorthi CC: Derek Atkins , sommerfeld@East.Sun.COM, "Scott G. Kelly" , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk notice that you made a lot of progress. Your "slight changes" actually shift the original paradigm from a "keepaplive in disguise" into "acknowledgement in disguise". Take my first emails and re-read: acknowledgments are better. Your problem is that you really want to trigger this with an "invalid SPI" message. And you come up with pretty fancy packets. Not that I do not like them (they're a valid vector after all) but now your philosophically correct pseudo-ICMP's tunnel data :) Question: what if every ESP (for instance) packet would piggy back an acknowledgement field (in both direction) ? That would solve quite a few issues, no ? And would also be much more efficient. One more thing: with acknowledgments alone, there are still possible DoS. All that will be in the draft I am cooking up but it is all about this: . my "invalid SPI notification" variant (i.e. within an IKE offer) may not work when under DoS. (flooding and rate limiting may prevent a good "invalid SPI" from being sent). BUT I do not restart IKE unduly, which is good. Bill Sommerfeld's CoB makes recovery faster.. . acknowledgements are good but a) slower than direct notifications (need several lost packets, difficult to restart at the right place (phase 1 or phase 2)), b) if uncontrolled, may restart IKE for nothing. E.g., Under a DoS, genuine ESP packets with a valid seq# may not reach the destination which in turn could not acknowledge them => forcing an undue rekey. In order to avoid undue rekeying within the acknowledgements scheme, the peers lacking the acknowledgment send an initialization offer saying: CKi | SA offers | "because you do not have inbound SPI xxx" If the recipient DOES have SPI xxx, it simply does not respond to the offer. Well, there are some more things (no details here) but you got the idea. I believe that notifications are good (fast and robust) in environments where flooding and such things do not happen (a private Frame Relay network or a direct link for instance). Acknowledgments are certainly suitable for Internet like medium. These two methods work together but I would suggest that they can be turned on/off independently. regards, frederic detienne sankar ramamoorthi wrote: > > >From: Derek Atkins [warlord@MIT.EDU] > >Sent: Wednesday, January 24, 2001 2:59 PM > >To: sankar ramamoorthi > >Cc: fd@cisco.com; sommerfeld@East.Sun.COM; Scott G. Kelly; > >ipsec@lists.tislabs.com > >Subject: Re: ipsec error protocol > > > >"sankar ramamoorthi" writes: > > > >> I think there is some confusion here. The 'invalid spi' is sent > >> by the host which has lost the SA state (because of reboot or > >> other means) and received by one trying to send data. > >> > >> The rebooted host does not have to worry about the decrypting > >> the inside ESP packets. It will drop the 'receipt-needed' packets > >> and the sending host will detect the condition after sending a few > packets. > > > >Ok, so hosts A and B have IPSec SAs, but B is generally communicating > >with A, with A rarely having anything to say except in response to B. > >A reboots, losing all state. B sends an ESP packet to A. A doesn't > >understand it, so it builds an invalid spi message to send back to B. > >B sees the invalid spi message and knows it needs to rekey before it > >can send anything to A. Is this what you envision? > > Yes with minor correction, > > B sees the invalid spi messages, > goes through few levels of steps to assure itself the message > is genuine and then rekeys. > > > > >> Yes - there is no authentication of the 'invalid spi' message. > >> But there are ways to ensure the message is genuine. At the first > >> level, the 'invalid spi' message can be made to carry some information > >> about the packet it received (8 bytes just as in icmp). That information > >> can contain the spi and sequence of the packet for which 'invalid spi' > >> is being generated. This can be used the receiver of the 'invalid spi' > >> to ensure that the message is reasonably genuine. It still is possible > >> that the message has been spoofed. The ipsec control packets > >> 'recipt-needed' and 'recipt' as described in the scheme can be used > >> to ensure the message was really genuine. > > > >Assuming my last interpretation is correct, an attacker can force a > >pair of hosts to rekey just by forging an invalid spi message. All > >they need to do is be able to copy an ESP packet off the wire and then > >build an invalid spi message around it. There is no proof that the > >invalid spi actually came from the intended recipient. > > > > Assuming he can send the forged 'invalid spi' packet in some reasonable > time window from which the original ESP packet was sent. > > Yes, detection of the forged 'invalid spi message' is the problem to be > solved. > That is why the receiver of the 'invalid spi' has to take some > extra steps to ensure the 'invalid spi' actually came from the > intended recipient before rekeying. The suggested approach outlines > ways to do that. > > OR > > find ways to ensure the 'invalid spi' message is always authenticated > (as in the solution proposed by Bill Sommerfeld and Fredric detienne). > > OR > > some variations of these (as in keepalive based solutions proposed in > the draft by Andrew krywaniuk and others). > > -- sankar -- > > >-derek > >-- > > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > > Member, MIT Student Information Processing Board (SIPB) > > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Jan 25 01:57:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA09538; Thu, 25 Jan 2001 01:57:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA04066 Thu, 25 Jan 2001 03:36:21 -0500 (EST) From: "sankar ramamoorthi" To: Subject: FW: ipsec error protocol Date: Thu, 25 Jan 2001 00:35:13 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----Original Message----- From: sankar ramamoorthi [mailto:sankar@nexsi.com] Sent: Wednesday, January 24, 2001 9:58 PM To: sommerfeld@East.Sun.COM Subject: RE: ipsec error protocol >From: owner-ipsec@lists.tislabs.com on behalf of Bill Sommerfeld >[sommerfeld@East.Sun.COM] >Sent: Wednesday, January 24, 2001 4:38 PM >To: sankar ramamoorthi >Cc: Derek Atkins; fd@cisco.com; sommerfeld@East.Sun.COM; Scott G. Kelly; >ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >> B sees the invalid spi messages, >> goes through few levels of steps to assure itself the message >> is genuine and then rekeys. > >what exactly does B do to validate the message? > >please show your work. > > - Bill B goes through the following steps to assure itself the message is genuine I am assuming the 'invalid spi' notice is in the clear. I am also assuming ipsec error protocol can be used to define the 'invalid spi' and the message is of the form ------------------------------ | ESP-NULL (with reserved spi) | ------------------------------ | ipsec control/error header | ------------------------------ | 8 bytes of the ESP packet for| | which there was no ipsec-sa | ------------------------------ **note**: An icmp error also could have been used for sending the 'invalid spi' message, though the error code would have to be agreed upon. 1. Derive the sequence number and SPI from the error packet. This is retrieved from the information about the offending ESP packet that was saved in the ipsec error packet. 2. Check if there is an outbound ipsec-SA with the matching SPI. If not ignore the error 3. Check if the sequence number in the error packet is within a resonable window of the outbound ipsec packet replay sequence number. If not ignore the packet. To cross this point the attacker has to be really be sophisticated. Not only he has to sniff and spoof the packet, but also send the 'invalid spi' message in a short time window. This level of assurance may be enough for some hosts. If it is not enough the following steps can provide furthur assurance. Detailed description of the messages involved (posted earlier) is also attached. 4. Mark the SA as 'MAY-BE-OUT-OF-SYNC'. On the next data packet to be sent using this ipsec SA, use 'receipt-needed' type of ipsec control packet. Start a counter. 5. If a valid packet is received on the inbound ipsec-sa or a valid 'receipt' type of ipsec-control packet is received for the inbound sa, reset the counter and clear the flag. The 'invalid spi' notification was bogus. 6. If counter reaches n, it implies n packets have been sent using the outbound-sa without receving a 'receipt' or valid data on the inbound-da. There is sufficient assurance that the peer genuinely does not have the ipsec-sa. Delete the ipsec-sa. -------------------------------------------------------------------- Earlier posting describing the ipsec control message exchange The format of the ipsec-control packet I had in mind was something like. ------------------------------ | ESP-NULL (with reserved spi) | ------------------------------ | ipsec control/error header | ------------------------------ | ESP packet for ipsec-sa of | | interest | ------------------------------ ipsec error header is of the form (similiar to icmp) type | code | checksum type = control or error code is different codes we want to use for the control/error For ipsec-state-synchronization purposes I was visualizing two codes namely recipt-needed receipt needed if the encapsulated ipsec packet is successfully processed recipt specified the control packet is a receipt to say that some previously sent receipt-needed packet was successfully processed. Using the above messages ipsec-state synchronization would proceed along these lines. Assume two peers communicating packets over an ipsec tunnel and one peer lost the ipsec-sa-state. peer without the ipsec-sa peer with the possibly state out-of-sync ipsec-sa (1) (on receiving an ipsec packet for which there is no matching ipsec-sa send a 'invalid spi' error in the clear) --------------------------------------------------> (2) on receiving 'invalid spi' error, if the selectors specified in the error, match an exisiting ipsec-sa mark the ipsec-sa with 'MAY-BE-OUT-OF-SYNC' flag and set counter to 0 (2B) If there is data to send and the ipsec-sa has 'MAY-BE-OUT-OF-SYNC' flag set, send the ipsec packet encapsulated in a control packet of type 'receipt-needed'. Increment counter. (3) if a control-packet of type 'receipt-needed' is received, do normal inound-ipsec processing on the encapsulated ipsec packet using the ipsec-sa specified in the control packet. If processing is unsuccessful do not send receipt. If processing is sucessful, pass packet to upper layers and send a receipt to peer. To send a receipt, generate an ip packet containing random data. Do normal outbound ipsec-processing on the packet using the ipsec-sa of interest. Build an ipsec control packet of type 'receipt' and send it to the peer. (4) If an ipsec-control packet of type 'receipt' is recieved, do normal inbound ipsec processing on the packet using the ipsec-sa specified in the control packet. If the ipsec-sa was not found or if if the ipsec-sa is not in 'MAY-BE-OUT-OF-SYNC' state or if the inbound processing was unsuccessful, drop the packet. If processing is successful, reset the counter reset the 'MAY-BE-OUT-OF-SYNC' flag and throw away the data from the decrypted packet. If a valid ipsec packet is received from the peer and if the 'MAY-BE-OUT-OF-SYNC' flag is set clear the flag and reset the counter. If counter has reached a max. value, then it implies the peer is out-of-sync. delete the ipsec-sa There are probably furthur refinements possible to this scheme. But as you can see, it rides on the replay protection scheme provied by ESP and AH protocols, does not add additional overheads in terms of the need to buffer data, timers etc. Now spoofing can occur at step (2), (3) and (4). packets spoofed at step (2) This may cause the receiver of the 'invalid spi' error to incorrectly set the SA in 'MAY-BE-OUT-OF-SYNC' state. This is not much a harm since it sends a 'recipt-needed' control packet only when there is data to be sent to the peer. There are no wasted round-trips since the data is sent in the 'receipt-needed' control packet. packets spoofed at step (2) This may cause an implementation to receive spoofed 'receipt-needed' ipsec control packets. The spoofed packets can be detected because, the encapsulated packet has to match an exisiting ipsec sa, has to be with in the replay window of the inbound-ipsec sa and has to be sucessfully processed for inbound-ipsec-processing. packets spoofed at step (3) This may cause an implementation to receive spoofed 'receipt' ipsec packets. Agains spoofed packets can be detected because, the encapsulated packet has to match an existing ipsec sa, has to with in the replay window of the inbound ipsec-sa and has to be sucessfully processed for inbound-ipsec processing. Welcome your comments on the described approach -- sankar -- From owner-ipsec@lists.tislabs.com Thu Jan 25 02:11:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10881; Thu, 25 Jan 2001 02:11:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA04157 Thu, 25 Jan 2001 03:49:10 -0500 (EST) To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Increased sequence number in ESP/AH Date: 25 Jan 2001 08:50:29 GMT Organization: University of California, Berkeley Lines: 18 Distribution: isaac Message-ID: <94opcl$r1d$6@abraham.cs.berkeley.edu> References: <20010124002945.E45E935C42@smb.research.att.com> <200101241814.KAA21566@potassium.network-alchemy.com> Reply-To: daw@cs.berkeley.edu (David Wagner) NNTP-Posting-Host: mozart.cs.berkeley.edu X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: >Of course. The single 32-bit add is noise. But keeping that counter in >sync is not. How about the following alternate proposal? Does it satisfy your needs? The suggestion is to have receivers be more sophisticated about managing their replay windows. Rather than keeping a single, 32-bit window for 32 consecutive sequence numbers, how about keeping N independent (appropriately spaced out) replay windows, where N counts the degree of parallelism you want at the sender? What I like about this approach is that it doesn't introduce any risk of replay attacks. And, since the original proposal (make replay detection optional & negotiable) already requires changed to both endpoints, this approach is not really any worse in that respect. But I probably didn't quite understand your requirements. Will this work? From owner-ipsec@lists.tislabs.com Thu Jan 25 08:21:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08867; Thu, 25 Jan 2001 08:21:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05124 Thu, 25 Jan 2001 09:54:49 -0500 (EST) Message-ID: <8894CA1F87A5D411BD24009027EE7838127FC2@md-exchange1.nai.com> From: "Mason, David" To: "'Dan Harkins'" , "Steven M. Bellovin" Cc: sommerfeld@East.Sun.COM, "'ipsec@lists.tislabs.com'" Subject: RE: Increased sequence number in ESP/AH Date: Thu, 25 Jan 2001 06:54:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I take it that the next proposal after "allowing replay attacks" would be to change the MUST in RFC2401 with respect to support for volume based lifetime since that value would experience as much contention as the replay counter. -dave From owner-ipsec@lists.tislabs.com Thu Jan 25 12:38:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA28377; Thu, 25 Jan 2001 12:38:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09189 Thu, 25 Jan 2001 13:17:16 -0500 (EST) Message-Id: <200101251819.f0PIJp5132092@thunk.east.sun.com> From: Bill Sommerfeld To: "sankar ramamoorthi" cc: ipsec@lists.tislabs.com Subject: Re: FW: ipsec error protocol In-reply-to: Your message of "Thu, 25 Jan 2001 00:35:13 PST." Reply-to: sommerfeld@East.Sun.COM Date: Thu, 25 Jan 2001 13:19:51 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To cross this point the attacker has to be really be sophisticated. Not only he has to sniff and spoof the packet, but also send the 'invalid spi' message in a short time window. I'm aware of active attack code which does stuff like this already for tcp connections. In addition, a (deliberately or not) misconfigured host along the path which implements your scheme would trivially implement this part of the attack -- just convince it that one of its host addresses is the target's address and arrange for the packet stream to hit its ip_input() or equivalent. 5. If a valid packet is received on the inbound ipsec-sa or a valid 'receipt' type of ipsec-control packet is received for the inbound sa, reset the counter and clear the flag. The 'invalid spi' notification was bogus. This assumes that: a) there is bidirectional traffic flow, and b) the implementation maintains a linkage between the "inbound" and "outbound" SA's Addressing each of these in turn: If you have redundant tunnels and are running dynamic routing over them (and before you dismiss this as unlikely, I know people who have talked seriously about deploying just this), then due the vagaries of dynamic routing, the traffic flow over any given tunnel may be unidirectional.. Existing implementations I'm familiar with don't do (b), and adding this mapping is non-trivial because multiple equivalent SA's may exist between a pair of communicating nodes. - Bill From owner-ipsec@lists.tislabs.com Thu Jan 25 12:49:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29325; Thu, 25 Jan 2001 12:49:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09413 Thu, 25 Jan 2001 14:25:11 -0500 (EST) Message-Id: <200101251920.LAA24702@potassium.network-alchemy.com> To: "Mason, David" cc: "'ipsec@lists.tislabs.com'" Subject: Re: Increased sequence number in ESP/AH In-reply-to: Your message of "Thu, 25 Jan 2001 06:54:09 PST." <8894CA1F87A5D411BD24009027EE7838127FC2@md-exchange1.nai.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24699.980450440.1@network-alchemy.com> Date: Thu, 25 Jan 2001 11:20:40 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let's get this straight. RFC2402 and RFC2406 already provide for "allowing replay attacks". I suggest you read them. I have no idea why volume based lifetimes are causing you pain but it is not my concern. Dan. On Thu, 25 Jan 2001 06:54:09 PST you wrote > I take it that the next proposal after "allowing replay attacks" would be to > change the MUST in RFC2401 with respect to support for volume based lifetime > since that value would experience as much contention as the replay counter. > > -dave From owner-ipsec@lists.tislabs.com Thu Jan 25 16:37:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA13431; Thu, 25 Jan 2001 16:37:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13385 Thu, 25 Jan 2001 18:48:50 -0500 (EST) Message-Id: <200101252344.PAA25699@potassium.network-alchemy.com> To: ipsec@lists.tislabs.com Subject: compliance question MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25696.980466294.1@network-alchemy.com> Date: Thu, 25 Jan 2001 15:44:55 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A question for the protocol police. Section 3.3.3 of RFC2406 says: The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see 3.4.3). Thus, if the counter has cycled, the sender will set up a new SA and key (unless the SA was configured with manual key management). If anti-replay is disabled, the sender does not need to monitor or reset the counter, e.g., in the case of manual key management (see Section 5). However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. Ignoring for the sake of a question whether disabling anti-replay is smart or not, would an implementation be conformant if, when anti-replay is disabled, the sequence number rolled over to zero prior to reaching it's maximum value? That is 1, 2, ... 2^5, 1, 2, etc. Dan. From owner-ipsec@lists.tislabs.com Thu Jan 25 16:37:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA13432; Thu, 25 Jan 2001 16:37:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13371 Thu, 25 Jan 2001 18:30:32 -0500 (EST) Message-Id: <200101252326.PAA25672@potassium.network-alchemy.com> To: daw@cs.berkeley.edu (David Wagner) cc: ipsec@lists.tislabs.com Subject: Re: Increased sequence number in ESP/AH In-reply-to: Your message of "25 Jan 2001 08:50:29 GMT." <94opcl$r1d$6@abraham.cs.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25669.980465164.1@network-alchemy.com> Date: Thu, 25 Jan 2001 15:26:04 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 25 Jan 2001 08:50:29 GMT you wrote > Dan Harkins wrote: > >Of course. The single 32-bit add is noise. But keeping that counter in > >sync is not. > > How about the following alternate proposal? Does it satisfy your needs? > > The suggestion is to have receivers be more sophisticated about managing > their replay windows. Rather than keeping a single, 32-bit window for > 32 consecutive sequence numbers, how about keeping N independent > (appropriately spaced out) replay windows, where N counts the degree of > parallelism you want at the sender? The problem I'm (having trouble) describing is on the sender side. The sender must keep its counter in sync among all the active nodes to whom the work load can be dynamically load-balanced or actively failed-over. A node to whom a workload has just been reassigned has to have fairly accurate knowledge of the counter so it can do that very simple and inexpensive 32bit add (new sequence number = X + 1 but what is X?). Making sure that knowledge is there becomes increasingly expensive at higher throughputs. > What I like about this approach is that it doesn't introduce any risk > of replay attacks. And, since the original proposal (make replay detection > optional & negotiable) already requires changed to both endpoints, this > approach is not really any worse in that respect. Replay detection is already optional for the receiver and there is a way for the receiver to notify the sender that anti-replay has been disabled but regardless the sender must continue to increment the counter. And that (the sender side) is where the problem lies. > But I probably didn't quite understand your requirements. Will this work? I actually think Bill Sommerfeld's suggestion to negotiate multiple equivalent SAs (N SAs for N degrees of parallelism) is better. The trouble of parallelizing the processing is taken out of IPsec and left in the loadbalanceing code. That's seems cleaner and doesn't require changing anything: the receive window and receiver processing is as it was, the sender just does his simple 32bit add for the SA he owns, and IKE can already negotiate N SAs for a particular flow. I'll shelve my proposal for now. Thanks, Dan. From owner-ipsec@lists.tislabs.com Thu Jan 25 16:43:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA13610; Thu, 25 Jan 2001 16:43:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA13421 Thu, 25 Jan 2001 19:00:48 -0500 (EST) To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Increased sequence number in ESP/AH Date: 26 Jan 2001 00:02:08 GMT Organization: University of California, Berkeley Lines: 34 Distribution: isaac Message-ID: <94qeq0$vvb$1@abraham.cs.berkeley.edu> References: <94opcl$r1d$6@abraham.cs.berkeley.edu> <200101252326.PAA25672@potassium.network-alchemy.com> Reply-To: daw@cs.berkeley.edu (David Wagner) NNTP-Posting-Host: mozart.cs.berkeley.edu X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan Harkins wrote: >David Wagner wrote: >> How about keeping N independent >> (appropriately spaced out) replay windows, where N counts the degree of >> parallelism you want at the sender? > >The problem I'm (having trouble) describing is on the sender side. The >sender must keep its counter in sync among all the active nodes to whom >the work load can be dynamically load-balanced or actively failed-over. No, you missed the the point of my proposal. My proposal eliminates the need for the sender's nodes to be in sync. Imagine you have two nodes at the sender. The first node transmits packets with sequence numbers 0,1,2,3,...; the second uses 2^31,2^31+1,2^31+2,...; so they don't need to be in sync. Today's receivers wouldn't be happy to see this, because they have only a single replay window. But, if we introduce two replay windows at the receiver, everything will be fine. The first window will be a 32-bit bitmap of all sequence numbers seen in the range 0..31; the second will cover 2^31..2^31+31; and of course each window range will shift appropriately as packets are received. This proposal has several nice features. First, the security properties of today's IPSEC are preserved. Second, parallelization incurs no overhead at the sender. Third, there's not much burden on the receiver: receivers could start with just one replay window per SA, and introduce extra replay windows only as needed (up to some reasonable limit). By the way, Sommerfeld's suggestion of generating N SA's for N degrees of parallelism sounds even better -- it requires no changes to the standard whatsoever. I had thought that, for some reason, you wanted to keep all the traffic on the same SA, but if you're happy with with Sommerfeld's solution, so much the better! From owner-ipsec@lists.tislabs.com Fri Jan 26 11:59:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA10093; Fri, 26 Jan 2001 11:59:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16212 Fri, 26 Jan 2001 13:35:31 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <94qeq0$vvb$1@abraham.cs.berkeley.edu> References: <94opcl$r1d$6@abraham.cs.berkeley.edu> <200101252326.PAA25672@potassium.network-alchemy.com> <94qeq0$vvb$1@abraham.cs.berkeley.edu> Date: Fri, 26 Jan 2001 13:31:06 -0500 To: daw@cs.berkeley.edu (David Wagner) From: Stephen Kent Subject: Re: Increased sequence number in ESP/AH Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, >Dan Harkins wrote: > >David Wagner wrote: > >> How about keeping N independent > >> (appropriately spaced out) replay windows, where N counts the degree of > >> parallelism you want at the sender? > > > >The problem I'm (having trouble) describing is on the sender side. The > >sender must keep its counter in sync among all the active nodes to whom > >the work load can be dynamically load-balanced or actively failed-over. > >No, you missed the the point of my proposal. My proposal eliminates >the need for the sender's nodes to be in sync. > >Imagine you have two nodes at the sender. The first node transmits >packets with sequence numbers 0,1,2,3,...; the second uses >2^31,2^31+1,2^31+2,...; so they don't need to be in sync. Today's >receivers wouldn't be happy to see this, because they have only a >single replay window. But, if we introduce two replay windows at >the receiver, everything will be fine. The first window will be a >32-bit bitmap of all sequence numbers seen in the range 0..31; the >second will cover 2^31..2^31+31; and of course each window range >will shift appropriately as packets are received. This would work, but it violates the current specs in several ways. We now require for the sender to increment the sequence counter by exactly 1 for each transmitted packet. These packets could be emitted out of order and thus a black box view of the IPsec implementation would suggest an error. Also, as you note, the receiver has to maintain more complex windows, which is not exactly a spec violation, but certainly is a change. I agree with Dan that one would want to negotiate anything like this, first, to make sure the receiver could accommodate it, just like my proposal for extending the sequence number space. I'm not necessarily enthusiastic about folks turning off anti-replay, but if we did have to do that, I would want to do it the way Dan suggested, i.e., default is that the sender generates sequence numbers and assume the receiver checks them, and one has to negotiate with the receiver to not generate sequence numbers. >This proposal has several nice features. First, the security properties >of today's IPSEC are preserved. Second, parallelization incurs no overhead >at the sender. Third, there's not much burden on the receiver: receivers >could start with just one replay window per SA, and introduce extra replay >windows only as needed (up to some reasonable limit). > >By the way, Sommerfeld's suggestion of generating N SA's for N degrees of >parallelism sounds even better -- it requires no changes to the standard >whatsoever. I had thought that, for some reason, you wanted to keep all >the traffic on the same SA, but if you're happy with with Sommerfeld's >solution, so much the better! I'm happy with that too. Steve From owner-ipsec@lists.tislabs.com Fri Jan 26 12:00:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10163; Fri, 26 Jan 2001 12:00:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16319 Fri, 26 Jan 2001 14:01:14 -0500 (EST) Message-ID: <3A71C9E3.9C466165@cisco.com> Date: Fri, 26 Jan 2001 20:02:59 +0100 From: Frederic Detienne Reply-To: fd@cisco.com Organization: Cisco Systems, Inc X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dan Harkins CC: David Wagner , ipsec@lists.tislabs.com Subject: Re: Increased sequence number in ESP/AH References: <200101252326.PAA25672@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: > I actually think Bill Sommerfeld's suggestion to negotiate multiple > equivalent SAs (N SAs for N degrees of parallelism) is better. The trouble > of parallelizing the processing is taken out of IPsec and left in the > loadbalanceing code. That's seems cleaner and doesn't require changing > anything: the receive window and receiver processing is as it was, the > sender just does his simple 32bit add for the SA he owns, and IKE can > already negotiate N SAs for a particular flow. > > I'll shelve my proposal for now. Thanks, > > Dan. It is indeed but by curiosity, what is the difference between negotiating 20 SA's every 20 hours instead of one every hour ? From owner-ipsec@lists.tislabs.com Fri Jan 26 13:31:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15745; Fri, 26 Jan 2001 13:31:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16565 Fri, 26 Jan 2001 15:23:50 -0500 (EST) Date: Fri, 26 Jan 2001 12:22:04 -0800 From: Derrell Piper To: David Wagner , ipsec@lists.tislabs.com Subject: Re: Increased sequence number in ESP/AH Message-ID: <163823.3189500524@el-air-1.electric-loft.org> In-Reply-To: <94qeq0$vvb$1@abraham.cs.berkeley.edu> X-Mailer: Mulberry/2.0.5 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Is there a summary of your presentation you could post for those of us who were unable to attend the last meeting? A couple of comments on replay and clustering. I don't have any problem with 64-bit replay sequence numbers. The math is lost in the noise and the additional sequence space will be needed very soon now. Regarding clustered IPSec SA's, I like Bill's proposal, though I tend to want to try to solve the problem with a single SA (pair). However, something like a simple negotiated replay window set is also problematic when you allow your clusters to dynamically resize (as we do). You'd have to provide a mechanism to negotiate a new replay window when you added another node not present during the initial negotation. The beauty of Bill's proposal is that this is just another Quick Mode. However, this will cost us O(n) in IPSec SA memory usage, where 'n' is the size of a cluster, given our failover guarantees. We currently achieve our 250ms failover in O(1) IPSec SA memory usage. This isn't very appealing to us when you consider that we support 20K+ tunnels in our high end systems. On the third hand (:-), it's just memory. How about this: 1) add a replay 'flow id' to the ESP header or trailer and include it in the integrity check 2) require the receiver to support multiple replay windows, per SA, indexed by flow id 3) require that the flow id be unique for the lifetime of the SA and forbid reuse of flow id's 4) require the receiver to switch to a new replay window upon receipt of an unknown flow id This allows the sender to start transmiting on a new replay window following load-balancing, failover, or a cluster resizing/remastering. With sufficient restrictions, there's no effective security risk. I do think this is an important problem to solve. Despite the advances in COTS hardware acceleration, the only way we're going to deal with increased pipe sizes in the near future is through parallelism/clustering. Derrell --On Friday, January 26, 2001 12:02 AM +0000 David Wagner wrote: > By the way, Sommerfeld's suggestion of generating N SA's for N degrees of > parallelism sounds even better -- it requires no changes to the standard > whatsoever. I had thought that, for some reason, you wanted to keep all > the traffic on the same SA, but if you're happy with with Sommerfeld's > solution, so much the better! From owner-ipsec@lists.tislabs.com Fri Jan 26 18:17:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA26880; Fri, 26 Jan 2001 18:17:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17292 Fri, 26 Jan 2001 19:56:22 -0500 (EST) Date: Fri, 26 Jan 2001 16:58:33 -0800 From: Jason R Thorpe To: ipsec@lists.tislabs.com Subject: Status of draft-ietf-ipsec-isakmp-gss-auth-06.txt Message-ID: <20010126165833.M473@dr-evil.shagadelic.org> Reply-To: thorpej@zembu.com Mail-Followup-To: Jason R Thorpe , ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Organization: Zembu Labs, Inc. Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What's the current status of the aforementioned draft (GSS-API Authentication Method for IKE)? I haven't seen any discussion of it since IETF-49, and the draft itself hasn't changed since July, 2000. I ask because the draft is now basically expired, and as far as I know, none of the temorarily-assigned constants in the draft were set into stone with official assignments. Yes, I know that there is now another proposed Kerberos-based IPsec key exchange mechanism on the table, but there are now multiple implementations of GSS-API for IKE out there (KAME, plus presumably a Microsoft implementation for Windows 2000, at least), so it might be nice for some forward movement on the draft to happen (make an informational RFC out of it to document existing practice?). -- -- Jason R. Thorpe From owner-ipsec@lists.tislabs.com Sat Jan 27 20:56:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19601; Sat, 27 Jan 2001 20:56:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA20075 Sat, 27 Jan 2001 22:49:18 -0500 (EST) From: "sankar ramamoorthi" To: Cc: Subject: RE: FW: ipsec error protocol Date: Sat, 27 Jan 2001 19:56:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200101251819.f0PIJp5132092@thunk.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: sommerfeld@thunk.east.sun.com on behalf of Bill Sommerfeld >[sommerfeld@east.sun.com] >Sent: Thursday, January 25, 2001 10:20 AM >To: sankar ramamoorthi >Cc: ipsec@lists.tislabs.com >Subject: Re: FW: ipsec error protocol > > To cross this point the attacker has to be really be sophisticated. > Not only he has to sniff and spoof the packet, but also send the > 'invalid spi' message in a short time window. > >I'm aware of active attack code which does stuff like this already for >tcp connections. > >In addition, a (deliberately or not) misconfigured host along the path >which implements your scheme would trivially implement this part of >the attack -- just convince it that one of its host addresses is the >target's address and arrange for the packet stream to hit its >ip_input() or equivalent. > One thing to note though is if there is a misconfiguration like that it does'nt help a lot since all the follow up communication (like probes, rekeys) to the intended address also will fail, and the problem can be tracked through general network diagnostic mechanisms By 'sophisticated' I meant someone who is able to inject these packets without affecting normal flow of traffic and make the sender do a lot of wasted work without making the problem visible to general network diagnostics. > 5. If a valid packet is received on the inbound ipsec-sa or > a valid 'receipt' type of ipsec-control packet is received for the > inbound sa, reset the counter and clear the flag. The 'invalid spi' > notification was bogus. > >This assumes that: > a) there is bidirectional traffic flow, and not necessarily, since the 'receipt' control packet takes care of the unidirectional traffic - the 'receipt' packets actually generate a bidirectional flow in the absence of any already exisiting bidirectional traffic. > b) the implementation maintains a linkage between the "inbound" and >"outbound" SA's > >Addressing each of these in turn: > >If you have redundant tunnels and are running dynamic routing over >them (and before you dismiss this as unlikely, I know people who have >talked seriously about deploying just this), then due the vagaries of >dynamic routing, the traffic flow over any given tunnel may be >unidirectional.. > >Existing implementations I'm familiar with don't do (b), and adding >this mapping is non-trivial because multiple equivalent SA's may exist >between a pair of communicating nodes. > Yes - this would be a problem. How are the SAs distributed between the pair of communicating nodes? Could'nt the same channel be used to keep information in sync. Yes, it would be non-trivial work in this particular scenario, but so would distribution of SAs. If there is no linkage between inbound and outbound SA then there are other issues as well. If there are multiple SAs with a peer, coordinating the move from a old SA pair to a new SA pair requires coordination between inbound and outbound sa (packets arriving on an inbound sa gives clue that the peer is using that sa pair - Tim Jenkins rekeying draft). -- sankar -- > - Bill From owner-ipsec@lists.tislabs.com Sun Jan 28 20:54:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA27851; Sun, 28 Jan 2001 20:54:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA22777 Sun, 28 Jan 2001 22:26:36 -0500 (EST) Message-Id: <200101290329.f0T3T55151144@thunk.east.sun.com> From: Bill Sommerfeld To: "sankar ramamoorthi" cc: sommerfeld@East.Sun.COM, ipsec@lists.tislabs.com Subject: Re: FW: ipsec error protocol In-reply-to: Your message of "Sat, 27 Jan 2001 19:56:37 PST." Reply-to: sommerfeld@East.Sun.COM Date: Sun, 28 Jan 2001 22:29:05 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >In addition, a (deliberately or not) misconfigured host along the path > >which implements your scheme would trivially implement this part of > >the attack -- just convince it that one of its host addresses is the > >target's address and arrange for the packet stream to hit its > >ip_input() or equivalent. > > > > One thing to note though is if there is a misconfiguration like that > it does'nt help a lot since all the follow up communication > (like probes, rekeys) to the intended address also will fail, and the > problem can be tracked through general network diagnostic mechanisms a host misconfigured like that caused serious chaos and confusion on the wireless network last IETF, and I don't think it was ever conclusively identified. > >Existing implementations I'm familiar with don't do (b), and adding > >this mapping is non-trivial because multiple equivalent SA's may exist > >between a pair of communicating nodes. > > Yes - this would be a problem. > > How are the SAs distributed between the pair of communicating nodes? IKE. > Could'nt the same channel be used to keep information in sync. We were discussing how to extend ike to allow for this when you claimed it was a layering violation. - Bill From owner-ipsec@lists.tislabs.com Mon Jan 29 11:50:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19025; Mon, 29 Jan 2001 11:50:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25099 Mon, 29 Jan 2001 13:54:12 -0500 (EST) From: "sankar ramamoorthi" To: Cc: Subject: RE: FW: ipsec error protocol Date: Mon, 29 Jan 2001 11:01:33 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200101290329.f0T3T55151144@thunk.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >To: sommerfeld@east.sun.com >Cc: ipsec@lists.tislabs.com >Subject: RE: FW: ipsec error protocol > > > >-----Original Message----- >From: sommerfeld@thunk.east.sun.com >[mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld >Sent: Sunday, January 28, 2001 7:29 PM >To: sankar ramamoorthi >Cc: sommerfeld@east.sun.com; ipsec@lists.tislabs.com >Subject: Re: FW: ipsec error protocol > > > >> >Existing implementations I'm familiar with don't do (b), and adding >> >this mapping is non-trivial because multiple equivalent SA's may exist >> >between a pair of communicating nodes. >> >> Yes - this would be a problem. >> >> How are the SAs distributed between the pair of communicating nodes? > >IKE. I think there is some context missing here. What I said was w.r.to the following comment >>> b) the implementation maintains a linkage between the "inbound" and >>>"outbound" SA's >>> >>>Addressing each of these in turn: >> >>>If you have redundant tunnels and are running dynamic routing over >>>them (and before you dismiss this as unlikely, I know people who have >>>talked seriously about deploying just this), then due the vagaries of >>>dynamic routing, the traffic flow over any given tunnel may be >>>unidirectional.. >> >>>Existing implementations I'm familiar with don't do (b), and adding >>>this mapping is non-trivial because multiple equivalent SA's may exist >>>between a pair of communicating nodes. >> I presumed that when you were talking about separation of inbound SA and outbound SA, you are discussing some kind of fault-tolerant system where the multiple negotiated SAs are distributed to backup(s) and some kind of separation between inbound and outbound SA is also maintained for loadbalancing purposes between primary and backup(s). >> Could'nt the same channel be used to keep information in sync. > >We were discussing how to extend ike to allow for this when you >claimed it was a layering violation. By channel, I meant the FT channel (see my assumptions above). Yes, I still feel that we should first try to fix ipsec problem at ipsec level. -- sankar -- From owner-ipsec@lists.tislabs.com Mon Jan 29 11:50:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19048; Mon, 29 Jan 2001 11:50:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA25055 Mon, 29 Jan 2001 13:34:59 -0500 (EST) From: "sankar ramamoorthi" To: Cc: , , Subject: Re: ipsec error protocol Date: Mon, 29 Jan 2001 10:42:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Apologize for the late response. Got tied up in something else. >From: owner-ipsec@lists.tislabs.com on behalf of Frédéric Detienne >[fd@cisco.com] >Sent: Wednesday, January 24, 2001 11:34 PM >To: sankar ramamoorthi >Cc: Derek Atkins; sommerfeld@East.Sun.COM; Scott G. Kelly; >ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >notice that you made a lot of progress. Your "slight changes" actually shift the original paradigm from a "keepaplive in disguise" into "acknowledgement in disguise". No, it is more like 'acknowledgements-when-needed' > >Take my first emails and re-read: acknowledgments are better. > acknowledgements only when needed is still better :-) >Your problem is that you really want to trigger this with an "invalid SPI" message. And you come up with pretty fancy packets. Not that I do not like them (they're a valid vector after all) but now your philosophically correct pseudo-ICMP's tunnel data :) Yes, but not all error/packets though, only the 'receipt-needed' type of control packet. > >Question: what if every ESP (for instance) packet would piggy back an acknowledgement field (in both direction) ? That would solve quite a few issues, no ? And would also be much more efficient. > I do not understand what you have in mind for the semantic of acknowledgement field. Yes, it would be nice to have an 'RECEIPT-NEEDED' and 'RECEIPT' type of flags in the ESP. It would also be nice to have versioning in ESP. Any reason why versioning was left out of the initial ESP design? > > >One more thing: with acknowledgments alone, there are still possible DoS. All that will be in the draft I am cooking up but it is all about this: > >. my "invalid SPI notification" variant (i.e. within an IKE offer) may not work when under DoS. (flooding and rate limiting may prevent a good "invalid SPI" from being sent). BUT I do not restart IKE unduly, which is good. Bill Sommerfeld's CoB makes recovery faster.. As for as I understand the scheme, you have O peer wih out-of-sync/no ipsecSA peer sending data step1 send ESP data <----------------------- no ipsec or ike state with peer. send notification step2 send 'invalid spi' notification (signed?) ------------------------> step3 initiate directed-ike phase1 or phase2 exchange (ike for a particular reason) sa proposal + 'because you do not have SA xxx' <--------------------------- if reason is satifactory respond to IKE exchange from peer step4 ---------------------------> responder proposal (2nd message of ike exchange sa proposal + 'because I did not have SA xxx' Seems to be a neat way to avoid passive attacks. However the initial IKE message is not authenticated and it now carries additional information. What are the kind of attacks possible? Comparing this with an ESP based scheme.. The receiver of 'invalid spi' has to go through the first 2 IKE exchanges to ensure that 'invalid spi' is genuine. It means timers have to be maintained, and the first IKE message has to be sent several times to get through. Since the same cookie is now resent on every retry, does it offer more information for the attacker? The sender of the 'invalid spi' also has to remember that it sent the 'invalid spi' message to a peer. Otherwise someone could send a 'invalid spi' of some random spi and force it to start the series of directed IKE exchange. Remembering all the machine to which 'invalid spi' was sent seems an additional burden and open to DOS attacks. > >. acknowledgements are good but > a) slower than direct notifications (need several lost packets, Yes - but how fast do you want to recover? Autenticated (replay proofed, DOS protected) notifications are best for immediate recovery, but it seems such a difficult problem to solve and any solution seems too heavyweight. With the ipsec error protocol, speed of recovery is left to the implementation. If one side needs a very fast recovery, a keep-alive equivalent protocol can be implemented using the messages provided in ipsec error protocol. For normal operations a triggered acknowledgement scheme seems sufficient. > difficult to restart at the right place (phase 1 or phase 2)), > not true. As I mentioned earlier, 'invalid spi' ipsec error is sent only when there is no phase1 SA with the peer. If there is a phase1 SA it should always try to use 'invalid SPI' ike notification using the info exchange. Getting 'invalid spi' ipsec error in the clear implies the peer has lost both phase1 and phase2 state. If the receiver of the 'invalid spi' can assure itself the message is genuine, it can start phase1 exchange right away. > b) if uncontrolled, may restart IKE for nothing. E.g., Under a DoS, genuine ESP packets with a valid seq# may not reach the destination which in turn could not acknowledge them => forcing an undue rekey. > Agreed. This is a problem. But if genuine ESP packets cannot get through, the rekeys also won't succeed, which can give an early indication of something is wrong. > >In order to avoid undue rekeying within the acknowledgements scheme, the peers lacking the acknowledgment send an initialization offer saying: > >CKi | SA offers | "because you do not have inbound SPI xxx" > neat - however the message is in the clear and not authenticated. What are the possible attacks on this? >If the recipient DOES have SPI xxx, it simply does not respond to the offer. > >Well, there are some more things (no details here) but you got the idea. I still do not fully grasp the proposal. I will wait for more explanation from you. > >I believe that notifications are good (fast and robust) in environments where flooding and such things do not happen (a private Frame Relay network or a direct link for instance). > >Acknowledgments are certainly suitable for Internet like medium. > >These two methods work together but I would suggest that they can be turned on/off independently. > Agreed - but I feel the authenticated notification is a harder problem to solve. I still have not fully grasped the finer details of the solution proposed by you and Bill Sommerfeld. I guess I will wait for your draft. Good luck, -- sankar -- >regards, > > frederic detienne > From owner-ipsec@lists.tislabs.com Mon Jan 29 13:12:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA23488; Mon, 29 Jan 2001 13:12:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA25400 Mon, 29 Jan 2001 15:25:38 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 29 Jan 2001 15:24:24 -0500 To: "sankar ramamoorthi" From: Stephen Kent Subject: Re: ipsec error protocol Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sankar, > > > > > >Question: what if every ESP (for instance) packet would piggy back an >acknowledgement field (in both direction) ? That would solve quite a few >issues, no ? And would also be much more efficient. > > > >I do not understand what you have in mind for the semantic of >acknowledgement field. > >Yes, it would be nice to have an 'RECEIPT-NEEDED' and 'RECEIPT' type of >flags >in the ESP. It would also be nice to have versioning in ESP. >Any reason why versioning was left out of the initial ESP design? Good question. I think we envisioned an IKE negotiation for this, but it could have been done better. No place for a small version number up front, given alignment considerations, and if we assume a general need for a negotiation for an SA prior to its establishment, then that's the right time to find out what your peer can support, e.g., re versions. For now, I see no need to create a new version of ESP. For example, we're planning to accommodate bigger sequence numbers via a negotiation but NO change in the on the wire format. Thus I don't see other requirements that would motivate a change to the format to accommodate the sort of flags you cite. Steve From owner-ipsec@lists.tislabs.com Mon Jan 29 13:47:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24738; Mon, 29 Jan 2001 13:47:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25514 Mon, 29 Jan 2001 16:02:26 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3A6FD6E4.93F510EE@cisco.com> References: <3A6FD6E4.93F510EE@cisco.com> Date: Mon, 29 Jan 2001 16:06:27 -0500 To: fd@cisco.com From: Stephen Kent Subject: Re: ipsec error protocol Cc: ipsec@lists.tislabs.com Content-Type: multipart/alternative; boundary="============_-1231320090==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1231320090==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable =46r=E9d=E9ric, I'm very uncomfortable moving toward ACKs in ESP. We try in IPsec to=20 mimic IP functionality as much as possible, and IP does not ACK=20 packets. Note that our anti-replay strategy allows for out of order=20 arrival precisely because IP allows for it (even though we do impose=20 some limits here). Steve --============_-1231320090==_ma============ Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =46r=E9d=E9ric, I'm very uncomfortable moving toward ACKs in ESP. We try in IPsec to mimic IP functionality as much as possible, and IP does not ACK packets. Note that our anti-replay strategy allows for out of order arrival precisely because IP allows for it (even though we do impose some limits here). Steve --============_-1231320090==_ma============-- From owner-ipsec@lists.tislabs.com Mon Jan 29 13:53:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA25165; Mon, 29 Jan 2001 13:53:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25508 Mon, 29 Jan 2001 16:02:24 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200101252344.PAA25699@potassium.network-alchemy.com> References: <200101252344.PAA25699@potassium.network-alchemy.com> Date: Mon, 29 Jan 2001 16:02:28 -0500 To: Dan Harkins From: Stephen Kent Subject: Re: compliance question Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, >A question for the protocol police. Section 3.3.3 of RFC2406 says: > > The sender assumes anti-replay is enabled as a default, unless > otherwise notified by the receiver (see 3.4.3). Thus, if the counter > has cycled, the sender will set up a new SA and key (unless the SA > was configured with manual key management). > > If anti-replay is disabled, the sender does not need to monitor or > reset the counter, e.g., in the case of manual key management (see > Section 5). However, the sender still increments the counter and > when it reaches the maximum value, the counter rolls over back to > zero. > >Ignoring for the sake of a question whether disabling anti-replay is >smart or not, would an implementation be conformant if, when anti-replay >is disabled, the sequence number rolled over to zero prior to reaching >it's maximum value? That is 1, 2, ... 2^5, 1, 2, etc. If we adopted a way for the sender to be told by the receiver that it did not care about anti-replay, then it would seem reasonable to ignore the transmit counter value and allow it to rollover. But, for now, this behavior would be non-compliant. For some algorithms and modes, e.g.g., single DES in CBC mode, 2**32 packets is a good limit and most easily enforced by the counter, irrespective of anti-replay concerns, so we should be aware that we would be giving up this feature if we adopt this approach. However, if we depricate the use of single DES and move to AES, as expected, this might become moot. Steve From owner-ipsec@lists.tislabs.com Mon Jan 29 14:50:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA27930; Mon, 29 Jan 2001 14:50:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25719 Mon, 29 Jan 2001 17:03:12 -0500 (EST) From: "sankar ramamoorthi" To: "Stephen Kent" Cc: Subject: RE: ipsec error protocol Date: Mon, 29 Jan 2001 14:10:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: Stephen Kent [kent@bbn.com] >Sent: Monday, January 29, 2001 12:24 PM >To: sankar ramamoorthi >Cc: ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >Sankar, > >> >> >> > >> >Question: what if every ESP (for instance) packet would piggy back an >>acknowledgement field (in both direction) ? That would solve quite a few >>issues, no ? And would also be much more efficient. >> > >> >>I do not understand what you have in mind for the semantic of >>acknowledgement field. >> >>Yes, it would be nice to have an 'RECEIPT-NEEDED' and 'RECEIPT' type of >>flags >>in the ESP. It would also be nice to have versioning in ESP. >>Any reason why versioning was left out of the initial ESP design? > >Good question. I think we envisioned an IKE negotiation for this, but >it could have been done better. No place for a small version number >up front, given alignment considerations, and if we assume a general >need for a negotiation for an SA prior to its establishment, then >that's the right time to find out what your peer can support, e.g., >re versions. I was trying to understand why versioning was left out in the initial design. Thanks for the backgrounder. > For now, I see no need to create a new version of ESP. I agree the flags I was citing do not make any compelling reason to change on the wire protocol nor I was making a case for one. It was more of a what-if-we-had kind of thinking which led to the versioning question. -- sankar -- From owner-ipsec@lists.tislabs.com Mon Jan 29 16:24:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA01640; Mon, 29 Jan 2001 16:24:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25911 Mon, 29 Jan 2001 18:11:29 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <163823.3189500524@el-air-1.electric-loft.org> References: <163823.3189500524@el-air-1.electric-loft.org> Date: Mon, 29 Jan 2001 18:15:44 -0500 To: Derrell Piper From: Stephen Kent Subject: Re: Increased sequence number in ESP/AH Cc: ipsec@lists.tislabs.com Content-Type: multipart/mixed; boundary="============_-1231312349==_============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1231312349==_============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Derrell, >Steve, > >Is there a summary of your presentation you could post for those of >us who were unable to attend the last meeting? I've attached the PPT slides to this message. >A couple of comments on replay and clustering. > >I don't have any problem with 64-bit replay sequence numbers. The >math is lost in the noise and the additional sequence space will be >needed very soon now. > >Regarding clustered IPSec SA's, I like Bill's proposal, though I >tend to want to try to solve the problem with a single SA (pair). >However, something like a simple negotiated replay window set is >also problematic when you allow your clusters to dynamically resize >(as we do). You'd have to provide a mechanism to negotiate a new >replay window when you added another node not present during the >initial negotation. The beauty of Bill's proposal is that this is >just another Quick Mode. However, this will cost us O(n) in IPSec >SA memory usage, where 'n' is the size of a cluster, given our >failover guarantees. We currently achieve our 250ms failover in >O(1) IPSec SA memory usage. This isn't very appealing to us when >you consider that we support 20K+ tunnels in our high end systems. >On the third hand (:-), it's just memory. > >How about this: > > 1) add a replay 'flow id' to the ESP header or trailer and >include it in the integrity check > 2) require the receiver to support multiple replay windows, >per SA, indexed by flow id > 3) require that the flow id be unique for the lifetime of the >SA and forbid reuse of flow id's > 4) require the receiver to switch to a new replay window upon >receipt of an unknown flow id Well, I hate to add new fields to the packet format, but we may have to do that at some point. However, the approach you propose here has the advantage of being dynamic with less overhead (no QM exchange), by allowing creation of new flows without creating new SAs. The flow IDs separate out the sequence number spaces, each on a separate crypto processor, right? So, the sequence numbers will be sequential per flow, but packets for the same SPD-defined flow may be distributed over various SA flows, to support parallelism. >This allows the sender to start transmiting on a new replay window >following load-balancing, failover, >or a cluster resizing/remastering. With sufficient restrictions, >there's no effective security risk. I think one could make this adequately secure, as you suggest. >I do think this is an important problem to solve. Despite the >advances in COTS hardware acceleration, the only way we're going to >deal with increased pipe sizes in the near future is through >parallelism/clustering. I'm not so sure about that assertion, but I guess it depends on your definition of "near future." As someone else noted, if one assigns sequence numbers to (pseudo) ESP headers prior to forwarding the packet to a crypto module, then the transmitter can use multiple modules w/o encountering this problem. At the receiver the same is true, in reverse, i.e., checking the sequence number outside the module avoids the problem. Now, if we move to a counter mode that relies on the sequence number for per-packet variability, I would begin to worry about this approach, because of the security implications of duplicate sequence numbers. However, for CBC mode, this is not an issue. True, the security boundary is extended beyond the chip re anti-replay, but if other aspects of IPsec are off chip, e.g., SPD lookup and mapping, then the relative security concerns seem small in comparison. Very fast individual chips are being developed or are available now. they seem to be pretty good relative to individual subscriber access speeds. I presume the problem you're trying to address here arises in POP (vs. CPE) IPsec implementations. There one has more motivation to use multiple chips and to share them among various subscriber flows, hence the desire for maximum, efficient utilization of the hardware. Steve --============_-1231312349==_============ Content-Id: Content-Type: application/vnd.ms-powerpoint; name="IPsec_WG_12=00.ppt" ; x-mac-type="534C4438" ; x-mac-creator="50505433" Content-Disposition: attachment; filename="IPsec_WG_12=00.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAA AAAAAAAAEAAAMAAAAAEAAAD+////AAAAAAAAAAD///////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// ///9////LwAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAAN AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA GgAAABsAAAD+////HQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAA AP7///8oAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAA/v////7////+/////v////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// /////wBSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAACAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAA AAAAAAAAAAAAAIBb9nSQZsABMQAAAEAAAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAg AEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAA AwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAJjIA AAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABwAAACgFQAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJwAAAAAQ AAAAAAAADwDoA2gTAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAABcAAAAA AAAAAQAAAAAAAAEPAPID1AEAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVBzABAAAAALcP RAAAAFQAaQBtAGUAcwAAAEIAbABhAGMAawAAAHQAcwCoDCDnqAzQ4wAABwC0CRDt5Akg AqgM4OPkCSACwgl04KIAQLIBAAQAEAC3D0QAAABBAHIAaQBhAGwAAABCAGwAYQBjAGsA AAB0AHMAqAwg56gM0OMAAAcAtAkQ7eQJIAKoDODj5AkgAsIJdOCiAECyAAAEACAAtw9E AAAATQBvAG4AbwB0AHkAcABlACAAUwBvAHIAdABzAAAAIOeoDNDjAAAHALQJEO3kCSAC qAzg4+QJIALCCXTgogBAsgIABAAwALcPRAAAAEEAcgBpAGEAbAAgAEIAbABhAGMAawAA AHQAcwAAACDnqAzQ4wAABwC0CRDt5AkgAqgM4OPkCSACwgl04KIAQLIAAAQAAACpDwoA AAAHAAAAAgAJBAkEQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABA AgAAAAACAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkAC AAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwQkAgAADwAA8BwCAAAAAAbwiAEA AALAAAAwAAAAIwAAAAgAAAAAAAAABwAAAAAAAAADAAAAAAAAACUAAAAAAAAAKAAAAAEA AAAIAAAAAwAAAAQAAAAAAAAABAAAAAEAAAAEAAAAAwAAACEAAAAAAAAABAAAAAAAAAAl AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAADAAAAAAAAAAMwAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAIAAAABAAAAAgA AAAAAAAACgAAAAAAAAAIAAAAAAAAAAoAAAAAAAAACAAAAAAAAAAIAAAAAAAAAAgAAAAA AAAALAAAAAAAAAAMAAAABAAAAAQAAAAHAAAABAAAAAkAAAAEAAAABgAAAAQAAAAAAAAA BAAAAAgAAAASAAAAAAAAAAQAAAAAAAAABgAAAAAAAAACAAAAAwEL8GAAAACAAQAAAACB AQQAAAiDAQAAAAi/ARAAEADAAQEAAAjBAQAAAQDEAQAAAADLAZwxAADNAQAAAADOAQAA AADQAQAAAADRAQAAAADXAQIAAAD/AQgACAABAgIAAAg/AgAAAgAQABrxBAAAAP8AAABA AB7xEAAAAP//////AAAAAgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAQAAAAAAAAA AQAAgAAAAAAPANAHzwAAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAHkAAABkAAAA eQAAAGQAAAAAAAAAIALkCQP9AAAAAAA0JHX5CQAAAADI/v//kP///wEA+gNwAPsDCAAA AAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8ABwQ8AAAAAAD9AzQAAAAyAAAAZAAAADIA AABkAAAAZwAAAAEAAAAg56gMAQAAAQAAAAAQ5KgMAAAAAAAAAAAAAAAAHwD/AxQAAAAC AAAEDAAAAAAAAAAAAAAAAgAAAD8A2Q8MAAAAAADaDwQAAAAAACUADwDwDxEOAAAAAPMD FAAAAAMAAAAAAAAAAgAAAAMBAAAAAAAAAACfDwQAAAAGAAAAAACoDyoAAABJUHNlYyBF bmhhbmNlbWVudHMgZm9yC0hpZ2ggU3BlZWQgTmV0d29ya3MAAKEPFgAAACsAAAAAAAAI AAABACsAAAAAAAIAKAAQAJ8PBAAAAAUAAAAAAKgPDAAAAFN0ZXBoZW4gS2VudAAA8wMU AAAAIgAAAAAAAAACAAAABAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPEwAAAEN1cnJlbnQg Q29uc3RyYWludHMQAJ8PBAAAAAEAAAAAAKgPYgAAAFNlcXVlbmNlIG51bWJlciBzcGFj ZSBleGhhdXN0aW9uDUVuY3J5cHRpb24gcGVyZm9ybWFuY2UNSW50ZWdyaXR5IChhbmQg YXV0aGVudGljYXRpb24pIHBlcmZvcm1hbmNlAADzAxQAAAAmAAAAAAAAAAIAAAAHAQAA AAAAAAAAnw8EAAAAAAAAAAAAqA8aAAAAU2VxdWVuY2UgTnVtYmVyIEV4aGF1c3Rpb24Q AJ8PBAAAAAEAAAAAAKgPbQIAAEF0IHZlcnkgaGlnaCBzcGVlZHMgKDEwIEdiL3MpLCB0 aGUgMzIgYml0IHNlcXVlbmNlIHNwYWNlIGNhbiBiZSBleGhhdXN0ZWQgYnkgc21hbGwg cGFja2V0cyBpbiBhIGZldyBtaW51dGVzDVdpdGggdGhlIHVzZSBvZiBBRVMgYW5kIG5l dyBtb2RlcywgdGhhdCByZWFkaWx5IHRvbGVyYXRlIGxhcmdlIHRyYWZmaWMgdm9sdW1l cywgYmlnZ2VyIHNlcXVlbmNlIHNwYWNlcyBhcmUgYXBwcm9wcmlhdGUNUHJvcG9zYWw6 IA1BbGxvdyBJS0UgdG8gbmVnb3RpYXRlIGEgNDgtYml0IHNlcXVlbmNlIG51bWJlciwg YnV0IHRyYW5zbWl0IG9ubHkgdGhlIGxvdyBvcmRlciAzMiBiaXRzIG9uIGVhY2ggcGFj a2V0DUluY2x1ZGUgaGlnaCBvcmRlciAxNiBiaXRzIGluIGludGVncml0eSBjaGVjayBh dCBlYWNoIGVuZCwgYW5kIG1haW50YWluIGxvY2FsIGNvdW50ZXJzIHRvIHRyYWNrIHRo ZXNlIGhpZ2ggb3JkZXIgYml0cw1SZWNlaXZlIHdpbmRvdyBtYW5hZ2VtZW50IGlzIHN0 aWxsIGEgbG9jYWwgbWF0dGVyDU5vIGNoYW5nZSB0byBmb3JtYXQgb2YgYml0cyBvbiB3 aXJlLCBlbmhhbmNlZCBJUHNlYyBpbXBsZW1lbnRhdGlvbnMgYXJlIGJhY2t3YXJkIGNv bXBhdGlibGUsIHBlci1TQSBmbGV4aWJpbGl0eQAAoQ8kAAAA7gAAAAAAAAAAAIABAAAB AAAAAADuAAAAAAAAAIABAAAAAAAAAACqDxoAAAAYAAAAAAAAAAIAAAABAAAAAwBUAgAA AAAAAAAA8wMUAAAAIwAAAAAAAAACAAAABQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFgAA AEVuY3J5cHRpb24gUGVyZm9ybWFuY2UQAJ8PBAAAAAEAAAAAAKgPKQEAAEFFUyBpcyBm YXN0ZXIgdGhhbiAzREVTDUJ1dCwgQ0JDIG1vZGUgbWluaW1pemVzIG9wcG9ydHVuaXRp ZXMgZm9yIHBhcmFsbGVsIGFuZCBwaXBlbGluZWQgaW1wbGVtZW50YXRpb25zDUNvdW50 ZXIgbW9kZXMgKGZpcnN0IGRldmVsb3BlZCBmb3IgQVRNIGVuY3J5cHRpb24pIG9mZmVy IHBhcmFsbGVsaXNtIGFuZCBwaXBlbGluaW5nIG9wcG9ydHVuaXRpZXMNRm9yIElQc2Vj LCBhIGNvdW50ZXIgbW9kZSBtdXN0IGFjY29tbW9kYXRlIGxvc3QgcGFja2V0cyBhbmQg b3V0IG9mIG9yZGVyIGFycml2YWwsIGVmZmljaWVudGx5DQAA8wMUAAAAJAAAAAQAAAAC AAAACAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIgAAAEEgUHJvcG9zZWQgQ291bnRlciBF bmNyeXB0aW9uIE1vZGUQAJ8PBAAAAAEAAAAAAKgPGwIAAENvdW50ZXIgZm9yIDE2LWJ5 dGUgYmxvY2sgQUVTIHNob3VsZCBiZSAxMjggYml0cywgeWllbGQgZGlmZmVyZW50IHZh bHVlIGZvciBlYWNoIHBhY2tldCBvbiBlYWNoIFNBDUxvdyBvcmRlciAzMiBiaXRzIGNv dW50IEFFUyBibG9ja3Mgd2l0aGluIGEgcGFja2V0LCBiaWdnZXIgdGhhbiBuZWVkZWQs IGV2ZW4gZm9yIElQdjYganVtYm9ncmFtDU5leHQgNDggYml0cyBhcmUgYSBwYWNrZXQg Y291bnRlciwgdXNpbmcgdGhlIGV4cGFuZGVkIEVTUCBzZXF1ZW5jZSBudW1iZXIgKGJ1 dCBvbmx5IGxvdyBvcmRlciAzMiBiaXRzIGFyZSBjYXJyaWVkIGluIGVhY2ggcGFja2V0 KQ1OZXh0IDE2IGJpdHMgY29udGFpbiBhIHNlY3JldCB2YWx1ZSBleHRyYWN0ZWQgZnJv bSBTS0VZSUQsIGZvciBwZXIgU0EgdW5pcXVlbmVzcyBhbmQga2VlcGluZyBjb3VudGVy IHNlY3JldA1Ub3AgMzIgYml0cyBhcmUgYSBwZXIgcGFja2V0IElWICh1bnByZWRpY3Rh YmxlIGlucHV0IHRvIHRoZSBjb3VudGVyLCBidXQgaGFsZiB0aGUgc2l6ZSBvZiB0aGUg Y3VycmVudCBJVikNAAChDyQAAABjAAAAAAAAAAAAuQEAAAEAAAAAAGMAAAAAAAAAuQEA AAAAAAAAAKoPGgAAALkAAAAAAAAACQAAAAEAAAADAFoBAAAAAAAAAADzAxQAAAAlAAAA AAAAAAIAAAAGAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8VAAAASW50ZWdyaXR5IFBlcmZv cm1hbmNlEACfDwQAAAABAAAAAACgD6wEAABXAGkAdABoACAAZgBhAHMAdAAgAGUAbgBj AHIAeQBwAHQAaQBvAG4ALAAgAHQAaABlACAAaQBuAHQAZQBnAHIAaQB0AHkAIAAmACAA YQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuACAAYwBvAG0AcAB1AHQAYQB0AGkAbwBu ACAAbgBvAHcAIABiAGUAYwBvAG0AZQBzACAAYQAgAGIAbwB0AHQAbABlAG4AZQBjAGsA LAAgAGkALgBlAC4ALAAgAEgATQBBAEMAIAAoAE0ARAA1ACAAbwByACAAUwBIAEEALQAx ACkAIABpAHMAIABzAGwAbwB3AA0ATQBvAGQAZQBzACAAdABoAGEAdAAgAGMAbwBtAGIA aQBuAGUAIABlAG4AYwByAHkAcAB0AGkAbwBuACAAJgAgAGkAbgB0AGUAZwByAGkAdAB5 ACAAbQBhAHkAIABiAGUAIABnAG8AbwBkACAAYwBoAG8AaQBjAGUAcwAsACAAYgB1AHQA DQBzAG8AbQBlACAAYQByAGUAIABuAG8AdAAgAGMAbwBuAHMAaQBzAHQAZQBuAHQAIAB3 AGkAdABoACAARQBTAFAAIABwAHIAbwBjAGUAcwBzAGkAbgBnACAAYQBuAGQAIABzAHkA bgB0AGEAeAAgACgAYQB1AHQAaABlAG4AdABpAGMAYQB0AGUAIABmAGkAcgBzAHQALAAg AHQAaABlAG4AIABkAGUAYwByAHkAcAB0ACkADQBzAG8AbQBlACAAaQBtAHAAbwBzAGUA IABuAG8AdABpAGMAZQBhAGIAbABlACAAcABlAG4AYQBsAHQAaQBlAHMAIABmAG8AcgAg AHMAbQBhAGwAbAAgAHAAYQBjAGsAZQB0AHMADQB0AGgAZQByAGUAIABtAGEAeQAgAGIA ZQAgAGkAbgB0AGUAbABsAGUAYwB0AHUAYQBsACAAcAByAG8AcABlAHIAdAB5ACAAcABy AG8AYgBsAGUAbQBzACAAYQBzACAAdwBlAGwAbAANAE0AbwByAGUAbwB2AGUAcgAsACAA dwBlACAAcgBlAHEAdQBpAHIAZQAgAGEAIABmAGEAcwB0ACwAIABzAHQAYQBuAGQALQBh AGwAbwBuAGUAIABpAG4AdABlAGcAcgBpAHQAeQAgAGEAbABnAG8AcgBpAHQAaABtACAA ZgBvAHIAIABFAFMAUAAsACAAdwBoAGUAbgAgAGkAdAAgAGkAcwAgAHUAcwBlAGQAIABp AG4AIABsAGkAZQB1ACAAbwBmACAAQQBIAA0AQQBzACAAYQAgAHMAdABhAHIAdAAsACAA bABlAHQAGSBzACAAYQBkAG8AcAB0ACAAQQBFAFMALQBNAEEAQwAgACgAdwBpAHQAaAAg AGEAIAByAGUAZAB1AGMAZQBkACAAOQA2ACAAYgBpAHQAIABvAHUAdABwAHUAdAApACAA YQBzACAAYQAgAGQAZQBmAGEAdQBsAHQADQBTAGkAbQBwAGwAZQAsACAAZgBhAHMAdABl AHIAIAB0AGgAYQBuACAASABNAEEAQwAsACAAcwBlAGMAdQByAGUALAAgAC4ALgAuAAAA oQ9IAAAAwAAAAAAAAAAAAMEAAAABAAAAAACwAAAAAAAAAAAAJgAAAAEAAAAAAMAAAAAA AAAAwQAAAAAAAACwAAAAAAAAACYAAAAAAAAAAADqAwAAAAAPAPgDfAgAAAIA7wMYAAAA AQAAAAECBwkIAAAAAAAAAAAAAAAAAAAAYADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZ ADMzzADMzP8AsrKyAGAA8AcgAAAAAAD/AP///wAAAAAA//8AAP+ZAAAA//8A/wAAAJaW lgBgAPAHIAAAAP//zAAAAAAAZmYzAICAAAAzmTMAgAAAAAAzzAD/zGYAYADwByAAAAD/ //8AAAAAADMzMwAAAAAA3d3dAICAgABNTU0A6urqAGAA8AcgAAAA////AAAAAACAgIAA AAAAAP/MZgAAAP8AzADMAMDAwABgAPAHIAAAAP///wAAAAAAgICAAAAAAADAwMAAAGb/ AP8AAAAAmQAAYADwByAAAAD///8AAAAAAICAgAAAAAAAM5n/AJn/zADMAMwAsrKyAAAA ow8+AAAAAQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAB AAEA////////IAAAAGb+AAAQAKMPggAAAAUA//0/AAcAbgACAGQAAACZ/gAAZAAUAAAA 2AAAAEACAAAAAAIAAAD//+8AAQABAP///////xgAAAAAAQAAiAUAAA8AdQDUASABAQAC AAAAFACSBQAADQAUIAAA0AJAAgAAAACABQAAEyDwA2ADAAAAAIAFAAC7ABAFgAQAAAIA EgAgAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAeAAAAAAAAAEACAAAAAAIAAAD/ /+8AAAAAAP///////wwAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGAD YAMAAAAAAAUAAIAEgAQAAAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAA AAAAAABAAgAAAAACAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAF AABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAG AAEAAAAAAAAAAQABCQAADgABACABAAAAAAIAAQkAAAwAAQBAAgAAAAADAAEJAAAMAAEA YAMAAAAABAABCQAADAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAF AAAAAAAAAAAAAgAUAAEAAAAAAAAAAgASAAIAAAAAAAAAAgASAAMAAAAAAAAAAgASAAQA AAAAAAAAAgAQAIAAow8+AAAABQAAAAAAAAAAAAIAEgABAAAAAAAAAAIAEAACAAAAAAAA AAIAEAADAAAAAAAAAAIAEAAEAAAAAAAAAAIADgAPAAwESgQAAA8AAvBCBAAAEAAI8AgA AAAFAAAABxQAABAAGPEEAAAAAQAAAA8AA/DUAwAADwAE8CgAAAABAAnwEAAAAP9//3// f/9//3//f/9//38CAArwCAAAAAAUAAAFAAAADwAE8PwAAAASAArwCAAAAAIUAAAACgAA AwEL8GAAAAB/AAEAAQCAAKQ5+QmBAHdhAQCCAKKtAACDAHdhAQCEAKKtAACHAAEAAAC/ ABAAHwCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAjLAZwxAAD/AQEACQABAgIAAAg/AgAA AgAAABDwCAAAAIABsAHQFKACDwAR8BAAAAAAAMMLCAAAAAAAAAABAAogDwAN8FQAAAAA AJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxl AACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwQAEAABIACvAIAAAAAxQA AAAKAADzAAvwWgAAAH8AAQABAIAABDr5CYEAd2EBAIIAoq0AAIMAd2EBAIQAoq0AAL8A EAAfAIEBBAAACIMBAAAACL8BAQARAMABAQAACMsBnDEAAP8BAQAJAAECAgAACD8CAAAC AAAAEPAIAAAAMAOwAdAUcA4PABHwEAAAAAAAwwsIAAAAAQAAAAIACiAPAA3wngAAAAAA nw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMN U2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAA og8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAA AAAADwAE8FgAAABCAQrwCAAAAAQUAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAAC/AQAA EADAAfwBKADLAT7fAAD/AQgACAABAgIAAAg/AgAAAgAAABDwCAAAANACsAHMFNACDwAE 8PAAAAASAArwCAAAAAcUAAAACgAA8wAL8FoAAACAAMQ6+QmBAHdhAQCCAKKtAACDAHdh AQCEAKKtAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAjLAZwxAAD/AQAACAAB AgIAAAg/AgAAAgCIAwEAAAAAABDwCAAAAOwPmhCDFuQQDwAN8GYAAAAAAJ8PBAAAAAQA AAAAAKgPEAAAAEJCTiBUZWNobm9sb2dpZXMAAKEPHAAAABEAAAAAAAAgAAAyABEAAAAA AAcAAwARAAAAZv4AAKYPFgAAAPEeAAApAhoBGgE0AjQCTwNPA2kEaQQPAATwQgAAABIA CvAIAAAAARQAAAAMAABzAAvwKgAAAIEBAAAACJMBjp+LAJQB3r1oAL8BHgAfAP8BAAAI AAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKy sgAgALoPDAAAAE4AUwBBACAAVgA1AA8A8AMaBgAAAQDxAwgAAAABAACAAAAQ4A8ADATa BQAADwAC8NIFAABAAAjwCAAAAAcAAAAHeAAADwAD8GoFAAAPAATwKAAAAAEACfAQAAAA kgEAAAAAAAAGAAAAkwEAAAIACvAIAAAAAHgAAAUAAAAPAATw3QAAABIACvAIAAAAAngA AAAKAACjAAvwPAAAAH8AAQABAIAAJEH5CYEBBAAACIMBAAAACL8BAQARAMABAQAACMsB nDEAAP8BAQAJAAECAgAACD8CAAACAAAAEPAIAAAAAAAAAFAHIAEPABHwEAAAAAAAwwsI AAAAAAAAAAoCCiAPAA3wWQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8UAAAAAgAA AAAAAAAAAAIAAAAAAAIADAAAAPkPBAAAAAAAAAAAAKoPFAAAAAEAAAABAAAAAAABAAAA AQAAAAAADwAE8N8AAAASAArwCAAAAAN4AAAACgAAowAL8DwAAAB/AAEAAQCAAIRB+QmB AQQAAAiDAQAAAAi/AQEAEQDAAQEAAAjLAZwxAAD/AQEACQABAgIAAAg/AgAAAgAAABDw CAAAAAAAkAngECABDwAR8BAAAAAAAMMLCAAAAAEAAAAHAAogDwAN8FsAAAAAAJ8PBAAA AAQAAAAAAKgPAQAAACoAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADAAAAPgPBAAA AAAAAAAAAKoPFAAAAAEAAAABAAAAAAABAAAAAQAAAAAADwAE8GQAAAASAArwCAAAAAR4 AAAACgAAYwAL8CQAAAB/AAQABACHAAEAAAB/AQAAAQC/AREAEQD/AQgACQA/AgEAAQAA ABDwCAAAALAB0AIQDiAKDwAR8BAAAAAAAMMLCAAAAAIAAAAFAAogDwAE8CIBAAASAArw CAAAAAV4AAAACgAAowAL8DwAAAB/AAEAAQCAAORB+QmBAQQAAAiDAQAAAAi/AQEAEQDA AQEAAAjLAZwxAAD/AQEACQABAgIAAAg/AgAAAgAAABDwCAAAALAKQAKgDtAUDwAR8BAA AAAAAMMLCAAAAAMAAAAGAgogDwAN8J4AAAAAAJ8PBAAAAAIAAAAAAKgPUgAAAENsaWNr IHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZl bA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAAC AA0AAAADAAwAAAAEAAAAqg8KAAAAUwAAAAEAAAAAAA8ABPDjAAAAEgAK8AgAAAAGeAAA AAoAALMAC/BCAAAAfwABAAEAgABEQvkJhwACAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEB AAAIywGcMQAA/wEBAAkAAQICAAAIPwIAAAIAAAAQ8AgAAABgFQAAUAeAFg8AEfAQAAAA AADDCwgAAAAEAAAACQIKIA8ADfBZAAAAAACfDwQAAAAEAAAAAACoDwEAAAAqAAChDxQA AAACAAAAAAAAAAAAAgAAAAAAAgAMAAAA+g8EAAAAAAAAAAAAqg8UAAAAAQAAAAEAAAAA AAEAAAABAAAAAAAPAATw5QAAABIACvAIAAAAB3gAAAAKAACzAAvwQgAAAH8AAQABAIAA NI0JCocAAgAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACMsBnDEAAP8BAQAJAAECAgAA CD8CAAACAAAAEPAIAAAAYBWQCeAQgBYPABHwEAAAAAAAwwsIAAAABQAAAAgCCiAPAA3w WwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAA AgAMAAAA2A8EAAAAAAAAAAAAqg8UAAAAAQAAAAEAAAAAAAEAAAABAAAAAAAPAATwSAAA ABIACvAIAAAAAXgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB3r1oAJQBjp+LAL8B EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAz M8wAzMz/ALKysgAPAO4DugIAAAIA7wMYAAAAAAAAAA8QAAAAAAAAAQAAgAAAAAAGAAAA AAD5AxAAAAAAAAAAAAAAAAIAAQACqOVgDwAMBFICAAAPAALwSgIAADAACPAIAAAAAwAA AAMYAAAPAAPw4gEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgA AAAAGAAABQAAAA8ABPDGAAAAEgAK8AgAAAACGAAAIAIAADMBC/ByAAAAgADkPvkJgQB3 YQEAggCirQAAgwB3YQEAhACirQAAhQAAAAAAhgAAAAAAhwABAAAAiAAAAAAAiQAAAAAA igAAAAAAiwAAAAAAvwAQAB8AvwEAABEAywGcMQAA/wEAAAkAPwIAAAIAAQMCFAAAiAMA AAAAAAAQ8AgAAADYAfAA8BWoBg8AEfAQAAAAAADDCwgAAAAAAAAADwAKIA8ADfAMAAAA AACeDwQAAAAAAAAADwAE8NwAAAASAArwCAAAAAMYAAAgAgAAMwEL8HIAAACAAEQ/+QmB AHdhAQCCAKKtAACDAHdhAQCEAKKtAACFAAAAAACGAAAAAACHAAAAAACIAAAAAACJAAAA AACKAAAAAACLAAAAAAC/ABAAHwC/AQAAEQDLAZwxAAD/AQAACQA/AgAAAgABAwMUAACI AwAAAAAAABDwCAAAAHAIyAG4FIANDwAR8BAAAAAAAMMLCAAAAAEAAAAQAAogDwAN8CIA AAAAAJ4PBAAAAAEAAAAAAKYPDgAAAPgAAADYANQB0ALwAxAFDwAE8EgAAAASAArwCAAA AAEYAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/AR4AHwD/AQAA CAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAkZGRAAAAAABhj/0AAK4AAPwBKADO zs4ADwDuA9gBAAACAO8DGAAAAAEAAAANDgAAAAAAAAEAAIAAAAAABwAAAA8ADASIAQAA DwAC8IABAABQAAjwCAAAAAMAAAADnAAADwAD8BgBAAAPAATwKAAAAAEACfAQAAAAAAAA AAAAAADNAAAAmgAAAAIACvAIAAAAAJwAAAUAAAAPAATwbAAAABIACvAIAAAAApwAACAC AABDAAvwGAAAAIAAlI0JCr8BAAABAP8BAAABAAEDAhQAAAAAEPAIAAAAgAGwAdAUoAIP ABHwEAAAAAAAwwsIAAAAAAAAAA0ACiAPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPBsAAAA EgAK8AgAAAADnAAAIAIAAEMAC/AYAAAAgAD0jQkKvwEAAAEA/wEAAAEAAQMDFAAAAAAQ 8AgAAAAwA7AB0BRwDg8AEfAQAAAAAADDCwgAAAABAAAADgAKIA8ADfAMAAAAAACeDwQA AAABAAAADwAE8EgAAAASAArwCAAAAAGcAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiT AY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAA gICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwDuA9gBAAACAO8DGAAAAAEAAAANDgAAAAAA AAEAAIAAAAAABwAAAA8ADASIAQAADwAC8IABAABgAAjwCAAAAAMAAAADqAAADwAD8BgB AAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAADNAAAAmgAAAAIACvAIAAAAAKgAAAUAAAAP AATwbAAAABIACvAIAAAAAqgAACACAABDAAvwGAAAAIAAtI4JCr8BAAABAP8BAAABAAED AhQAAAAAEPAIAAAAgAGwAdAUoAIPABHwEAAAAAAAwwsIAAAAAAAAAA0ACiAPAA3wDAAA AAAAng8EAAAAAAAAAA8ABPBsAAAAEgAK8AgAAAADqAAAIAIAAEMAC/AYAAAAgAAUjwkK vwEAAAEA/wEAAAEAAQMDFAAAAAAQ8AgAAAAwA7AB0BRwDg8AEfAQAAAAAADDCwgAAAAB AAAADgAKIA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAGoAAAADAAA gwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/ AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwDuA9gB AAACAO8DGAAAAAEAAAANDgAAAAAAAAEAAIAAAAAABwAAAA8ADASIAQAADwAC8IABAABw AAjwCAAAAAMAAAADoAAADwAD8BgBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAADNAAAA mgAAAAIACvAIAAAAAKAAAAUAAAAPAATwbAAAABIACvAIAAAAAqAAACACAABDAAvwGAAA AIAANJAJCr8BAAABAP8BAAABAAEDAhQAAAAAEPAIAAAAgAGwAdAUoAIPABHwEAAAAAAA wwsIAAAAAAAAAA0ACiAPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPBsAAAAEgAK8AgAAAAD oAAAIAIAAEMAC/AYAAAAgACUkAkKvwEAAAEA/wEAAAEAAQMDFAAAAAAQ8AgAAAAwA7AB 0BRwDg8AEfAQAAAAAADDCwgAAAABAAAADgAKIA8ADfAMAAAAAACeDwQAAAABAAAADwAE 8EgAAAASAArwCAAAAAGgAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69 aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAA zJkAMzPMAMzM/wCysrIADwDuA2oFAAACAO8DGAAAAAEAAAANDgAAAAAAAAEAAIAAAAAA BwAAAA8ADAQaBQAADwAC8BIFAACAAAjwCAAAAAgAAAARsAAAIAAY8QgAAAABAAAAAgAA AA8AA/CaBAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAzQAAAJoAAAACAArwCAAAAACw AAAFAAAADwAE8MEAAAASAArwCAAAAAawAAAACgAAwwAL8EgAAACAADSTCQqFAAIAAACH AAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAjLAZwxAAD/AQgACAABAgIAAAg/AgAA AgCIAwIAAAAAABDwCAAAAMADwA+wE9AFDwAN8EkAAAAAAJ8PBAAAAAQAAAAAAKgPFwAA AGJsb2NrIGNvdW50ZXINKDMyIGJpdHMpAAChDxYAAAAYAAAAAAAACAAAAQAYAAAAAAAC ABQADwAE8MgAAAASAArwCAAAAAiwAAAACgAAwwAL8EgAAACAAPSTCQqFAAIAAACHAAEA AACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAjLAZwxAAD/AQgACAABAgIAAAg/AgAAAgCI AwIAAAAAABDwCAAAAMADYAnAD9AFDwAN8FAAAAAAAJ8PBAAAAAQAAAAAAKgPHgAAAEVT UCBTZXF1ZW5jZSBOdW1iZXINICg0OCBiaXRzKQAAoQ8WAAAAHwAAAAAAAAgAAAEAHwAA AAAAAgAUAA8ABPC3AAAAEgAK8AgAAAAJsAAAAAoAAMMAC/BIAAAAgAC0lAkKhQACAAAA hwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAIywGcMQAA/wEIAAgAAQICAAAIPwIA AAIAiAMCAAAAAAAQ8AgAAADAA6ACkAbQBQ8ADfA/AAAAAACfDwQAAAAEAAAAAACoDw0A AABJVg0gKDMyIGJpdHMpAAChDxYAAAAOAAAAAAAACAAAAQAOAAAAAAACABQADwAE8GwA AAASAArwCAAAAAqwAAAgAgAAQwAL8BgAAACAABSVCQq/AQAAAQD/AQAAAQABAwIUAAAA ABDwCAAAAIABsAHQFKACDwAR8BAAAAAAAMMLCAAAAAAAAAANAAogDwAN8AwAAAAAAJ4P BAAAAAAAAAAPAATwbAAAABIACvAIAAAAC7AAACACAABDAAvwGAAAAIAAdJUJCr8BAAAB AP8BAAABAAEDAxQAAAAAEPAIAAAAYAaAAaAU4A0PABHwEAAAAAAAwwsIAAAAAQAAAA4A CiAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPCwAAAAEgAK8AgAAAAQsAAAAAoAALMAC/BC AAAAgAA0lgkKhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAIywGcMQAA /wEIAAgAAQICAAAIPwIAAAIAAAAQ8AgAAADAA5AGYAnQBQ8ADfA+AAAAAACfDwQAAAAE AAAAAACoDwwAAABYDSAoMTYgYml0cykAAKEPFgAAAA0AAAAAAAAIAAABAA0AAAAAAAIA FAAPAATwagAAAEIBCvAIAAAAEbAAAAAKAACzAAvwQgAAAIUAAgAAAIcAAQAAAEQBBAAA AH8BAAABAL8BAAAQAMABAQAACMsBnDEAAM4BAgAAAP8BGAAYAAECAgAACD8CAAACAAAA EPAIAAAAwAPQC9AL0AUPAATwSAAAABIACvAIAAAAAbAAAAAMAACDAAvwMAAAAIEBAAAA CIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA ////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4D2AEAAAIA7wMYAAAAAQAA AA0OAAAAAAAAAQAAgAAAAAAHAAAADwAMBIgBAAAPAALwgAEAAJAACPAIAAAAAwAAAAOk AAAPAAPwGAEAAA8ABPAoAAAAAQAJ8BAAAACABAAAKQAAAHAIAABNAAAAAgAK8AgAAAAA pAAABQAAAA8ABPBsAAAAEgAK8AgAAAACpAAAIAIAAEMAC/AYAAAAgACUlgkKvwEAAAEA /wEAAAEAAQMCFAAAAAAQ8AgAAACAAbAB0BSgAg8AEfAQAAAAAADDCwgAAAAAAAAADQAK IA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8GwAAAASAArwCAAAAAOkAAAgAgAAQwAL8BgA AACAAPSWCQq/AQAAAQD/AQAAAQABAwMUAAAAABDwCAAAADADsAHQFHAODwAR8BAAAAAA AMMLCAAAAAEAAAAOAAogDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAA AaQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAI AAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKy sgAAAHIXMAAAAAEAMAAAAAAAcBMAABYiAAAXABAA9BsAACIAUADYJAAAmCgAAHgqAADq LwAAuCYAAAAA9Q8cAAAABgEAAAEbAAMAAAAAyjEAAAEAAAAnAAAABwDnQAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP7/AAADCgEAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ MAAAAHAVAAAMAAAAAQAAAGgAAAACAAAAcAAAAAQAAACsAAAABwAAAMAAAAAIAAAA7AAA AAkAAAAAAQAAEgAAAAwBAAAKAAAALAEAAAwAAAA4AQAADQAAAEQBAAAPAAAAUAEAABEA AABYAQAAAgAAABAnAAAeAAAAMgAAAEhvdyBTZWN1cmUgQ2FuIFdlIE1ha2UgYSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eT8Ab2keAAAACwAAAFN0ZXZlIEtlbnQAQx4AAAAiAAAA TWFjaW50b3NoIEhEOlByZXNlbnRhdGlvbnM6TlNBIFY1AHRpHgAAAAsAAABTdGV2ZSBL ZW50AEQeAAAAAwAAADQyAHYeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50AHRpb0AA AAAACB9oOQAAAEAAAACA74qtdL6+AUAAAACAY8xdumbAAQMAAACKAQAARwAAABAUAAD+ ////UElDVBQIAAAAAAAQABYAEQL/DAD//v/QAkAAAAJAAAAAAAAAAIcAtAniRAAAHgAB AAoAAAAAAIcAtACaAAAA/4LQAAAAAACHALQAAAAEAAAAAABIAAAASAAAABAAIAADAAgA AAAACfjWIAn41awAAAAAAIcAtAAAAAAAhwC0AAAACoH/gf+B/4H/5f8ACoH/gf+B/4H/ 5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8A CoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/ gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B /4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/ 5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8A CoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ATd//AgD///0A6//8APr/AADR/wAA9v8BAAC1 /wIA///9AOv//AD6/wAA0f8AAPb/AQAAtf8CZv///Wbr//xm+v8AZtH/AGb2/wFmZtf/ AFPf/wMA//8A/v8AAOz/AAD2/wAA0f8AAPb/AAC0/wMA//8A/v8AAOz/AAD2/wAA0f8A APb/AAC0/wNm//9m/v8AZuz/AGb2/wBm0f8AZvb/AGbW/wEZ3/8DAP//AP7/AQD//QAB ///+AP7//gD8/wAA/P/9AAH///0AAf///QAA//0A/v/+AP7//gD+//4ABP8AAP///gAB ///9AAD//gAB///9AP7//gAB///+AAH///4Av/8DAP//AP7/AQD//QAB///+AP7//gD8 /wAA/P/9AAH///0AAf///QAA//0A/v/+AP7//gD+//4ABP8AAP///gAB///9AAD//gAB ///9AP7//gAB///+AAH///4Av/8DZv//Zv7/AWb//WYB///+Zv7//mb8/wBm/P/9ZgH/ //1mAf///WYA//1m/v/+Zv7//mb+//5mBP9mZv///mYB///9ZgD//mYB///9Zv7//mYB ///+ZgH///5m4f8BMd//AgD///0AAf8A/P8AAP7/AgD/AP7/AAD9//wAAf8A/v8CAP8A /v8AAPz/AQAA/v8CAP8A/v8CAP8A/v8KAP//AP//AP//AAD+/wIA/wD+/wUA/wD//wD5 /wMA//8A/v8CAP8Avf8CAP///QAB/wD8/wAA/v8CAP8A/v8AAP3//AAB/wD+/wIA/wD+ /wAA/P8BAAD+/wIA/wD+/wIA/wD+/woA//8A//8A//8AAP7/AgD/AP7/BQD/AP//APn/ AwD//wD+/wIA/wC9/wJm///9ZgH/Zvz/AGb+/wJm/2b+/wBm/f/8ZgH/Zv7/Amb/Zv7/ AGb8/wFmZv7/Amb/Zv7/Amb/Zv7/Cmb//2b//2b//2Zm/v8CZv9m/v8FZv9m//9m+f8D Zv//Zv7/Amb/Zt//AQrf/wMA//8A/P/+AAH///wAAf8A+f8AAPz/AAD+/wIA/wD+/wIA ///8AP7/AgD/APz//AAH//8A//8A///7AAH/AP7/AgD/AP7//gD8/wMA//8A/v8CAP8A vf8DAP//APz//gAB///8AAH/APn/AAD8/wAA/v8CAP8A/v8CAP///AD+/wIA/wD8//wA B///AP//AP//+wAB/wD+/wIA/wD+//4A/P8DAP//AP7/AgD/AL3/A2b//2b8//5mAf// /GYB/2b5/wBm/P8AZv7/Amb/Zv7/Amb///xm/v8CZv9m/P/8Zgf//2b//2b///tmAf9m /v8CZv9m/v/+Zvz/A2b//2b+/wJm/2bf/wEi3/8DAP//APn/AgD/APz/AAD+/wAA/f8A APz/AAD+/wIA/wD+/wIA/wD+/wEAAP7/AgD/AP7/AgD/APv/BwD//wD//wAA/P8AAP7/ AgD/APv/AAD9/wMA//8A/v8CAP8Avf8DAP//APn/AgD/APz/AAD+/wAA/f8AAPz/AAD+ /wIA/wD+/wIA/wD+/wEAAP7/AgD/AP7/AgD/APv/BwD//wD//wAA/P8AAP7/AgD/APv/ AAD9/wMA//8A/v8CAP8Avf8DZv//Zvn/Amb/Zvz/AGb+/wBm/f8AZvz/AGb+/wJm/2b+ /wJm/2b+/wFmZv7/Amb/Zv7/Amb/Zvv/B2b//2b//2Zm/P8AZv7/Amb/Zvv/AGb9/wNm //9m/v8CZv9m3/8BE9//AwD//wD9//0A/v/9AAH///4A/P/8AAH/AP7/AgD/AP7/AgD/ //wA/v8CAP///gD+//0ACf//AP//AP//AP/9AAH/AP7/BAD/AAD//QD8/wAA/v/+AAL/ /wC9/wMA//8A/f/9AP7//QAB///+APz//AAB/wD+/wIA/wD+/wIA///8AP7/AgD///4A /v/9AAn//wD//wD//wD//QAB/wD+/wQA/wAA//0A/P8AAP7//gAC//8Avf8DZv//Zv3/ /Wb+//1mAf///mb8//xmAf9m/v8CZv9m/v8CZv///Gb+/wJm///+Zv7//WYJ//9m//9m //9m//1mAf9m/v8EZv9mZv/9Zvz/AGb+//5mAv//Zt//AAqB/4H/gf+B/+X/AAqB/4H/ gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AHTY/wAA/v8C AP8A+f8AAPf//gDq/wAA/P8AAP7/AAD6/wAA7P8AAKr/AAD+/wIA/wD5/wAA9//+AOr/ AAD8/wAA/v8AAPr/AADs/wAAqv8AZv7/Amb/Zvn/AGb3//5m6v8AZvz/AGb+/wBm+v8A Zuz/AGbT/wB62P8AAP7/AAD3/wAA+P8AAP7/AADr/wAA/P8EAAD//wD6/wAA7P8AAKr/ AAD+/wAA9/8AAPj/AAD+/wAA6/8AAPz/BAAA//8A+v8AAOz/AACq/wBm/v8AZvf/AGb4 /wBm/v8AZuv/AGb8/wRmZv//Zvr/AGbs/wBm0/8A9dj/AAD+/wIA/wD+//0AAP/9APv/ AAD8//0A/v/+AAH///4A/v/9APz/BgAA//8A///+AAD//gAB/wD+/wAA/v/9AAH///4A Bv//AP//AP/9ALL/AAD+/wIA/wD+//0AAP/9APv/AAD8//0A/v/+AAH///4A/v/9APz/ BgAA//8A///+AAD//gAB/wD+/wAA/v/9AAH///4ABv//AP//AP/9ALL/AGb+/wJm/2b+ //1mAP/9Zvv/AGb8//1m/v/+ZgH///5m/v/9Zvz/BmZm//9m///+ZgD//mYB/2b+/wBm /v/9ZgH///5mBv//Zv//Zv/9Ztv/ARDY//wABP8A//8A/v8CAP8A/v8AAPv//gAC//8A /v8CAP8A/v8BAAD+/wIA/wD+/wAA/P8GAP8A/wD/AP7/AgD/AP7/BwD//wD//wAA/v8C AP8A/f8EAP8A/wCu//wABP8A//8A/v8CAP8A/v8AAPv//gAC//8A/v8CAP8A/v8BAAD+ /wIA/wD+/wAA/P8GAP8A/wD/AP7/AgD/AP7/BwD//wD//wAA/v8CAP8A/f8EAP8A/wCu //xmBP9m//9m/v8CZv9m/v8AZvv//mYC//9m/v8CZv9m/v8BZmb+/wJm/2b+/wBm/P8G Zv9m/2b/Zv7/Amb/Zv7/B2b//2b//2Zm/v8CZv9m/f8EZv9m/2bX/wD72P8AAP7/BQD/ AP//AP7/AgD/AP7/AAD4/wIA/wD+/wEA//cAAf8A/v8AAPz/BQD//wAA//wAAf8A/v8H AP8A/wD/AAD+/wIA/wD9/wEAAP7//gCx/wAA/v8FAP8A//8A/v8CAP8A/v8AAPj/AgD/ AP7/AQD/9wAB/wD+/wAA/P8FAP//AAD//AAB/wD+/wcA/wD/AP8AAP7/AgD/AP3/AQAA /v/+ALH/AGb+/wVm/2b//2b+/wJm/2b+/wBm+P8CZv9m/v8BZv/3ZgH/Zv7/AGb8/wVm //9mZv/8ZgH/Zv7/B2b/Zv9m/2Zm/v8CZv9m/f8BZmb+//5m2v8BE9j/AAD+/wUA/wD/ /wD+/wIA/wD+/wAA/P8AAP7/AgD/AP7/AgD/AP3/AAD8/wAA/v8AAPz/BgD//wAA/wD8 /wAA/f8AAP7/AgD/AP7/AgD/AP3/AgD/APz/AACy/wAA/v8FAP8A//8A/v8CAP8A/v8A APz/AAD+/wIA/wD+/wIA/wD9/wAA/P8AAP7/AAD8/wYA//8AAP8A/P8AAP3/AAD+/wIA /wD+/wIA/wD9/wIA/wD8/wAAsv8AZv7/BWb/Zv//Zv7/Amb/Zv7/AGb8/wBm/v8CZv9m /v8CZv9m/f8AZvz/AGb+/wBm/P8GZv//Zmb/Zvz/AGb9/wBm/v8CZv9m/v8CZv9m/f8C Zv9m/P8AZtv/AQHY/wAA/v8CAP8A/v8FAAD/AP8A/v8AAPv//gAB///9AP7//QAA//0A Af///QD8/wAA/v8CAP///QAC/wAA/v8AAP7/AgD///4AAv//AP3/AgD///wAsf8AAP7/ AgD/AP7/BQAA/wD/AP7/AAD7//4AAf///QD+//0AAP/9AAH///0A/P8AAP7/AgD///0A Av8AAP7/AAD+/wIA///+AAL//wD9/wIA///8ALH/AGb+/wJm/2b+/wVmZv9m/2b+/wBm +//+ZgH///1m/v/9ZgD//WYB///9Zvz/AGb+/wJm///9ZgL/Zmb+/wBm/v8CZv///mYC //9m/f8CZv///Gba/wAqz/8AAP7/AADw/wAAgf/k/wAA/v8AAPD/AACB/+T/AGb+/wBm 8P8AZpb/AB7O//4A7/8AAIH/4//+AO//AACB/+P//mbv/wBmlv8ACoH/gf+B/4H/5f8A CoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/ gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B /4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/ 5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8A CoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/gf+B/4H/5f8ACoH/ gf+B/4H/5f8ACoH/gf+B/4H/5f8ARbr//gAB/wD5/wAA9v8CAP8A+P8AAIH/8//+AAH/ APn/AAD2/wIA/wD4/wAAgf/z//4AAf8A+f8AAPb/AgD/APj/AAC6/wBguf8CAAD/+QAA //4AAP/7AAH///4AAf//+wAC/wAAgf/z/wIAAP/5AAD//gAA//sAAf///gAB///7AAL/ AACB//P/AgAA//kAAP/+AAD/+wAB///+AAH///sAAv8AALv/AG+3/wIAAP/9AAb/AP8A /wD//QAD/wD///4AAf///QAD/wD/AIH/8P8CAAD//QAG/wD/AP8A//0AA/8A///+AAH/ //0AA/8A/wCB//D/AgAA//0ABv8A/wD/AP/9AAP/AP///gAB///9AAP/AP8Auv8Ab7n/ AwAA///6AAT/AP8A//0ACP8A//8A//8A//0ABP8A//8Agf/z/wMAAP//+gAE/wD/AP/9 AAj/AP//AP//AP/9AAT/AP//AIH/8/8DAAD///oABP8A/wD//QAI/wD//wD//wD//QAE /wD//wC7/wASsf8AAIH/zv8AAIH/zv8AAJ7/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/ AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB /4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/ gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B /+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/ AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB /4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/ gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B /+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/ AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB /4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/ gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B /+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/ AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB /4H/gf+B/+X/AAqB/4H/gf+B/+X/AAqB/4H/gf+B/+X/AP8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAAAwoBAAAAAAAAAAAAAAAAAAAA AAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuzAIAAIgCAAAQ AAAAAQAAAIgAAAADAAAAkAAAAA8AAACoAAAABAAAAMQAAAAGAAAAzAAAAAcAAADUAAAA CAAAANwAAAAJAAAA5AAAAAoAAADsAAAAFwAAAPQAAAALAAAA/AAAABAAAAAEAQAAEwAA AAwBAAAWAAAAFAEAAA0AAAAcAQAADAAAACgCAAACAAAAECcAAB4AAAAPAAAAT24tc2Ny ZWVuIFNob3cAZR4AAAARAAAAQkJOIFRlY2hub2xvZ2llcwByAGYDAAAAJjIAAAMAAAAq AAAAAwAAAAYAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAADAAAAYhYIAAsAAAAAAAAA CwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAsAAAAGAAAAVGltZXMABgAAAEFyaWFs AA8AAABNb25vdHlwZSBTb3J0cwAMAAAAQXJpYWwgQmxhY2sABwAAAE5TQSBWNQArAAAA SVBzZWMgRW5oYW5jZW1lbnRzIGZvciBIaWdoIFNwZWVkIE5ldHdvcmtzABQAAABDdXJy ZW50IENvbnN0cmFpbnRzABsAAABTZXF1ZW5jZSBOdW1iZXIgRXhoYXVzdGlvbgAXAAAA RW5jcnlwdGlvbiBQZXJmb3JtYW5jZQAjAAAAQSBQcm9wb3NlZCBDb3VudGVyIEVuY3J5 cHRpb24gTW9kZQAWAAAASW50ZWdyaXR5IFBlcmZvcm1hbmNlAAwQAAAGAAAAHgAAAAsA AABGb250cyBVc2VkAAMAAAAEAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEA AAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAABgAAAJgAAAADAAAAAAAAACAAAAABAAAA NgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAAAQJwAAQQAAAE4AAAB7 AEIAMwBGADAAMAAzADAAMAAtAEMAQwAyAEUALQAxADEARAA0AC0AQgBGAEQARgAtAEIA RAAyADIAQwBGADYANABFADYARgBBAH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQwB1AHIA cgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+//// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////wAA 9g8iAAAAFAAAAF/AkeMCMgAACgD0AwMAAABTdGV2ZSBLZW50CAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --============_-1231312349==_============-- From owner-ipsec@lists.tislabs.com Mon Jan 29 16:58:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02495; Mon, 29 Jan 2001 16:58:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26073 Mon, 29 Jan 2001 19:15:44 -0500 (EST) Message-Id: <200101300011.QAA09304@potassium.network-alchemy.com> To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: compliance question In-reply-to: Your message of "Mon, 29 Jan 2001 16:02:28 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9301.980813511.1@network-alchemy.com> Date: Mon, 29 Jan 2001 16:11:51 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, A way to tell a peer in a standards-compliant manner already exists. RFC2407 defines a REPLAY-STATUS notify message that IKE can use to tell a peer whether or not it has anti-replay enabled for a particular SA (it's chained onto a Quick Mode message ala RESPONDER-LIFETIME). I don't know how many people actually implemented it though. The default is to assume anti-replay is enabled so the only use of REPLAY-STATUS would be to support something that we all acknowledge is generally not a good idea to do. Dan. On Mon, 29 Jan 2001 16:02:28 EST you wrote > Dan, > > >A question for the protocol police. Section 3.3.3 of RFC2406 says: > > > > The sender assumes anti-replay is enabled as a default, unless > > otherwise notified by the receiver (see 3.4.3). Thus, if the counter > > has cycled, the sender will set up a new SA and key (unless the SA > > was configured with manual key management). > > > > If anti-replay is disabled, the sender does not need to monitor or > > reset the counter, e.g., in the case of manual key management (see > > Section 5). However, the sender still increments the counter and > > when it reaches the maximum value, the counter rolls over back to > > zero. > > > >Ignoring for the sake of a question whether disabling anti-replay is > >smart or not, would an implementation be conformant if, when anti-replay > >is disabled, the sequence number rolled over to zero prior to reaching > >it's maximum value? That is 1, 2, ... 2^5, 1, 2, etc. > > If we adopted a way for the sender to be told by the receiver that it > did not care about anti-replay, then it would seem reasonable to > ignore the transmit counter value and allow it to rollover. But, for > now, this behavior would be non-compliant. For some algorithms and > modes, e.g.g., single DES in CBC mode, 2**32 packets is a good limit > and most easily enforced by the counter, irrespective of anti-replay > concerns, so we should be aware that we would be giving up this > feature if we adopt this approach. However, if we depricate the use > of single DES and move to AES, as expected, this might become moot. > > Steve > From owner-ipsec@lists.tislabs.com Tue Jan 30 08:36:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA03956; Tue, 30 Jan 2001 08:36:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00331 Tue, 30 Jan 2001 09:53:46 -0500 (EST) Date: Mon, 29 Jan 2001 17:42:39 +0000 From: Kanta Matsuura To: ipsec@lists.tislabs.com Subject: hash payload in IKE Message-ID: <1537615811.980790159@deseronto.ccsr.cam.ac.uk> X-Mailer: Mulberry (Win32) [1.4.5, s/n S-100001] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear those who are familiar with RFC2409 and IKE implementations, RFC 2409 says "For authentication with digital signatures, HASH_I and HASH_R are signed and verified" (in Page 10) and "the signed data, SIG_I or SIG_R, is the result of the negotiated digital signature algorithm applied to HASH_I or HASH_R" ^^^^ (in Page 11). Does this mean that the hash payloads (HASH_I, HASH_R) are sent explicitly? Or they are not transmitted but must be computed by the recipient? --- K.Matsuura From owner-ipsec@lists.tislabs.com Tue Jan 30 13:58:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21696; Tue, 30 Jan 2001 13:58:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01653 Tue, 30 Jan 2001 15:59:00 -0500 (EST) Message-ID: <3A772CDF.4E0AEE26@cisco.com> Date: Tue, 30 Jan 2001 22:06:39 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: <3A6FD6E4.93F510EE@cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > Frédéric, > > I'm very uncomfortable moving toward ACKs in ESP. We try in IPsec to mimic IP functionality as much as possible, and IP does not ACK packets. I agree but we also created a tunneling protocol... what does not make much sense in transport mode makes a lot in tunnel mode. (but I am with you, do not shoot) > Note that our anti-replay strategy allows for out of order arrival precisely because IP allows for it (even though we do impose some limits here). Again, I can only agree with you. The only goal of the ack is to avoid a "large" gap between the sender and the receiver. In filigrane, read large as "configurable" gap in the sense of . can be turned off . gap of configurable size (in # of packets or amount of data). Obviously, no retransmission of any sort nor any expectation in the order of arrival (replay detection stays as it is): we just ack the biggest packet ID received (piggy backed if possible). More (or actually less), my very restricted goal is to make sure the other IPSec peer still has all its marbles. NOT assuring *some* packets were not lost in the path (well if that has that side effect, good, but we do not want to explicitely cover that; we let it to TCP). Actually, I am not too much in favor of changing ESP either: I believe it would be better to design an acknowledged tunneling protocol (or change an existing one like GRE or L2TP) and make it "IPSec aware" within a given stack (i.e. when the tunnel lacks some acks, it tears itself down and takes its SA's with it). >From the field, though, I can see that people are already so confused with a single tunnel... and we make them use tunnels in tunnels... and they screw their topology. I just thought it may be easier to embed the feature in IPSec (almost transparently) => would make IPSec more appealing. Now, if you tell me that this is a Bad-Idea(tm)... frederic > Steve From owner-ipsec@lists.tislabs.com Tue Jan 30 14:00:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA21802; Tue, 30 Jan 2001 14:00:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA01611 Tue, 30 Jan 2001 15:54:46 -0500 (EST) From: "Christian Franzen" To: Subject: delete notification Date: Tue, 30 Jan 2001 21:57:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi what should happen if an ipsec gateway receives a delete notification. - delete ISAKMP SADB or - delete all (IPsec and ISAKMP) SADB should an initial contact be started immediately? Cisco deletes only ISAKMP SAs as far as I know and doesn't start with main mode again. This question comes up if you decide to delete all SAs when an ISDN line of an ISDN Router goes down. Do you have any idea of how to tell the peer, that all SAs were deleted? Thanks for your help Christian From owner-ipsec@lists.tislabs.com Tue Jan 30 15:15:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25862; Tue, 30 Jan 2001 15:15:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA01844 Tue, 30 Jan 2001 17:13:45 -0500 (EST) Message-ID: <3A773E5F.9F9FEFEF@cisco.com> Date: Tue, 30 Jan 2001 23:21:19 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sankar ramamoorthi CC: sommerfeld@East.Sun.COM, skelly@redcreek.com, ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sankar ramamoorthi wrote: > >notice that you made a lot of progress. Your "slight changes" actually > shift the original paradigm from a "keepaplive in disguise" into > "acknowledgement in disguise". > > No, it is more like 'acknowledgements-when-needed' turn it the way you want. They are acks. > >Take my first emails and re-read: acknowledgments are better. > > > acknowledgements only when needed is still better :-) no, it is slower. > > >Your problem is that you really want to trigger this with an "invalid SPI" > message. And you come up with pretty fancy packets. Not that I do not like > them (they're a valid vector after all) but now your philosophically correct > pseudo-ICMP's tunnel data :) > > Yes, but not all error/packets though, only the 'receipt-needed' type of > control packet. Not all pink rabits have green sunglasses... [stuff trimmed] > > As for as I understand the scheme, you have > I corrected your sketch. There is no notification message. peer wih out-of-sync/no ipsecSA peer sending data step1 send ESP data <----------------------- no ipsec or ike state with peer. send notification in IKE offer. step2 initiate directed-ike phase1 or phase2 exchange (ike for a particular reason) sa proposal + 'because I do not have SA xxx and you do' ---------------------------> if reason is satifactory respond to IKE exchange from peer step4 <--------------------------- responder proposal (2nd message of ike exchange sa proposal + 'because you did not have SA xxx' ... (IKE continues and terminates with a CoB). > Seems to be a neat way to avoid passive attacks. However the > initial IKE message is not authenticated and it now carries > additional information. The first four Main Mode IKE packet are NEVER authenticated anyway. So what ? They contain keying material and your policies... who cares ? Think of it: there are active attacks against IKE but they are very specific and take you nowhere or people live with that (been debated). I do not introduce (I think) any [new] weakness in IKE. Period. > What are the kind of attacks possible? a. I do not see any attack that could not be done on IKE. b. So far, no one sees one. c. That is exactly why I asked the list and why I am trying to write this ~@#&% draft. If you find a problem that is introduced in IKE by my method, please mention it. You will save me a lot of time. If you find a problem in IKE... wow. > > Comparing this with an ESP based scheme.. > [trimmed] (already discussed that). > > > >. acknowledgements are good but > > a) slower than direct notifications (need several lost packets, > > Yes - but how fast do you want to recover? Since you ask me: as fast as possible. > > With the ipsec error protocol, speed of recovery is left to the > implementation. Mmmh... heard of round trip time ? High speed high latency ? Take the time you want but think you can lose quite a few packets inbetween. It could be your broker, your VoIP call to the police, your remote surgeon... > If one side needs a very fast recovery, a keep-alive > equivalent protocol can be implemented using the messages provided > in ipsec error protocol. NO. Once and for all: keepalives are Bad. Evil. Broken. You shifted your own scheme from keepalives to acknowledgements... [trimmed things I did not want to comment] > > b) if uncontrolled, may restart IKE for nothing. E.g., Under a DoS, > genuine ESP packets with a valid seq# may not reach the destination which in > turn could not acknowledge them => forcing an undue rekey. > > > Agreed. This is a problem. But if genuine ESP packets cannot get through, > the rekeys also won't succeed You have very polite hackers around you then. regards, frederic detienne From owner-ipsec@lists.tislabs.com Tue Jan 30 17:18:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA29614; Tue, 30 Jan 2001 17:18:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02197 Tue, 30 Jan 2001 19:34:30 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: Cc: Subject: RE: ipsec error protocol Date: Tue, 30 Jan 2001 19:34:22 -0500 Message-Id: <003a01c08b1d$8f7e37a0$1e72788a@andrewk3.ca.alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <3A773E5F.9F9FEFEF@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > What are the kind of attacks possible? > > a. I do not see any attack that could not be done on IKE. > > b. So far, no one sees one. > > c. That is exactly why I asked the list and why I am trying > to write this ~@#&% draft. Realistically speaking, there are only 2 attacks we need to worry about: DoS and excessive generation of known plaintext. Both are possible, to varying extents, with any of the methods we have seen proposed. > > If one side needs a very fast recovery, a keep-alive > > equivalent protocol can be implemented using the messages provided > > in ipsec error protocol. > > NO. Once and for all: keepalives are Bad. Evil. Broken. > > You shifted your own scheme from keepalives to acknowledgements... Can we please not be dogmatic about this? Keepalives come with certain well-known pitfalls; if you know what they are, you can invent a scheme with whatever design tolerances you desire. Anddrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Frédéric Detienne > Sent: Tuesday, January 30, 2001 5:21 PM > To: sankar ramamoorthi > Cc: sommerfeld@East.Sun.COM; skelly@redcreek.com; > ipsec@lists.tislabs.com > Subject: Re: ipsec error protocol > > > sankar ramamoorthi wrote: > > >notice that you made a lot of progress. Your "slight > changes" actually > > shift the original paradigm from a "keepaplive in disguise" into > > "acknowledgement in disguise". > > > > No, it is more like 'acknowledgements-when-needed' > > turn it the way you want. They are acks. > > > >Take my first emails and re-read: acknowledgments are better. > > > > > acknowledgements only when needed is still better :-) > > no, it is slower. > > > > > >Your problem is that you really want to trigger this with > an "invalid SPI" > > message. And you come up with pretty fancy packets. Not > that I do not like > > them (they're a valid vector after all) but now your > philosophically correct > > pseudo-ICMP's tunnel data :) > > > > Yes, but not all error/packets though, only the > 'receipt-needed' type of > > control packet. > > Not all pink rabits have green sunglasses... > > [stuff trimmed] > > > > > As for as I understand the scheme, you have > > > > I corrected your sketch. There is no notification message. > > > peer wih out-of-sync/no ipsecSA peer > sending data > > step1 > send ESP data > <----------------------- > > no ipsec or ike state with > peer. send notification in > IKE offer. > > step2 > initiate directed-ike phase1 > or phase2 exchange > (ike for a particular reason) > sa proposal + 'because I do > not have SA xxx and you do' > ---------------------------> > > if reason is satifactory > respond to IKE exchange > from peer > step4 > <--------------------------- > responder proposal (2nd > message of ike exchange > sa proposal + 'because you did > not have SA xxx' > > ... (IKE continues and terminates > with a CoB). > > > Seems to be a neat way to avoid passive attacks. However the > > initial IKE message is not authenticated and it now carries > > additional information. > > The first four Main Mode IKE packet are NEVER authenticated > anyway. So what ? They contain keying material and your > policies... who cares ? > > Think of it: there are active attacks against IKE but they > are very specific and take you nowhere or people live with > that (been debated). I do not introduce (I think) any [new] > weakness in IKE. Period. > > > > What are the kind of attacks possible? > > a. I do not see any attack that could not be done on IKE. > > b. So far, no one sees one. > > c. That is exactly why I asked the list and why I am trying > to write this ~@#&% draft. > > > If you find a problem that is introduced in IKE by my method, > please mention it. You will save me a lot of time. > > If you find a problem in IKE... wow. > > > > > > Comparing this with an ESP based scheme.. > > > > [trimmed] (already discussed that). > > > > > > >. acknowledgements are good but > > > a) slower than direct notifications (need several lost packets, > > > > Yes - but how fast do you want to recover? > > Since you ask me: as fast as possible. > > > > > With the ipsec error protocol, speed of recovery is left to the > > implementation. > > Mmmh... heard of round trip time ? High speed high latency ? > > Take the time you want but think you can lose quite a few > packets inbetween. > > It could be your broker, your VoIP call to the police, your > remote surgeon... > > > > If one side needs a very fast recovery, a keep-alive > > equivalent protocol can be implemented using the messages provided > > in ipsec error protocol. > > NO. Once and for all: keepalives are Bad. Evil. Broken. > > You shifted your own scheme from keepalives to acknowledgements... > > > [trimmed things I did not want to comment] > > > > b) if uncontrolled, may restart IKE for nothing. E.g., > Under a DoS, > > genuine ESP packets with a valid seq# may not reach the > destination which in > > turn could not acknowledge them => forcing an undue rekey. > > > > > Agreed. This is a problem. But if genuine ESP packets > cannot get through, > > the rekeys also won't succeed > > You have very polite hackers around you then. > > > regards, > > frederic detienne > From owner-ipsec@lists.tislabs.com Tue Jan 30 17:42:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA00338; Tue, 30 Jan 2001 17:42:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02247 Tue, 30 Jan 2001 20:00:33 -0500 (EST) Message-Id: <200101310103.f0V13J5152166@thunk.east.sun.com> From: Bill Sommerfeld To: andrew.krywaniuk@alcatel.com cc: fd@cisco.com, ipsec@lists.tislabs.com Subject: Re: ipsec error protocol In-reply-to: Your message of "Tue, 30 Jan 2001 19:34:22 EST." <003a01c08b1d$8f7e37a0$1e72788a@andrewk3.ca.alcatel.com> Reply-to: sommerfeld@East.Sun.COM Date: Tue, 30 Jan 2001 20:03:19 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Can we please not be dogmatic about this? Keepalives come with certain > well-known pitfalls; if you know what they are, you can invent a scheme with > whatever design tolerances you desire. keepalives: - do not quickly detect loss of state unless the keepalive timeout is very short. - generate traffic even when applications have nothing to say. if the keepalive timeout is short, they may even generate more overhead packets than "real" traffic - have no way to distinguish temporary loss of connectivity from permanent loss of state, resulting in premature disconnects. They are an extremely poor fit for the problem. - Bill From owner-ipsec@lists.tislabs.com Tue Jan 30 17:57:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA00711; Tue, 30 Jan 2001 17:57:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02340 Tue, 30 Jan 2001 20:17:37 -0500 (EST) From: ji@research.att.com Date: Tue, 30 Jan 2001 20:20:32 -0500 (EST) Message-Id: <200101310120.UAA08154@bual.research.att.com> To: andrew.krywaniuk@alcatel.com, sommerfeld@East.Sun.COM Subject: Re: ipsec error protocol Cc: fd@cisco.com, ipsec@lists.tislabs.com Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "keepalive" is a misnomer. The proper term is "makedead". /ji From owner-ipsec@lists.tislabs.com Tue Jan 30 18:36:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA01706; Tue, 30 Jan 2001 18:36:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA02408 Tue, 30 Jan 2001 20:50:57 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: ji@research.att.com Cc: andrew.krywaniuk@alcatel.com, sommerfeld@East.Sun.COM, fd@cisco.com, ipsec@lists.tislabs.com Subject: Re: ipsec error protocol Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Jan 2001 20:53:49 -0500 Message-Id: <20010131015350.3B26835C42@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200101310120.UAA08154@bual.research.att.com>, ji@research.att.com w rites: >"keepalive" is a misnomer. The proper term is "makedead". > More or less. A keep-alive is a way to temporarily disarm a timer-based make-dead mechanism. Thus, TCP may have a keep-alive with a 2-hour minimum timeout (RFC 1122, Section 4.2.3.6). The *intent* is that a connection that is idle for two hours be made dead; that's the purpose of the requirement. And that, in turn, is because connections consume certain resoures that end systems may need to recover. The keep-alive is a message sent in the absence of other traffic, to inform the other side that there is still a host (and, presumably, an application) that wants the connection to persist, even though it is temporarily idle. But -- and it's an important "but" -- if no such message can get through for two hours, yes, the connection should be torn down if the hosts or connections have that feature configured. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Tue Jan 30 21:52:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA06070; Tue, 30 Jan 2001 21:52:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA02861 Wed, 31 Jan 2001 00:05:21 -0500 (EST) From: "sankar ramamoorthi" To: Cc: , , Subject: RE: ipsec error protocol Date: Tue, 30 Jan 2001 21:12:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3A773E5F.9F9FEFEF@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >From: goofy@cisco.com on behalf of Frederic Detienne [fd@cisco.com] >Sent: Tuesday, January 30, 2001 2:21 PM >To: sankar ramamoorthi >Cc: sommerfeld@East.Sun.COM; skelly@redcreek.com; >ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >sankar ramamoorthi wrote: >> >notice that you made a lot of progress. Your "slight changes" actually >> shift the original paradigm from a "keepaplive in disguise" into >> "acknowledgement in disguise". >> >> No, it is more like 'acknowledgements-when-needed' > >turn it the way you want. They are acks. > >> >Take my first emails and re-read: acknowledgments are better. >> > >> acknowledgements only when needed is still better :-) > >no, it is slower. > >> >> >Your problem is that you really want to trigger this with an "invalid SPI" >> message. And you come up with pretty fancy packets. Not that I do not like >> them (they're a valid vector after all) but now your philosophically correct >> pseudo-ICMP's tunnel data :) >> >> Yes, but not all error/packets though, only the 'receipt-needed' type of >> control packet. > >Not all pink rabits have green sunglasses... > >[stuff trimmed] > >> >> As for as I understand the scheme, you have >> > >I corrected your sketch. There is no notification message. > Thanks for pointing it out. I missed this part. > > peer wih out-of-sync/no ipsecSA peer sending data > > step1 > send ESP data > <----------------------- > > no ipsec or ike state with > peer. send notification in > IKE offer. > > step2 > initiate directed-ike phase1 > or phase2 exchange > (ike for a particular reason) > sa proposal + 'because I do > not have SA xxx and you do' > ---------------------------> > > if reason is satifactory > respond to IKE exchange > from peer > step4 > <--------------------------- > responder proposal (2nd > message of ike exchange > sa proposal + 'because you did > not have SA xxx' > > ... (IKE continues and terminates with a CoB). > >> Seems to be a neat way to avoid passive attacks. However the >> initial IKE message is not authenticated and it now carries >> additional information. > >The first four Main Mode IKE packet are NEVER authenticated anyway. So what ? They contain keying material and your policies... who cares ? > >Think of it: there are active attacks against IKE but they are very specific and take you nowhere or people live with that (been debated). I do not introduce (I think) any [new] weakness in IKE. Period. > On the face of it it looks fine, you will need rate limiting though - otherwise one can end up with a lot of ike timers under DOS conditions. A question. How will directed exchange work in ipsra scenario? Assume the remote access server has lost state about a remote-client. On receiving the ESP packet, the server has to start a directed ike exchange, which means it has to have a SPD policy entry for the remote client. In some of the remote access implmentations, it is always the remote client which is the initiator - ie: a dynamic SPD policy is created for the remote client once it is authenticated (not through IKE but through some legacy auth mechanism). The dynamic SPD policy is deleted once the SA is deleted. So the server may not even know the right SPD policy for the client to start the directed IKE negotiation. >> >> With the ipsec error protocol, speed of recovery is left to the >> implementation. > >Mmmh... heard of round trip time ? High speed high latency ? > >Take the time you want but think you can lose quite a few packets inbetween. > >It could be your broker, your VoIP call to the police, your remote surgeon... > > >> If one side needs a very fast recovery, a keep-alive >> equivalent protocol can be implemented using the messages provided >> in ipsec error protocol. > >NO. Once and for all: keepalives are Bad. Evil. Broken. > >You shifted your own scheme from keepalives to acknowledgements... > Agreed - The arguments seem to be similiar to what people had for TCP_KEEPALIVE. Just one comment about the acknowledgements in ipsec error protocol. The ipsec error protocol does not use acknowledgemnts in the usual sense. It uses 'recipt' packet to indicate that some valid ESP packet was received on the inbound-SA. It is not an acknowledgemnt to a particular packet. It is more of an acknowledment to say that the channel is alive. Hence reordering is not an issue. -- sankar -- From owner-ipsec@lists.tislabs.com Wed Jan 31 10:10:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16160; Wed, 31 Jan 2001 10:10:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA05262 Wed, 31 Jan 2001 11:39:16 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200101300011.QAA09304@potassium.network-alchemy.com> References: <200101300011.QAA09304@potassium.network-alchemy.com> Date: Wed, 31 Jan 2001 11:33:27 -0500 To: Dan Harkins From: Stephen Kent Subject: Re: compliance question Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, > Steve, > > A way to tell a peer in a standards-compliant manner already exists. >RFC2407 defines a REPLAY-STATUS notify message that IKE can use to >tell a peer whether or not it has anti-replay enabled for a particular >SA (it's chained onto a Quick Mode message ala RESPONDER-LIFETIME). >I don't know how many people actually implemented it though. The default >is to assume anti-replay is enabled so the only use of REPLAY-STATUS >would be to support something that we all acknowledge is generally >not a good idea to do. Well, this one certainly escaped my attention! Chalk it up to our lack of adequate coordination between IKE and the other IPsec standards in our rush to get it all done. Until 2401 is revised and accommodates this sort of facility, I'd stick with my original observation. Steve From owner-ipsec@lists.tislabs.com Wed Jan 31 11:32:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20921; Wed, 31 Jan 2001 11:32:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05546 Wed, 31 Jan 2001 13:12:09 -0500 (EST) From: "sankar ramamoorthi" To: "Stephen Kent" Cc: Subject: RE: ipsec error protocol Date: Wed, 31 Jan 2001 10:14:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C08B6E.A6DD0560" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C08B6E.A6DD0560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >From: Stephen Kent [kent@bbn.com] >Sent: Monday, January 29, 2001 12:24 PM >To: sankar ramamoorthi >Cc: ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >Sankar, > >> >> >> > >> >Question: what if every ESP (for instance) packet would piggy back an >>acknowledgement field (in both direction) ? That would solve quite a few >>issues, no ? And would also be much more efficient. >> > >> >>I do not understand what you have in mind for the semantic of >>acknowledgement field. >> >>Yes, it would be nice to have an 'RECEIPT-NEEDED' and 'RECEIPT' type of >>flags >>in the ESP. It would also be nice to have versioning in ESP. >>Any reason why versioning was left out of the initial ESP design? > >Good question. I think we envisioned an IKE negotiation for this, but >it could have been done better. No place for a small version number >up front, given alignment considerations, and if we assume a general >need for a negotiation for an SA prior to its establishment, then >that's the right time to find out what your peer can support, e.g., >re versions. For now, I see no need to create a new version of ESP. >For example, we're planning to accommodate bigger sequence numbers >via a negotiation but NO change in the on the wire format. Thus I Some questions on this topic. As per RFC 2401, if an ipsec implementation gets a packet with valid authentication and whose sequence number is larger than the current replay window, the implementation should accept the packet and set its sequnce window to the larger size. At 10 million packets/sec(10^7) it takes approximately 400 seconds for a 32 bit sequence to overflow. That means if someone were to replay a valid authenticated packet every 400 seconds it is likely to accepted as a valid packet. How will changing the sequence number space to a bigger value by just negotiation alone help the above problem? Does'nt on the wire sequence number size also has to change? What am I missing? Thanks, -- sankar -- > >Steve ------=_NextPart_000_0013_01C08B6E.A6DD0560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>From: Stephen Kent = [kent@bbn.com]
>Sent: Monday, = January 29,=20 2001 12:24 PM
>To: sankar ramamoorthi
>Cc: ipsec@lists.tislabs.com
&g= t;Subject:=20 Re: ipsec error=20 protocol
>
>Sankar,
>
>><snip>
>&g= t;
>> =20 >
>>  >Question: what if every ESP (for instance) = packet=20 would piggy back an
>>acknowledgement field (in both direction) = ? That=20 would solve quite a few
>>issues, no ? And would also be much = more=20 efficient.
>>  >
>>
>>I do not = understand=20 what you have in mind for the semantic of
>>acknowledgement=20 field.
>>
>>Yes, it would be nice to have an = 'RECEIPT-NEEDED'=20 and 'RECEIPT' type of
>>flags
>>in the ESP. It would = also be=20 nice to have versioning in ESP.
>>Any reason why versioning was = left=20 out of the initial ESP design?
>
>Good question. I think we=20 envisioned an IKE negotiation for this, but
>it could have been = done=20 better. No place for a small version number
>up front, given = alignment=20 considerations, and if we assume a general
>need for a = negotiation for an=20 SA prior to its establishment, then
>that's the right time to = find out=20 what your peer can support, e.g.,
>re versions.  For now, I = see no=20 need to create a new version of ESP.
>For example, we're planning = to=20 accommodate bigger sequence numbers
>via a negotiation but NO = change in=20 the on the wire format. Thus I
 

Some questions on = this=20 topic.
 
As per RFC 2401, if an = ipsec=20 implementation gets a  packet with
valid authentication and whose = sequence=20 number is larger than the
current replay window, the=20 implementation should accept the packet
and set its = sequnce=20 window to the larger = size. 
 
At 10 million = packets/sec(10^7) it=20 takes approximately 400 seconds for
a 32 bit sequence to overflow.=20
 
That means if someone = were to replay=20 a valid authenticated packet every
400 seconds it is = likely to=20 accepted as a valid packet.
 
How will changing the = sequence number=20 space to a bigger value
by just negotiation alone help the above = problem?=20 Does'nt on the wire
sequence number size also has to change? =
 
What am I = missing?
 
Thanks,
 
-- sankar = --
 
>
>Steve
------=_NextPart_000_0013_01C08B6E.A6DD0560-- From owner-ipsec@lists.tislabs.com Wed Jan 31 11:35:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21216; Wed, 31 Jan 2001 11:35:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA05621 Wed, 31 Jan 2001 13:29:57 -0500 (EST) Message-ID: <3A785AD1.9E540EC9@columbia.sparta.com> Date: Wed, 31 Jan 2001 13:34:57 -0500 From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: automated gateway discovery Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, Can anyone give me a pointer to recent work on automated gateway discovery, especially in nested environments? Thanks, Andrea Colegrove From owner-ipsec@lists.tislabs.com Wed Jan 31 14:25:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02047; Wed, 31 Jan 2001 14:25:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06105 Wed, 31 Jan 2001 15:58:31 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 31 Jan 2001 16:00:41 -0500 To: "sankar ramamoorthi" From: Stephen Kent Subject: RE: ipsec error protocol Cc: Content-Type: multipart/alternative; boundary="============_-1231147536==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1231147536==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:14 AM -0800 1/31/01, sankar ramamoorthi wrote: > >From: Stephen Kent [kent@bbn.com] >>Sent: Monday, January 29, 2001 12:24 PM >>To: sankar ramamoorthi >>Cc: ipsec@lists.tislabs.com >>Subject: Re: ipsec error protocol >> >>Sankar, >> >>> >>> >>> > >>> >Question: what if every ESP (for instance) packet would piggy back an >>>acknowledgement field (in both direction) ? That would solve quite a few >>>issues, no ? And would also be much more efficient. >>> > >>> >>>I do not understand what you have in mind for the semantic of >>>acknowledgement field. >>> >>>Yes, it would be nice to have an 'RECEIPT-NEEDED' and 'RECEIPT' type of >>>flags >>>in the ESP. It would also be nice to have versioning in ESP. >>>Any reason why versioning was left out of the initial ESP design? >> >>Good question. I think we envisioned an IKE negotiation for this, but >>it could have been done better. No place for a small version number >>up front, given alignment considerations, and if we assume a general >>need for a negotiation for an SA prior to its establishment, then >>that's the right time to find out what your peer can support, e.g., >>re versions. For now, I see no need to create a new version of ESP. >>For example, we're planning to accommodate bigger sequence numbers >>via a negotiation but NO change in the on the wire format. Thus I > > >Some questions on this topic. > >As per RFC 2401, if an ipsec implementation gets a packet with >valid authentication and whose sequence number is larger than the >current replay window, the implementation should accept the packet >and set its sequnce window to the larger size. > >At 10 million packets/sec(10^7) it takes approximately 400 seconds for >a 32 bit sequence to overflow. > >That means if someone were to replay a valid authenticated packet every >400 seconds it is likely to accepted as a valid packet. > >How will changing the sequence number space to a bigger value >by just negotiation alone help the above problem? Does'nt on the wire >sequence number size also has to change? > >What am I missing? You are missing a couple of points that have been mentioned in previous messages to the list: - yes, I have proposed an extension of the sequence number space to allow for much larger sequence numbers, e.g., 64 bit sequence numbers, but with transmission of only the low order 32 bits in the AH or ESP header. - the proposal includes the extended sequence number in the integrity calculation, so a replayed packet will not be accepted by ESP (or AH) even though it carries only a 32-bit sequence number in the header, i.e., if a packet arrives with a sequence number that looks like a rollover of the 32-bit sequence number, it will be treated as having a 64-bit number with the low order bit of the high order 32 bits incremented by 1. A replay, when viewed in this fashion, will fail the integrity check, which means the receive sequence number window will not be changed. Steve --============_-1231147536==_ma============ Content-Type: text/html; charset="us-ascii" RE: ipsec error protocol
At 10:14 AM -0800 1/31/01, sankar ramamoorthi wrote:
>From: Stephen Kent [kent@bbn.com]
>Sent: Monday, January 29, 2001 12:24 PM
>To: sankar ramamoorthi
>Cc: ipsec@lists.tislabs.com
>Subject: Re: ipsec error protocol
>
>Sankar,
>
>><snip>
>>
>>  >
>>  >Question: what if every ESP (for instance) packet would piggy back an
>>acknowledgement field (in both direction) ? That would solve quite a few
>>issues, no ? And would also be much more efficient.
>>  >
>>
>>I do not understand what you have in mind for the semantic of
>>acknowledgement field.
>>
>>Yes, it would be nice to have an 'RECEIPT-NEEDED' and 'RECEIPT' type of
>>flags
>>in the ESP. It would also be nice to have versioning in ESP.
>>Any reason why versioning was left out of the initial ESP design?
>
>Good question. I think we envisioned an IKE negotiation for this, but
>it could have been done better. No place for a small version number
>up front, given alignment considerations, and if we assume a general
>need for a negotiation for an SA prior to its establishment, then
>that's the right time to find out what your peer can support, e.g.,
>re versions.  For now, I see no need to create a new version of ESP.
>For example, we're planning to accommodate bigger sequence numbers
>via a negotiation but NO change in the on the wire format. Thus I
 

Some questions on this topic.
 
As per RFC 2401, if an ipsec implementation gets a  packet with
valid authentication and whose sequence number is larger than the
current replay window, the implementation should accept the packet
and set its sequnce window to the larger size. 
 
At 10 million packets/sec(10^7) it takes approximately 400 seconds for
a 32 bit sequence to overflow.
 
That means if someone were to replay a valid authenticated packet every
400 seconds it is likely to accepted as a valid packet.
 
How will changing the sequence number space to a bigger value
by just negotiation alone help the above problem? Does'nt on the wire
sequence number size also has to change?
 
What am I missing?

You are missing a couple of points that have been mentioned in previous messages to the list:

        - yes, I have proposed an extension of the sequence number space to allow for much larger sequence numbers, e.g., 64 bit sequence numbers, but with transmission of only the low order 32 bits in the AH or ESP header.

        - the proposal includes the extended sequence number in the integrity calculation, so a replayed packet will not be accepted by ESP (or AH) even though it carries only a 32-bit sequence number in the header, i.e., if a packet arrives with a sequence number that looks like a rollover of the 32-bit sequence number, it will be treated as having a 64-bit number with the low order bit of the high order 32 bits incremented by 1. A replay, when viewed in this fashion, will fail the integrity check, which means the receive sequence number window will not be changed.

Steve
--============_-1231147536==_ma============-- From owner-ipsec@lists.tislabs.com Wed Jan 31 14:30:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02525; Wed, 31 Jan 2001 14:30:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06036 Wed, 31 Jan 2001 15:51:40 -0500 (EST) From: "Joseph D. Harwood" To: "sankar ramamoorthi" , "Stephen Kent" Cc: Subject: RE: ipsec error protocol Date: Wed, 31 Jan 2001 12:54:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01C08B84.FFF27E80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-reply-to: X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C08B84.FFF27E80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C08B84.FFF27E80" ------=_NextPart_001_0008_01C08B84.FFF27E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit By include, I mean the authentication calculation covers the upper 32 bits of the expanded sequence number. Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com -----Original Message----- From: Joseph D. Harwood [mailto:jharwood@vesta-corp.com] Sent: Wednesday, January 31, 2001 12:52 PM To: sankar ramamoorthi; Stephen Kent Cc: ipsec@lists.tislabs.com Subject: RE: ipsec error protocol Sankar, The authentication value would include the upper 32-bits of the expanded sequence number, even though it isn't sent on the wire. A replay of an earlier packet would thus fail. Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of sankar ramamoorthi Sent: Wednesday, January 31, 2001 10:15 AM To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: RE: ipsec error protocol >From: Stephen Kent [kent@bbn.com] >Sent: Monday, January 29, 2001 12:24 PM >To: sankar ramamoorthi >Cc: ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >Sankar, > >> >> >> > >> >Question: what if every ESP (for instance) packet would piggy back an >>acknowledgement field (in both direction) ? That would solve quite a few >>issues, no ? And would also be much more efficient. >> > >> >>I do not understand what you have in mind for the semantic of >>acknowledgement field. >> >>Yes, it would be nice to have an 'RECEIPT-NEEDED' and 'RECEIPT' type of >>flags >>in the ESP. It would also be nice to have versioning in ESP. >>Any reason why versioning was left out of the initial ESP design? > >Good question. I think we envisioned an IKE negotiation for this, but >it could have been done better. No place for a small version number >up front, given alignment considerations, and if we assume a general >need for a negotiation for an SA prior to its establishment, then >that's the right time to find out what your peer can support, e.g., >re versions. For now, I see no need to create a new version of ESP. >For example, we're planning to accommodate bigger sequence numbers >via a negotiation but NO change in the on the wire format. Thus I Some questions on this topic. As per RFC 2401, if an ipsec implementation gets a packet with valid authentication and whose sequence number is larger than the current replay window, the implementation should accept the packet and set its sequnce window to the larger size. At 10 million packets/sec(10^7) it takes approximately 400 seconds for a 32 bit sequence to overflow. That means if someone were to replay a valid authenticated packet every 400 seconds it is likely to accepted as a valid packet. How will changing the sequence number space to a bigger value by just negotiation alone help the above problem? Does'nt on the wire sequence number size also has to change? What am I missing? Thanks, -- sankar -- > >Steve ------=_NextPart_001_0008_01C08B84.FFF27E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
By=20 include, I mean the authentication calculation covers the upper 32 bits = of the=20 expanded sequence number. 
 

Best Regards,
Joseph D.=20 Harwood
jharwood@vesta-corp.com
www.vesta-corp.com

-----Original Message-----
From: Joseph D. Harwood=20 [mailto:jharwood@vesta-corp.com]
Sent: Wednesday, January = 31, 2001=20 12:52 PM
To: sankar ramamoorthi; Stephen Kent
Cc:=20 ipsec@lists.tislabs.com
Subject: RE: ipsec error=20 protocol

Sankar,
 
The=20 authentication value would include the upper 32-bits of the expanded = sequence=20 number, even though it isn't sent on the wire.  A replay of an = earlier=20 packet would thus fail.
 

Best Regards,
Joseph D.=20 Harwood
jharwood@vesta-corp.com
www.vesta-corp.com

-----Original Message-----
From:=20 owner-ipsec@lists.tislabs.com = [mailto:owner-ipsec@lists.tislabs.com]On=20 Behalf Of sankar ramamoorthi
Sent: Wednesday, January = 31, 2001=20 10:15 AM
To: Stephen Kent
Cc:=20 ipsec@lists.tislabs.com
Subject: RE: ipsec error=20 protocol

>From: Stephen = Kent [kent@bbn.com]
>Sent: Monday, = January=20 29, 2001 12:24 PM
>To: sankar ramamoorthi
>Cc: ipsec@lists.tislabs.com
&g= t;Subject:=20 Re: ipsec error=20 = protocol
>
>Sankar,
>
>><snip>
>&g= t;
>> =20 >
>>  >Question: what if every ESP (for = instance) packet=20 would piggy back an
>>acknowledgement field (in both = direction) ?=20 That would solve quite a few
>>issues, no ? And would also = be much=20 more efficient.
>>  >
>>
>>I do = not=20 understand what you have in mind for the semantic=20 of
>>acknowledgement field.
>>
>>Yes, it = would be=20 nice to have an 'RECEIPT-NEEDED' and 'RECEIPT' type=20 of
>>flags
>>in the ESP. It would also be nice to = have=20 versioning in ESP.
>>Any reason why versioning was left out = of the=20 initial ESP design?
>
>Good question. I think we = envisioned an=20 IKE negotiation for this, but
>it could have been done = better. No=20 place for a small version number
>up front, given alignment=20 considerations, and if we assume a general
>need for a = negotiation=20 for an SA prior to its establishment, then
>that's the right = time to=20 find out what your peer can support, e.g.,
>re = versions.  For=20 now, I see no need to create a new version of ESP.
>For = example,=20 we're planning to accommodate bigger sequence numbers
>via a=20 negotiation but NO change in the on the wire format. Thus I =
 

Some questions = on this=20 topic.
 
As per RFC 2401, if = an ipsec=20 implementation gets a  packet with
valid authentication = and whose sequence=20 number is larger than the
current replay window, the=20 implementation should accept the packet
and set its = sequnce=20 window to the larger = size. 
 
At 10 million = packets/sec(10^7)=20 it takes approximately 400 seconds for
a 32 bit sequence to = overflow.=20
 
That means if = someone were to=20 replay a valid authenticated packet every
400 seconds = it is=20 likely to accepted as a valid packet.
 
How will changing = the sequence=20 number space to a bigger value
by just negotiation alone help the = above=20 problem? Does'nt on the wire
sequence number size also has to = change?=20
 
What am I = missing?
 
Thanks,
 
-- sankar = --
 
>
>Steve
------=_NextPart_001_0008_01C08B84.FFF27E80-- ------=_NextPart_000_0007_01C08B84.FFF27E80 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0007_01C08B84.FFF27E80-- From owner-ipsec@lists.tislabs.com Wed Jan 31 14:31:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA02561; Wed, 31 Jan 2001 14:31:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05990 Wed, 31 Jan 2001 15:49:17 -0500 (EST) From: "Joseph D. Harwood" To: "sankar ramamoorthi" , "Stephen Kent" Cc: Subject: RE: ipsec error protocol Date: Wed, 31 Jan 2001 12:51:33 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_01C08B84.8A620F00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-reply-to: X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C08B84.8A620F00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0003_01C08B84.8A620F00" ------=_NextPart_001_0003_01C08B84.8A620F00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sankar, The authentication value would include the upper 32-bits of the expanded sequence number, even though it isn't sent on the wire. A replay of an earlier packet would thus fail. Best Regards, Joseph D. Harwood jharwood@vesta-corp.com www.vesta-corp.com -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of sankar ramamoorthi Sent: Wednesday, January 31, 2001 10:15 AM To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: RE: ipsec error protocol >From: Stephen Kent [kent@bbn.com] >Sent: Monday, January 29, 2001 12:24 PM >To: sankar ramamoorthi >Cc: ipsec@lists.tislabs.com >Subject: Re: ipsec error protocol > >Sankar, > >> >> >> > >> >Question: what if every ESP (for instance) packet would piggy back an >>acknowledgement field (in both direction) ? That would solve quite a few >>issues, no ? And would also be much more efficient. >> > >> >>I do not understand what you have in mind for the semantic of >>acknowledgement field. >> >>Yes, it would be nice to have an 'RECEIPT-NEEDED' and 'RECEIPT' type of >>flags >>in the ESP. It would also be nice to have versioning in ESP. >>Any reason why versioning was left out of the initial ESP design? > >Good question. I think we envisioned an IKE negotiation for this, but >it could have been done better. No place for a small version number >up front, given alignment considerations, and if we assume a general >need for a negotiation for an SA prior to its establishment, then >that's the right time to find out what your peer can support, e.g., >re versions. For now, I see no need to create a new version of ESP. >For example, we're planning to accommodate bigger sequence numbers >via a negotiation but NO change in the on the wire format. Thus I Some questions on this topic. As per RFC 2401, if an ipsec implementation gets a packet with valid authentication and whose sequence number is larger than the current replay window, the implementation should accept the packet and set its sequnce window to the larger size. At 10 million packets/sec(10^7) it takes approximately 400 seconds for a 32 bit sequence to overflow. That means if someone were to replay a valid authenticated packet every 400 seconds it is likely to accepted as a valid packet. How will changing the sequence number space to a bigger value by just negotiation alone help the above problem? Does'nt on the wire sequence number size also has to change? What am I missing? Thanks, -- sankar -- > >Steve ------=_NextPart_001_0003_01C08B84.8A620F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sankar,
 
The=20 authentication value would include the upper 32-bits of the expanded = sequence=20 number, even though it isn't sent on the wire.  A replay of an = earlier=20 packet would thus fail.
 

Best Regards,
Joseph D.=20 Harwood
jharwood@vesta-corp.com
www.vesta-corp.com

-----Original Message-----
From:=20 owner-ipsec@lists.tislabs.com = [mailto:owner-ipsec@lists.tislabs.com]On=20 Behalf Of sankar ramamoorthi
Sent: Wednesday, January = 31, 2001=20 10:15 AM
To: Stephen Kent
Cc:=20 ipsec@lists.tislabs.com
Subject: RE: ipsec error=20 protocol

>From: Stephen = Kent [kent@bbn.com]
>Sent: Monday, = January 29,=20 2001 12:24 PM
>To: sankar ramamoorthi
>Cc: ipsec@lists.tislabs.com
&g= t;Subject:=20 Re: ipsec error=20 = protocol
>
>Sankar,
>
>><snip>
>&g= t;
>> =20 >
>>  >Question: what if every ESP (for instance) = packet=20 would piggy back an
>>acknowledgement field (in both = direction) ?=20 That would solve quite a few
>>issues, no ? And would also be = much=20 more efficient.
>>  >
>>
>>I do not = understand what you have in mind for the semantic=20 of
>>acknowledgement field.
>>
>>Yes, it = would be=20 nice to have an 'RECEIPT-NEEDED' and 'RECEIPT' type=20 of
>>flags
>>in the ESP. It would also be nice to = have=20 versioning in ESP.
>>Any reason why versioning was left out = of the=20 initial ESP design?
>
>Good question. I think we = envisioned an IKE=20 negotiation for this, but
>it could have been done better. No = place for=20 a small version number
>up front, given alignment = considerations, and=20 if we assume a general
>need for a negotiation for an SA prior = to its=20 establishment, then
>that's the right time to find out what = your peer=20 can support, e.g.,
>re versions.  For now, I see no need = to create=20 a new version of ESP.
>For example, we're planning to = accommodate=20 bigger sequence numbers
>via a negotiation but NO change in the = on the=20 wire format. Thus I
 

Some questions on = this=20 topic.
 
As per RFC 2401, if = an ipsec=20 implementation gets a  packet with
valid authentication and whose = sequence=20 number is larger than the
current replay window, the=20 implementation should accept the packet
and set its = sequnce=20 window to the larger = size. 
 
At 10 million = packets/sec(10^7) it=20 takes approximately 400 seconds for
a 32 bit sequence to overflow.=20
 
That means if someone = were to=20 replay a valid authenticated packet every
400 seconds it = is likely=20 to accepted as a valid packet.
 
How will changing the = sequence=20 number space to a bigger value
by just negotiation alone help the = above=20 problem? Does'nt on the wire
sequence number size also has to = change?=20
 
What am I = missing?
 
Thanks,
 
-- sankar = --
 
>
>Steve
------=_NextPart_001_0003_01C08B84.8A620F00-- ------=_NextPart_000_0002_01C08B84.8A620F00 Content-Type: text/x-vcard; name="Joseph D. Harwood.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Joseph D. Harwood.vcf" BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa = Clara;CA;95054 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:(408) 838-9434=3D0D=3D0A5201 = Great America Parkway, Suite 320=3D0D=3D0ASanta Clara, =3D CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD ------=_NextPart_000_0002_01C08B84.8A620F00-- From owner-ipsec@lists.tislabs.com Wed Jan 31 15:44:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06173; Wed, 31 Jan 2001 15:44:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06313 Wed, 31 Jan 2001 17:11:53 -0500 (EST) From: "sankar ramamoorthi" To: "Stephen Kent" Cc: Subject: RE: ipsec error protocol Date: Wed, 31 Jan 2001 14:16:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C08B90.78F83DA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C08B90.78F83DA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit RE: ipsec error protocol>RE: ipsec error protocolFrom: Stephen Kent [kent@bbn.com] >Sent: Wednesday, January 31, 2001 1:01 PM >To: sankar ramamoorthi >Cc: ipsec@lists.tislabs.com >Subject: RE: ipsec error protocol > > Some questions on this topic. > > As per RFC 2401, if an ipsec implementation gets a packet with > valid authentication and whose sequence number is larger than the > current replay window, the implementation should accept the packet > and set its sequnce window to the larger size. > > At 10 million packets/sec(10^7) it takes approximately 400 seconds for > a 32 bit sequence to overflow. > > That means if someone were to replay a valid authenticated packet every > 400 seconds it is likely to accepted as a valid packet. > > How will changing the sequence number space to a bigger value > by just negotiation alone help the above problem? Does'nt on the wire > sequence number size also has to change? > > What am I missing? > > >You are missing a couple of points that have been mentioned in previous messages to the list: > > > - yes, I have proposed an extension of the sequence number space to allow for much larger sequence numbers, e.g., 64 bit sequence numbers, but with transmission of only the low order 32 bits in the AH or ESP header. > > > - the proposal includes the extended sequence number in the integrity calculation, so a replayed packet will not be accepted by ESP (or AH) even though it carries only a 32-bit sequence number in the header, i.e., if a packet arrives with a sequence number that looks like a rollover of the 32-bit sequence number, it will be treated as having a 64-bit number with the low order bit of the high order 32 bits incremented by 1. A replay, when viewed in this fashion, will fail the integrity check, which means the receive sequence number window will not be changed. > If I understand correctly what you are saying on-the-wire 32 bit sequence is first treated as the lower order 32 bits of a 64 bit sequence window. Once it overflows, it is treated as higher order 32 bits of the sequence window with the lower order 32 bits pegged at 64k-1(I presume). If that is the case we are using the 64bit window as two independent 32 bit windows. Does'nt it limit the amount of available window space and forces the rekeying to occur every (400*2) or (400*3) secs? Thanks, -- sankar -- > >Steve ------=_NextPart_000_002B_01C08B90.78F83DA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: ipsec error protocol
>RE: ipsec error = protocolFrom:=20 Stephen Kent [kent@bbn.com]
>Sent:=20 Wednesday, January 31, 2001 1:01 PM
>To: sankar = ramamoorthi
>Cc: ipsec@lists.tislabs.com
&g= t;Subject:=20 RE: ipsec error protocol
>
>  Some questions on this=20 topic.
>
>  As per RFC 2401, if an ipsec implementation = gets=20 a  packet with
>  valid authentication and whose = sequence number=20 is larger than the
>  current replay window, the = implementation=20 should accept the packet
>  and set its sequnce window to the = larger=20 size.
>
>  At 10 million packets/sec(10^7) it takes=20 approximately 400 seconds for
>  a 32 bit sequence to=20 overflow.
>
>  That means if someone were to replay a = valid=20 authenticated packet every
>  400 seconds it is likely to = accepted as=20 a valid packet.
>
>  How will changing the sequence = number=20 space to a bigger value
>  by just negotiation alone help the = above=20 problem? Does'nt on the wire
>  sequence number size also has = to=20 change?
>
>  What am I = missing?
>
>
>You are=20 missing a couple of points that have been mentioned in previous messages = to the=20 list:
>
>
>        = - yes, I=20 have proposed an extension of the sequence number space to allow for = much larger=20 sequence numbers, e.g., 64 bit sequence numbers, but with transmission = of only=20 the low order 32 bits in the AH or ESP=20 header.
>
>
>       = - the=20 proposal includes the extended sequence number in the integrity = calculation, so=20 a replayed packet will not be accepted by ESP (or AH) even though it = carries=20 only a 32-bit sequence number in the header, i.e., if a packet arrives = with a=20 sequence number that looks like a rollover of the 32-bit sequence = number, it=20 will be treated as having a 64-bit number with the low order bit of the = high=20 order 32 bits incremented by 1. A replay, when viewed in this fashion, = will fail=20 the integrity check, which means the receive sequence number window will = not be=20 changed.
>
 
If I understand = correctly what you=20 are saying
 
on-the-wire 32 bit = sequence is first=20 treated as the lower order 32
bits of a 64 bit sequence window. Once = it=20 overflows, it is treated as
higher order 32 bits of the sequence = window with=20 the lower order
32 bits pegged at 64k-1(I presume).
 
If that is = the=20 case we are  using the = 64bit=20 window as two independent 32 bit
windows. Does'nt it limit the amount = of=20 available window space and=20 forces
the rekeying to occur every (400*2) = or=20 (400*3) secs? 
 
Thanks,
 
-- sankar = --
 
>
>Steve
------=_NextPart_000_002B_01C08B90.78F83DA0-- From owner-ipsec@lists.tislabs.com Wed Jan 31 15:46:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06230; Wed, 31 Jan 2001 15:46:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06389 Wed, 31 Jan 2001 17:38:09 -0500 (EST) From: "sankar ramamoorthi" To: "Stephen Kent" Cc: Subject: RE: ipsec error protocol Date: Wed, 31 Jan 2001 14:45:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C08B94.7669CDC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C08B94.7669CDC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit RE: ipsec error protocol>RE: ipsec error protocolFrom: Stephen Kent [kent@bbn.com] >Sent: Wednesday, January 31, 2001 1:01 PM >To: sankar ramamoorthi >Cc: ipsec@lists.tislabs.com >Subject: RE: ipsec error protocol > > Some questions on this topic. > > As per RFC 2401, if an ipsec implementation gets a packet with > valid authentication and whose sequence number is larger than the > current replay window, the implementation should accept the packet > and set its sequnce window to the larger size. > > At 10 million packets/sec(10^7) it takes approximately 400 seconds for > a 32 bit sequence to overflow. > > That means if someone were to replay a valid authenticated packet every > 400 seconds it is likely to accepted as a valid packet. > > How will changing the sequence number space to a bigger value > by just negotiation alone help the above problem? Does'nt on the wire > sequence number size also has to change? > > What am I missing? > > >You are missing a couple of points that have been mentioned in previous messages to the list: > > > - yes, I have proposed an extension of the sequence number space to allow for much larger sequence numbers, e.g., 64 bit sequence numbers, but with transmission of only the low order 32 bits in the AH or ESP header. > > > - the proposal includes the extended sequence number in the integrity calculation, so a replayed packet will not be accepted by ESP (or AH) even though it carries only a 32-bit sequence number in the header, i.e., if a packet arrives with a sequence number that looks like a rollover of the 32-bit sequence number, it will be treated as having a 64-bit number with the low order bit of the high order 32 bits incremented by 1. This is where I was getting confused. How are sequence numbers maintained on the outbound side? Is it maintained as a continously incresing 64bit counter? If so since the upper 32 bits are not sent over the wire, a replayed packet and a genuine packet whose lower 32 bit has rolled over may look the same to the receiver of the packet - right? -- sankar -- ------=_NextPart_000_0036_01C08B94.7669CDC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: ipsec error protocol
>RE: ipsec error = protocolFrom:=20 Stephen Kent [kent@bbn.com]
>Sent:=20 Wednesday, January 31, 2001 1:01 PM
>To: sankar = ramamoorthi
>Cc: ipsec@lists.tislabs.com
&g= t;Subject:=20 RE: ipsec error protocol
>
>  Some questions on this=20 topic.
>
>  As per RFC 2401, if an ipsec implementation = gets=20 a  packet with
>  valid authentication and whose = sequence number=20 is larger than the
>  current replay window, the = implementation=20 should accept the packet
>  and set its sequnce window to the = larger=20 size.
>
>  At 10 million packets/sec(10^7) it takes=20 approximately 400 seconds for
>  a 32 bit sequence to=20 overflow.
>
>  That means if someone were to replay a = valid=20 authenticated packet every
>  400 seconds it is likely to = accepted as=20 a valid packet.
>
>  How will changing the sequence = number=20 space to a bigger value
>  by just negotiation alone help the = above=20 problem? Does'nt on the wire
>  sequence number size also has = to=20 change?
>
>  What am I = missing?
>
>
>You are=20 missing a couple of points that have been mentioned in previous messages = to the=20 list:
>
>
>        = - yes, I=20 have proposed an extension of the sequence number space to allow for = much larger=20 sequence numbers, e.g., 64 bit sequence numbers, but with transmission = of only=20 the low order 32 bits in the AH or ESP=20 header.
>
>
>       = - the=20 proposal includes the extended sequence number in the integrity = calculation, so=20 a replayed packet will not be accepted by ESP (or AH) even though it = carries=20 only a 32-bit sequence number in the header, i.e., if a packet arrives = with a=20 sequence number that looks like a rollover of the 32-bit sequence = number, it=20 will be treated as having a 64-bit number with the low order bit of the = high=20 order 32 bits incremented by 1.
 
This is where I was = getting confused.=20 How are sequence numbers maintained
on the outbound side? =
 
Is it maintained as a = continously=20 incresing 64bit counter? If so
since the upper 32 bits are not sent = over the=20 wire, a replayed packet and = a=20
genuine packet whose lower 32 bit has rolled over may look the same=20 to
the receiver of the packet - right?
 
-- sankar = --
 
 
 
 
------=_NextPart_000_0036_01C08B94.7669CDC0-- From owner-ipsec@lists.tislabs.com Wed Jan 31 15:58:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA06509; Wed, 31 Jan 2001 15:58:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06415 Wed, 31 Jan 2001 17:48:23 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 31 Jan 2001 17:44:31 -0500 To: "sankar ramamoorthi" From: Stephen Kent Subject: RE: ipsec error protocol Cc: Content-Type: multipart/alternative; boundary="============_-1231140966==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1231140966==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:16 PM -0800 1/31/01, sankar ramamoorthi wrote: > > >If I understand correctly what you are saying > >on-the-wire 32 bit sequence is first treated as the lower order 32 >bits of a 64 bit sequence window. Once it overflows, it is treated as >higher order 32 bits of the sequence window with the lower order >32 bits pegged at 64k-1(I presume). No. the on-the-wire bits are always treated as the low order 32 bits of the sequence number. if two IPsec peers negotiate a large sequence number space, then when the low order bits overflow, they increment the high order part of the counter. Thus, every 2**32 packets, the high order part of the counter increments by 1. > If that is the case we are using the 64bit window as two independent 32 bit >windows. Does'nt it limit the amount of available window space and forces >the rekeying to occur every (400*2) or (400*3) secs? > no, see explanation above. Steve --============_-1231140966==_ma============ Content-Type: text/html; charset="us-ascii" RE: ipsec error protocol
At 2:16 PM -0800 1/31/01, sankar ramamoorthi wrote:

 
If I understand correctly what you are saying
 
on-the-wire 32 bit sequence is first treated as the lower order 32
bits of a 64 bit sequence window. Once it overflows, it is treated as
higher order 32 bits of the sequence window with the lower order
32 bits pegged at 64k-1(I presume).

No. the on-the-wire bits are always treated as the low order 32 bits of the sequence number. if two IPsec peers negotiate a large sequence number space, then when the low order bits overflow, they increment the high order part of the counter. Thus, every 2**32 packets, the high order part of the counter increments by 1.

 If that is the case we are  using the 64bit window as two independent 32 bit
windows. Does'nt it limit the amount of available window space and forces
the rekeying to occur every (400*2) or (400*3) secs? 
 

no, see explanation above.

Steve
--============_-1231140966==_ma============-- From owner-ipsec@lists.tislabs.com Wed Jan 31 16:00:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06565; Wed, 31 Jan 2001 16:00:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06456 Wed, 31 Jan 2001 18:06:26 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 31 Jan 2001 17:59:07 -0500 To: "sankar ramamoorthi" From: Stephen Kent Subject: RE: ipsec error protocol Cc: Content-Type: multipart/alternative; boundary="============_-1231140083==_ma============" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1231140083==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sankar, > > >This is where I was getting confused. How are sequence numbers maintained >on the outbound side? as full 64-bit values > >Is it maintained as a continously incresing 64bit counter? If so >since the upper 32 bits are not sent over the wire, a replayed packet and a >genuine packet whose lower 32 bit has rolled over may look the same to >the receiver of the packet - right? it would look the same until the integrity check was performed. admittedly, this scheme places a limit on receiver window size, i.e., it must be less than 2**32. anyone have a problem with that? Steve --============_-1231140083==_ma============ Content-Type: text/html; charset="us-ascii" RE: ipsec error protocol
Sankar,

<snip>
 
This is where I was getting confused. How are sequence numbers maintained
on the outbound side?

as full 64-bit values
 
Is it maintained as a continously incresing 64bit counter? If so
since the upper 32 bits are not sent over the wire, a replayed packet and a
genuine packet whose lower 32 bit has rolled over may look the same to
the receiver of the packet - right?

it would look the same until the integrity check was performed.

admittedly, this scheme places a limit on receiver window size, i.e., it must be less than 2**32.

anyone have a problem with that?

Steve


--============_-1231140083==_ma============-- From owner-ipsec@lists.tislabs.com Wed Jan 31 16:19:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA08753; Wed, 31 Jan 2001 16:19:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA06499 Wed, 31 Jan 2001 18:22:33 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3A772CDF.4E0AEE26@cisco.com> References: <3A6FD6E4.93F510EE@cisco.com> <3A772CDF.4E0AEE26@cisco.com> Date: Wed, 31 Jan 2001 18:19:46 -0500 To: fd@cisco.com From: Stephen Kent Subject: Re: ipsec error protocol Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id SAA06496 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Frédéric, >Stephen Kent wrote: >> >> Frédéric, >> >> I'm very uncomfortable moving toward ACKs in ESP. We try in IPsec >>to mimic IP functionality as much as possible, and IP does not ACK >>packets. > >I agree but we also created a tunneling protocol... what does not >make much sense in transport mode makes a lot in tunnel mode. Not sure I agree with the principle you state above, but we can let it ride for now. > >(but I am with you, do not shoot) > >> Note that our anti-replay strategy allows for out of order arrival >>precisely because IP allows for it (even though we do impose some >>limits here). > >Again, I can only agree with you. The only goal of the ack is to >avoid a "large" gap between the sender and the receiver. In >filigrane, read large as "configurable" gap in the sense of > >. can be turned off >. gap of configurable size (in # of packets or amount of data). > >Obviously, no retransmission of any sort nor any expectation in the >order of arrival (replay detection stays as it is): we just ack the >biggest packet ID received (piggy backed if possible). I have to admit that, at this point in the exchange (and trying to deal with threads o other lists at the same time) that I'm lost. What problem are we trying to solve? Is it the loss of state at the other IPsec device, or the parallel crypto chip and sequence number problem that Dan raised? Steve From owner-ipsec@lists.tislabs.com Wed Jan 31 17:34:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA10526; Wed, 31 Jan 2001 17:34:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06629 Wed, 31 Jan 2001 19:42:28 -0500 (EST) From: "sankar ramamoorthi" To: "Stephen Kent" Cc: Subject: RE: ipsec error protocol Date: Wed, 31 Jan 2001 16:49:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C08BA5.CD49E290" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0062_01C08BA5.CD49E290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit RE: ipsec error protocol>RE: ipsec error protocolFrom: Stephen Kent [kent@bbn.com] >Sent: Wednesday, January 31, 2001 2:59 PM >To: sankar ramamoorthi >Cc: ipsec@lists.tislabs.com >Subject: RE: ipsec error protocol > >Sankar, > > > > > This is where I was getting confused. How are sequence numbers maintained > on the outbound side? > >as full 64-bit values > > > Is it maintained as a continously incresing 64bit counter? If so > since the upper 32 bits are not sent over the wire, a replayed packet and a > genuine packet whose lower 32 bit has rolled over may look the same to > the receiver of the packet - right? > > >it would look the same until the integrity check was performed. > > >admittedly, this scheme places a limit on receiver window size, i.e., it must be less than 2**32. > > >anyone have a problem with that? > If the receiver window is limited to 2**32 bits, then it means at 10Gig/sec speeds the receiver has to rekey after 400 seconds. Is that acceptable? -- sankar -- > >Steve > > > > ------=_NextPart_000_0062_01C08BA5.CD49E290 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: ipsec error protocol
>RE: ipsec error = protocolFrom:=20 Stephen Kent [kent@bbn.com]
>Sent:=20 Wednesday, January 31, 2001 2:59 PM
>To: sankar = ramamoorthi
>Cc: ipsec@lists.tislabs.com
&g= t;Subject:=20 RE: ipsec error = protocol
>
>Sankar,
>
>
> =20 <snip>
>
>  This is where I was getting confused. = How are=20 sequence numbers maintained
>  on the outbound=20 side?
>
>as full 64-bit values
>
>
>  = Is it=20 maintained as a continously incresing 64bit counter? If so
>  = since=20 the upper 32 bits are not sent over the wire, a replayed packet and=20 a
>  genuine packet whose lower 32 bit has rolled over may = look the=20 same to
>  the receiver of the packet -=20 right?
>
>
>it would look the same until the integrity = check=20 was performed.
>
>
>admittedly, this scheme places a = limit on=20 receiver window size, i.e., it must be less than 2**32.=20
>
>
>anyone have a problem with = that?
>
 
 
If the receiver = window is=20 limited to 2**32 bits, then it means
at 10Gig/sec speeds  the receiver has to rekey = after 400=20 seconds.
 
Is that = acceptable?
 
-- sankar = --
 
 
 
>
>Steve
>
>
>
>
 ------=_NextPart_000_0062_01C08BA5.CD49E290-- From owner-ipsec@lists.tislabs.com Wed Jan 31 18:46:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12851; Wed, 31 Jan 2001 18:46:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA06862 Wed, 31 Jan 2001 20:52:58 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "sankar ramamoorthi" Cc: "Stephen Kent" , ipsec@lists.tislabs.com Subject: Re: ipsec error protocol Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Jan 2001 20:55:44 -0500 Message-Id: <20010201015549.3175F35C42@smb.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "sankar ramamoorthi " writes: >> >>admittedly, this scheme places a limit on receiver window size, i.e., it >must be less than 2**32. >> >> >>anyone have a problem with that? >> > > >If the receiver window is limited to 2**32 bits, then it means >at 10Gig/sec speeds the receiver has to rekey after 400 seconds. > >Is that acceptable? > No, that's not what Steve meant. The window is effectively the limit on out-of-order packets. When a packet arrives, it has a sequence number. But the receiver has to keep track of packets that haven't arrived yet. This is typically done by a bit mask. See the end of section 3.4.3 in RFC 2406 and Appendix C of 2401. --Steve Bellovin, http://www.research.att.com/~smb From owner-ipsec@lists.tislabs.com Wed Jan 31 18:59:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA13172; Wed, 31 Jan 2001 18:59:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA06912 Wed, 31 Jan 2001 21:17:35 -0500 (EST) Message-ID: <3A78C90B.7E8475D9@cisco.com> Date: Thu, 01 Feb 2001 03:25:15 +0100 From: =?iso-8859-1?Q?Fr=E9d=E9ric?= Detienne Reply-To: fd@cisco.com Organization: Cisco X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: ipsec error protocol References: <3A6FD6E4.93F510EE@cisco.com> <3A772CDF.4E0AEE26@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > >Obviously, no retransmission of any sort nor any expectation in the > >order of arrival (replay detection stays as it is): we just ack the > >biggest packet ID received (piggy backed if possible). > > I have to admit that, at this point in the exchange (and trying to > deal with threads o other lists at the same time) that I'm lost. What > problem are we trying to solve? Is it the loss of state at the other > IPsec device, or the parallel crypto chip and sequence number problem > that Dan raised? the loss of state (and only that). > Steve